aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
...
* Lower error level from PANIC to FATAL when restoring slots at startupMichael Paquier2018-11-02
| | | | | | | | | | | | | | | | | | | | When restoring slot information from disk at startup and filling in shared memory information, the startup process would issue a PANIC message if more slots are found than what max_replication_slots allows, and then Postgres generates a core dump, recommending to increase max_replication_slots. This gives users a switch to crash Postgres at will by creating slots, lower the configuration to not support it, and then restart it. Making Postgres crash hard in this case is overdoing it just to give a recommendation to users. So instead use a FATAL, which makes Postgres fail to start without crashing, still giving the recommendation. This is more consistent with what happens for prepared transactions for example. Author: Michael Paquier Reviewed-by: Andres Freund Discussion: https://postgr.es/m/20181030025109.GD1644@paquier.xyz
* Remove obsolete pg_constraint.consrc columnPeter Eisentraut2018-11-01
| | | | | | This has been deprecated and effectively unused for a long time. Reviewed-by: Daniel Gustafsson <daniel@yesql.se>
* Remove obsolete pg_attrdef.adsrc columnPeter Eisentraut2018-11-01
| | | | | | | This has been deprecated and effectively unused for a long time. Reviewed-by: Alvaro Herrera <alvherre@2ndquadrant.com> Reviewed-by: Daniel Gustafsson <daniel@yesql.se>
* Fix error message typo introduced 691d79a07933.Andres Freund2018-11-01
| | | | | | Reported-By: Michael Paquier Discussion: https://postgr.es/m/20181101003405.GB1727@paquier.xyz Backpatch: 9.4-, like the previous commit
* Adjust trace_sort log messages.Peter Geoghegan2018-11-01
| | | | | | | | | | | | | | | | | The project message style guide dictates: "When citing the name of an object, state what kind of object it is". The parallel CREATE INDEX patch added a worker number to most of the trace_sort messages within tuplesort.c without specifying the object type. Bring these messages into compliance with the style guide. We're still treating a leader or serial Tuplesortstate as having worker number -1. trace_sort is a developer option, and these two cases are highly comparable, so this seems appropriate. Per complaint from Tom Lane. Discussion: https://postgr.es/m/8330.1540831863@sss.pgh.pa.us Backpatch: 11-, where parallel CREATE INDEX was introduced.
* Disallow starting server with insufficient wal_level for existing slot.Andres Freund2018-10-31
| | | | | | | | | | | | | | | | Previously it was possible to create a slot, change wal_level, and restart, even if the new wal_level was insufficient for the slot. That's a problem for both logical and physical slots, because the necessary WAL records are not generated. This removes a few tests in newer versions that, somewhat inexplicably, whether restarting with a too low wal_level worked (a buggy behaviour!). Reported-By: Joshua D. Drake Author: Andres Freund Discussion: https://postgr.es/m/20181029191304.lbsmhshkyymhw22w@alap3.anarazel.de Backpatch: 9.4-, where replication slots where introduced
* Fix memory leak in repeated SPGIST index scans.Tom Lane2018-10-31
| | | | | | | | | | | | | | | | | | | | | | | spgendscan neglected to pfree all the memory allocated by spgbeginscan. It's possible to get away with that in most normal queries, since the memory is allocated in the executor's per-query context which is about to get deleted anyway; but it causes severe memory leakage during creation or filling of large exclusion-constraint indexes. Also, document that amendscan is supposed to free what ambeginscan allocates. The docs' lack of clarity on that point probably caused this bug to begin with. (There is discussion of changing that API spec going forward, but I don't think it'd be appropriate for the back branches.) Per report from Bruno Wolff. It's been like this since the beginning, so back-patch to all active branches. In HEAD, also fix an independent leak caused by commit 2a6368343 (allocating memory during spgrescan instead of spgbeginscan, which might be all right if it got cleaned up, but it didn't). And do a bit of code beautification on that commit, too. Discussion: https://postgr.es/m/20181024012314.GA27428@wolff.to
* Fix typo in xlog.c.Andres Freund2018-10-31
| | | | | Author: Daniel Gustafsson Discussion: https://postgr.es/m/A6817958-949E-4A5B-895D-FA421B6640C2@yesql.se
* Sync our copy of the timezone library with IANA release tzcode2018g.Tom Lane2018-10-31
| | | | | | | | | | | | | This patch absorbs an upstream fix to "zic" for a recently-introduced bug that made it output data that some 32-bit clients couldn't read. Given the current source data, the bug only manifests in zones with leap seconds, which we don't generate, so that there's no actual change in our installed timezone data files from this. Still, in case somebody uses our copy of "zic" to do something else, it seems best to apply the fix promptly. Also, update the README's notes about converting upstream code to our conventions.
* Update time zone data files to tzdata release 2018g.Tom Lane2018-10-31
| | | | | DST law changes in Morocco (with, effectively, zero notice). Historical corrections for Hawaii.
* Fix interaction of CASE and ArrayCoerceExpr.Tom Lane2018-10-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | An array-type coercion appearing within a CASE that has a constant (after const-folding) test expression was mangled by the planner, causing all the elements of the resulting array to be equal to the coerced value of the CASE's test expression. This is my oversight in commit c12d570fa: that changed ArrayCoerceExpr to use a subexpression involving a CaseTestExpr, and I didn't notice that eval_const_expressions needed an adjustment to keep from folding such a CaseTestExpr to a constant when it's inside a suitable CASE. This is another in what's getting to be a depressingly long line of bugs associated with misidentification of the referent of a CaseTestExpr. We're overdue to redesign that mechanism; but any such fix is unlikely to be back-patchable into v11. As a stopgap, fix eval_const_expressions to do what it must here. Also add a bunch of comments pointing out the restrictions and assumptions that are needed to make this work at all. Also fix a related oversight: contain_context_dependent_node() was not aware of the relationship of ArrayCoerceExpr to CaseTestExpr. That was somewhat fail-soft, in that the outcome of a wrong answer would be to prevent optimizations that could have been made, but let's fix it while we're at it. Per bug #15471 from Matt Williams. Back-patch to v11 where the faulty logic came in. Discussion: https://postgr.es/m/15471-1117f49271989bad@postgresql.org
* pg_rewind: Remove unused macroPeter Eisentraut2018-10-30
| | | | | This has never been used while pg_rewind was in the tree (possibly once copied from pg_upgrade).
* Consolidate cross-option checks in pg_restoreMichael Paquier2018-10-30
| | | | | | | | | | | | | | | This moves one check for conflicting options from the archive restore code to the main function where other similar checks are performed. Also reword the error message to be consistent with other messages. The only option combination impacted is --create specified with --single-transaction, and informing the caller at an early step saves from opening the archive worked on. A TAP test is added for this combination. Author: Daniel Gustafsson Reviewed-by: Fabien Coelho Discussion: https://postgr.es/m/616808BD-4B59-4E6C-97A9-7317F62D5570@yesql.se
* Add pg_partition_tree to display information about partitionsMichael Paquier2018-10-30
| | | | | | | | | | | | | | | | | | This new function is useful to display a full tree of partitions with a partitioned table given in output, and avoids the need of any complex WITH RECURSIVE query when looking at partition trees which are deep multiple levels. It returns a set of records, one for each partition, containing the partition's name, its immediate parent's name, a boolean value telling if the relation is a leaf in the tree and an integer telling its level in the partition tree with given table considered as root, beginning at zero for the root, and incrementing by one each time the scan goes one level down. Author: Amit Langote Reviewed-by: Jesper Pedersen, Michael Paquier, Robert Haas Discussion: https://postgr.es/m/8d00e51a-9a51-ad02-d53e-ba6bf50b2e52@lab.ntt.co.jp
* Exclude temporary directories from pgindentPeter Eisentraut2018-10-29
| | | | | | Exclude tmp_check and tmp_install from pgindent. In a fully-built tree, pgindent would spend a lot of time digging through these directories and ends up re-indenting installed header files.
* pg_restore: Augment documentation for -N optionPeter Eisentraut2018-10-29
| | | | | | This was forgotten when the option was added. Author: Michael Banck <michael.banck@credativ.de>
* Remove incorrect comment in dshash.c.Thomas Munro2018-10-29
| | | | | | | Back-patch to 11. Author: Antonin Houska Discussion: https://postgr.es/m/8726.1540553521%40localhost
* Fix perl searchpath for modern perl for MSVC toolsAndrew Dunstan2018-10-28
| | | | | | | | | | | | | Modern versions of perl no longer include the current directory in the perl searchpath, as it's insecure. Instead of adding the current directory, we get around the problem by adding the directory where the script lives. Problem noted by Victor Wagner. Solution adapted from buildfarm client code. Backpatch to all live versions.
* Improve tab completion of CREATE EVENT TRIGGER in psqlMichael Paquier2018-10-26
| | | | | | | | | | | This adds tab completion of the clauses WHEN and EXECUTE FUNCTION|PROCEDURE clauses to CREATE EVENT TRIGGER, similar to CREATE TRIGGER in the previous commit. This has version-dependent logic so as FUNCTION is chosen over PROCEDURE for 11 and newer versions. Author: Dagfinn Ilmari Mannsåker Reviewed-by: Tom Lane, Michael Paquier Discussion: https://postgr.es/m/d8jmur4q4yc.fsf@dalvik.ping.uio.no
* Add tab completion of EXECUTE FUNCTION for CREATE TRIGGER in psqlMichael Paquier2018-10-26
| | | | | | | | | | | | | | | | The change to accept EXECUTE FUNCTION as well as EXECUTE PROCEDURE in CREATE TRIGGER (added by 0a63f99) forgot to tell psql's tab completion system about this. In passing, add tab completion of EXECUTE FUNCTION/PROCEDURE after a complete WHEN ( … ) clause. This change is version-aware, with FUNCTION being selected automatically instead of PROCEDURE depending on the backend version, PROCEDURE being an historical grammar kept for compatibility and considered as deprecated in v11. Author: Dagfinn Ilmari Mannsåker Reviewed-by: Tom Lane, Michael Paquier Discussion: https://postgr.es/m/d8jmur4q4yc.fsf@dalvik.ping.uio.no
* Add pg_promote functionMichael Paquier2018-10-25
| | | | | | | | | | | | This function is able to promote a standby with this new SQL-callable function. Execution access can be granted to non-superusers so that failover tools can observe the principle of least privilege. Catalog version is bumped. Author: Laurenz Albe Reviewed-by: Michael Paquier, Masahiko Sawada Discussion: https://postgr.es/m/6e7c79b3ec916cf49742fb8849ed17cd87aed620.camel@cybertec.at
* Apply unconstify() in more placesPeter Eisentraut2018-10-25
| | | | Discussion: https://www.postgresql.org/message-id/08adbe4e-38f8-2c73-55f0-591392371687%402ndquadrant.com
* Improve unconstify() documentationPeter Eisentraut2018-10-25
| | | | | | Refer to expression instead of variable when appropriate. Discussion: https://www.postgresql.org/message-id/08adbe4e-38f8-2c73-55f0-591392371687%402ndquadrant.com
* Fix typo in regression test commentAndrew Dunstan2018-10-24
| | | | per Michael Banck
* Correctly set t_self for heap tuples in expand_tupleAndrew Dunstan2018-10-24
| | | | | | | | | | | | Commit 16828d5c0 incorrectly set an invalid pointer for t_self for heap tuples. This patch correctly copies it from the source tuple, and includes a regression test that relies on it being set correctly. Backpatch to release 11. Fixes bug #15448 reported by Tillmann Schulz Diagnosis and test case by Amit Langote
* List wait events in alphabetical orderMichael Paquier2018-10-24
| | | | | | | | | | | | | | | This changes the documentation, and the related structures so as everything is consistent. Some wait events were not listed alphabetically since their introduction, others have been added rather randomly. Keeping all those entries in order helps in maintenance, and helps the user looking at the documentation. Author: Michael Paquier, Kuntal Ghosh Discussion: https://postgr.es/m/20181024002539.GI1658@paquier.xyz Backpatch-through: 10, only for the documentation part to avoid an ABI breakage.
* Remove get_attidentity()Peter Eisentraut2018-10-23
| | | | | | | | All existing uses can get this information more easily from the relation descriptor, so the detour through the syscache is not necessary. Reviewed-by: Michael Paquier <michael@paquier.xyz>
* Remove get_atttypmod()Peter Eisentraut2018-10-23
| | | | | | | This has been unused since 2004. get_atttypetypmodcoll() is often a better alternative. Reviewed-by: Michael Paquier <michael@paquier.xyz>
* Drop const cast from dlsym() callsPeter Eisentraut2018-10-23
| | | | | | | This workaround might be obsolete. We'll see if those "older platforms" mentioned in the comment are still around. Discussion: https://www.postgresql.org/message-id/08adbe4e-38f8-2c73-55f0-591392371687%402ndquadrant.com
* Sprinkle some const decorationsPeter Eisentraut2018-10-23
| | | | These mainly help understanding the function signatures better.
* Clarify descriptions of relhassubclass and relispartition in pg_classMichael Paquier2018-10-22
| | | | | | | | Three places are fixed, one for each author. Reported-by: Tom Lane Author: Tom Lane, Amit Langote, Michael Paquier Discussion: https://postgr.es/m/82470.1540177167@sss.pgh.pa.us
* Set pg_class.relhassubclass for partitioned indexesMichael Paquier2018-10-22
| | | | | | | | | | | | | | | | | Like for relations, switching this parameter is optimistic by turning it on each time a partitioned index gains a partition. So seeing this parameter set to true means that the partitioned index has or has had partitions. The flag cannot be reset yet for partitioned indexes, which is something not obvious anyway as partitioned relations exist to have partitions. This allows to track more conveniently partition trees for indexes, which will come in use with an upcoming patch helping in listing partition trees with an SQL-callable function. Author: Amit Langote Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/80306490-b5fc-ea34-4427-f29c52156052@lab.ntt.co.jp
* Don't try to test files named with a trailing dot on WindowsAndrew Dunstan2018-10-21
| | | | | | | | | | | The pg_verify_checksums test tries to create files with corrupt data named "123." and "123_." But on Windows a file name with a trailing dot is the same as a file without the trailing dot. In the first case this will create a file with a "valid" name, which causes the test to fail in an unexpected way, and in the secongd case this will be redandant as the test already creates a file named "123_". Bug discovered by buildfarm animal bowerbird.
* Lower privilege level of programs calling regression_mainAndrew Dunstan2018-10-20
| | | | | | | | | | | On Windows this mean that the regression tests can now safely and successfully run as Administrator, which is useful in situations like Appveyor. Elsewhere it's a no-op. Backpatch to 9.5 - this is harder in earlier branches and not worth the trouble. Discussion: https://postgr.es/m/650b0c29-9578-8571-b1d2-550d7f89f307@2ndQuadrant.com
* Client-side fixes for delayed NOTIFY receipt.Tom Lane2018-10-19
| | | | | | | | | | | | | | | | | | | | | | | | PQnotifies() is defined to just process already-read data, not try to read any more from the socket. (This is a debatable decision, perhaps, but I'm hesitant to change longstanding library behavior.) The documentation has long recommended calling PQconsumeInput() before PQnotifies() to ensure that any already-arrived message would get absorbed and processed. However, psql did not get that memo, which explains why it's not very reliable about reporting notifications promptly. Also, most (not quite all) callers called PQconsumeInput() just once before a PQnotifies() loop. Taking this recommendation seriously implies that we should do PQconsumeInput() before each call. This is more important now that we have "payload" strings in notification messages than it was before; that increases the probability of having more than one packet's worth of notify messages. Hence, adjust code as well as documentation examples to do it like that. Back-patch to 9.5 to match related server fixes. In principle we could probably go back further with these changes, but given lack of field complaints I doubt it's worthwhile. Discussion: https://postgr.es/m/CAOYf6ec-TmRYjKBXLLaGaB-jrd=mjG1Hzn1a1wufUAR39PQYhw@mail.gmail.com
* Server-side fix for delayed NOTIFY and SIGTERM processing.Tom Lane2018-10-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 4f85fde8e introduced some code that was meant to ensure that we'd process cancel, die, sinval catchup, and notify interrupts while waiting for client input. But there was a flaw: it supposed that the process latch would be set upon arrival at secure_read() if any such interrupt was pending. In reality, we might well have cleared the process latch at some earlier point while those flags remained set -- particularly notifyInterruptPending, which can't be handled as long as we're within a transaction. To fix the NOTIFY case, also attempt to process signals (except ProcDiePending) before trying to read. Also, if we see that ProcDiePending is set before we read, forcibly set the process latch to ensure that we will handle that signal promptly if no data is available. I also made it set the process latch on the way out, in case there is similar logic elsewhere. (It remains true that we won't service ProcDiePending here unless we need to wait for input.) The code for handling ProcDiePending during a write needs those changes, too. Also be a little more careful about when to reset whereToSendOutput, and improve related comments. Back-patch to 9.5 where this code was added. I'm not entirely convinced that older branches don't have similar issues, but the complaint at hand is just about the >= 9.5 code. Jeff Janes and Tom Lane Discussion: https://postgr.es/m/CAOYf6ec-TmRYjKBXLLaGaB-jrd=mjG1Hzn1a1wufUAR39PQYhw@mail.gmail.com
* Sync our copy of the timezone library with IANA release tzcode2018f.Tom Lane2018-10-19
| | | | | | | | | | | | | | | | About half of this is purely cosmetic changes to reduce the diff between our code and theirs, like inserting "const" markers where they have them. The other half is tracking actual code changes in zic.c and localtime.c. I don't think any of these represent near-term compatibility hazards, but it seems best to stay up to date. I also fixed longstanding bugs in our code for producing the known_abbrevs.txt list, which by chance hadn't been exposed before, but which resulted in some garbage output after applying the upstream changes in zic.c. Notably, because upstream removed their old phony transitions at the Big Bang, it's now necessary to cope with TZif files containing no DST transition times at all.
* Update time zone data files to tzdata release 2018f.Tom Lane2018-10-19
| | | | | | | | | | | | | DST law changes in Chile, Fiji, and Russia (Volgograd). Historical corrections for China, Japan, Macau, and North Korea. Note: like the previous tzdata update, this involves a depressingly large amount of semantically-meaningless churn in tzdata.zi. That is a consequence of upstream's data compression method assigning unstable abbreviations to DST rulesets. I complained about that to them last time, and this version now uses an assignment method that pays some heed to not changing abbreviations unnecessarily. So hopefully, that'll be better going forward.
* Silence perlcritic warning about missing return.Tom Lane2018-10-19
| | | | Per buildfarm member crake.
* Use whitelist to choose files scanned with pg_verify_checksumsMichael Paquier2018-10-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The original implementation of pg_verify_checksums used a blacklist to decide which files should be skipped for scanning as they do not include data checksums, like pg_internal.init or pg_control. However, this missed two things: - Some files are created within builds of EXEC_BACKEND and these were not listed, causing failures on Windows. - Extensions may create custom files in data folders, causing the tool to equally fail. This commit switches to a whitelist-like method instead by checking if the files to scan are authorized relation files. This is close to a reverse-engineering of what is defined in relpath.c in charge of building the relation paths, and we could consider refactoring what this patch does so as all routines are in a single place. This is left for later. This is based on a suggestion from Andres Freund. TAP tests are updated so as multiple file patterns are tested. The bug has been spotted by various buildfarm members as a result of b34e84f which has introduced the TAP tests of pg_verify_checksums. Author: Michael Paquier Reviewed-by: Andrew Dunstan, Michael Banck Discussion: https://postgr.es/m/20181012005614.GC26424@paquier.xyz Backpatch-through: 11
* Add missing quote_identifier calls for CREATE TRIGGER ... REFERENCING.Tom Lane2018-10-19
| | | | | | | | | | | Mixed-case names for transition tables weren't dumped correctly. Oversight in commit 8c48375e5, per bug #15440 from Karl Czajkowski. In passing, I couldn't resist a bit of code beautification. Back-patch to v10 where this was introduced. Discussion: https://postgr.es/m/15440-02d1468e94d63d76@postgresql.org
* Refactor pid, random seed and start time initialization.Thomas Munro2018-10-19
| | | | | | | | | | | | | | | | | | | | | | | | Background workers, including parallel workers, were generating the same sequence of numbers in random(). This showed up as DSM handle collisions when Parallel Hash created multiple segments, but any code that calls random() in background workers could be affected if it cares about different backends generating different numbers. Repair by making sure that all new processes initialize the seed at the same time as they set MyProcPid and MyStartTime in a new function InitProcessGlobals(), called by the postmaster, its children and also standalone processes. Also add a new high resolution MyStartTimestamp as a potentially useful by-product, and remove SessionStartTime from struct Port as it is now redundant. No back-patch for now, as the known consequences so far are just a bunch of harmless shm_open(O_EXCL) collisions. Author: Thomas Munro Reviewed-by: Tom Lane Discussion: https://postgr.es/m/CAEepm%3D2eJj_6%3DB%2B2tEpGu2nf1BjthCf9nXXUouYvJJ4C5WSwhg%40mail.gmail.com
* Still further rethinking of build changes for macOS Mojave.Tom Lane2018-10-18
| | | | | | | | | | | | | | | | | | | | | | | To avoid the sorts of problems complained of by Jakob Egger, it'd be best if configure didn't emit any references to the sysroot path at all. In the case of PL/Tcl, we can do that just by keeping our hands off the TCL_INCLUDE_SPEC string altogether. In the case of PL/Perl, we need to substitute -iwithsysroot for -I in the compile commands, which is easily handled if we change to using a configure output variable that includes the switch not only the directory name. Since PL/Tcl and PL/Python already do it like that, this seems like good consistency cleanup anyway. Hence, this replaces the advice given to Perl-related extensions in commit 5e2217131; instead of writing "-I$(perl_archlibexp)/CORE", they should just write "$(perl_includespec)". (The old way continues to work, but not on recent macOS.) It's still the case that configure needs to be aware of the sysroot path internally, but that's cleaner than what we had before. As before, back-patch to all supported versions. Discussion: https://postgr.es/m/20840.1537850987@sss.pgh.pa.us
* Improve some comments related to executor result relations.Tom Lane2018-10-17
| | | | | | | | es_leaf_result_relations doesn't exist; perhaps this was an old name for es_tuple_routing_result_relations, or maybe this comment has gone unmaintained through multiple rounds of whacking the code around. Related comment in execnodes.h was both obsolete and ungrammatical.
* Const-ify a few more large static tables.Tom Lane2018-10-17
| | | | | | Per research by Andres. Discussion: https://postgr.es/m/20181015200754.7y7zfuzsoux2c4ya@alap3.anarazel.de
* Fix minor bug in isolationtester.Tom Lane2018-10-17
| | | | | | | | | | | | | | If the lock wait query failed, isolationtester would report the PQerrorMessage from some other connection, meaning there would be no message or an unrelated one. This seems like a pretty unlikely occurrence, but if it did happen, this bug could make it really difficult/confusing to figure out what happened. That seems to justify patching all the way back. In passing, clean up another place where the "wrong" conn was used for an error report. That one's not actually buggy because it's a different alias for the same connection, but it's still confusing to the reader.
* Fix crash in multi-insert COPYPeter Eisentraut2018-10-17
| | | | | | | | | A bug introduced in 0d5f05cde011512e605bb2688d9b1fbb5b3ae152 considered the *previous* partition's triggers when deciding whether multi-insert can be used. Rearrange the code so that the current partition is considered. Author: Ashutosh Sharma <ashu.coek88@gmail.com>
* Minor additional improvements for ecpglib/prepare.c.Tom Lane2018-10-17
| | | | | | | | | | | | | | | | | | | Avoid allocating never-used entries in stmtCacheEntries[], other than the intentionally-unused zero'th entry. Tie the array size directly to the bucket count and size, rather than having undocumented dependencies between three magic constants. Fix the hash calculation to be platform-independent --- notably, it was sensitive to the signed'ness of "char" before, not to mention having an unnecessary hard-wired dependency on the existence and size of type "long long". (The lack of complaints says it's been a long time since anybody tried to build PG on a compiler without "long long", and certainly with the requirement for C99 this isn't a live bug anymore. But it's still not per project coding style.) Fix ecpg_auto_prepare's new-cache-entry path so that it increments the exec count for the new cache entry not the dummy zero'th entry. The last of those is an actual bug, though one of little consequence; the rest is mostly future-proofing and neatnik-ism. Doesn't seem necessary to back-patch.
* Improve tzparse's handling of TZDEFRULES ("posixrules") zone data.Tom Lane2018-10-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the IANA timezone code, tzparse() always tries to load the zone file named by TZDEFRULES ("posixrules"). Previously, we'd hacked that logic to skip the load in the "lastditch" code path, which we use only to initialize the default "GMT" zone during GUC initialization. That's critical for a couple of reasons: since we do not support leap seconds, we *must not* allow "GMT" to have leap seconds, and since this case runs before the GUC subsystem is fully alive, we'd really rather not take the risk of pg_open_tzfile throwing any errors. However, that still left the code reading TZDEFRULES on every other call, something we'd noticed to the extent of having added code to cache the result so it was only done once per process not a lot of times. Andres Freund complained about the static data space used up for the cache; but as long as the logic was like this, there was no point in trying to get rid of that space. We can improve matters by looking a bit more closely at what the IANA code actually needs the TZDEFRULES data for. One thing it does is that if "posixrules" is a leap-second-aware zone, the leap-second behavior will be absorbed into every POSIX-style zone specification. However, that's a behavior we'd really prefer to do without, since for our purposes the end effect is to render every POSIX-style zone name unsupported. Otherwise, the TZDEFRULES data is used only if the POSIX zone name specifies DST but doesn't include a transition date rule (e.g., "EST5EDT" rather than "EST5EDT,M3.2.0,M11.1.0"). That is a minority case for our purposes --- in particular, it never happens when tzload() invokes tzparse() to interpret a transition date rule string found in a tzdata zone file. Hence, if we legislate that we're going to ignore leap-second data from "posixrules", we can postpone the TZDEFRULES load into the path where we actually need to substitute for a missing date rule string. That means it will never happen at all in common scenarios, making it reasonable to dynamically allocate the cache space when it does happen. Even when the data is already loaded, this saves some cycles in the common code path since we avoid a memcpy of 23KB or so. And, IMO at least, this is a less ugly hack on the IANA logic than what we had before, since it's not messing with the lastditch-vs-regular code paths. Back-patch to all supported branches, not so much because this is a critical change as that I want to keep all our copies of the IANA timezone code in sync. Discussion: https://postgr.es/m/20181015200754.7y7zfuzsoux2c4ya@alap3.anarazel.de
* Avoid statically allocating statement cache in ecpglib/prepare.c.Tom Lane2018-10-17
| | | | | | | | This removes a megabyte of storage that isn't used at all in ecpglib's default operating mode --- you have to enable auto-prepare to get any use out of it. Seems well worth the trouble to allocate on demand. Discussion: https://postgr.es/m/20181015200754.7y7zfuzsoux2c4ya@alap3.anarazel.de
generated by cgit v1.2.3 (git 2.25.1) at 2025-07-17 03:46:49 +0000