aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
...
* Fix off-by-one bug in XactLogCommitRecordAlvaro Herrera2018-06-15
| | | | | | | | | | | Commit 1eb6d6527aae introduced zeroed alignment bytes in the GID field of commit/abort WAL records. Fixup commit cf5a1890592b later changed that representation into a regular cstring with a single terminating zero byte, but it also introduced an off-by-one mistake. Fix that. Author: Nikhil Sontakke Reported-by: Nikhil Sontakke Discussion: https://postgr.es/m/CAMGcDxey6dG1DP34_tJMoWPcp5sPJUAL4K5CayUUXLQSx2GQpA@mail.gmail.com
* Fix memory leak.Tatsuo Ishii2018-06-15
| | | | | | | | Memory is allocated twice for "file" and "files" variables in BufFileOpenShared(). Author: Antonin Houska Discussion: https://postgr.es/m/11329.1529045692%40localhost
* Fail BRIN control functions during recovery explicitlyAlvaro Herrera2018-06-14
| | | | | | | | | | | They already fail anyway, but prior to this patch they raise an ugly error message about a lock that cannot be acquired. This just improves the message. Author: Masahiko Sawada Reported-by: Masahiko Sawada Discussion: https://postgr.es/m/CAD21AoBZau4g4_NUf3BKNd=CdYK+xaPdtJCzvOC1TxGdTiJx_Q@mail.gmail.com Reviewed-by: Kuntal Ghosh, Alexander Korotkov, Simon Riggs, Michaël Paquier, Álvaro Herrera
* Remove spurious code comments in standby related codeSimon Riggs2018-06-14
| | | | | | | | | GetRunningTransactionData() suggested that subxids were not worth optimizing away if overflowed, yet they have already been removed for that case. Changes to LogAccessExclusiveLock() API forgot to remove the prior comment when it was copied to LockAcquire().
* Remove cut-off bug from RunningTransactionDataSimon Riggs2018-06-14
| | | | | | | | | | 32ac7a118fc17f5 tried to fix a Hot Standby issue reported by Greg Stark, but in doing so caused a different bug to appear, noted by Andres Freund. Revoke the core changes from 32ac7a118fc17f5, leaving in its place a minor change in code ordering and comments to explain for the future.
* Code review for match_clause_to_partition_key().Tom Lane2018-06-13
| | | | | | | | | | | | | | | | | Fix inconsistent decisions about NOMATCH vs UNSUPPORTED result codes. If we're going to cater for partkeys that have the same expression and different collations, surely we should also support partkeys with the same expression and different opclasses. Clean up shaky handling of commuted opclauses, eg checking the wrong operator to see what its negator is. This wouldn't cause any actual bugs given a sane opclass definition, but it doesn't seem helpful to expend more code to be less correct. Improve handling of null elements in ScalarArrayOp arrays: in the "op ALL" case, we can conclude they result in an unsatisfiable clause. Minor cosmetic changes and comment improvements.
* Fix some ill-chosen names for globally-visible partition support functions.Tom Lane2018-06-13
| | | | | "compute_hash_value" is particularly gratuitously generic, but IMO all of these ought to have names clearly related to partitioning.
* Fix up run-time partition pruning's use of relcache's partition data.Tom Lane2018-06-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous coding saved pointers into the partitioned table's relcache entry, but then closed the relcache entry, causing those pointers to nominally become dangling. Actual trouble would be seen in the field only if a relcache flush occurred mid-query, but that's hardly out of the question. While we could fix this by copying all the data in question at query start, it seems better to just hold the relcache entry open for the whole query. While at it, improve the handling of support-function lookups: do that once per query not once per pruning test. There's still something to be desired here, in that we fail to exploit the possibility of caching data across queries in the fn_extra fields of the relcache's FmgrInfo structs, which could happen if we just used those structs in-place rather than copying them. However, combining that with the possibility of per-query lookups of cross-type comparison functions seems to require changes in the APIs of a lot of the pruning support functions, so it's too invasive to consider as part of this patch. A win would ensue only for complex partition key data types (e.g. arrays), so it may not be worth the trouble. David Rowley and Tom Lane Discussion: https://postgr.es/m/17850.1528755844@sss.pgh.pa.us
* Exclude files in .git from list of perl filesAndrew Dunstan2018-06-12
| | | | | | | | The .git directory might contain perl files, as hooks, for example. Since we have no control over these they should be excluded from things like our perlcritic checks. Per offline report from Mike Blackwell.
* Fix bugs in vacuum of shared rels, by keeping their relcache entries current.Andres Freund2018-06-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When vacuum processes a relation it uses the corresponding relcache entry's relfrozenxid / relminmxid as a cutoff for when to remove tuples etc. Unfortunately for nailed relations (i.e. critical system catalogs) bugs could frequently lead to the corresponding relcache entry being stale. This set of bugs could cause actual data corruption as vacuum would potentially not remove the correct row versions, potentially reviving them at a later point. After 699bf7d05c some corruptions in this vein were prevented, but the additional error checks could also trigger spuriously. Examples of such errors are: ERROR: found xmin ... from before relfrozenxid ... and ERROR: found multixact ... from before relminmxid ... To be caused by this bug the errors have to occur on system catalog tables. The two bugs are: 1) Invalidations for nailed relations were ignored, based on the theory that the relcache entry for such tables doesn't change. Which is largely true, except for fields like relfrozenxid etc. This means that changes to relations vacuumed in other sessions weren't picked up by already existing sessions. Luckily autovacuum doesn't have particularly longrunning sessions. 2) For shared *and* nailed relations, the shared relcache init file was never invalidated while running. That means that for such tables (e.g. pg_authid, pg_database) it's not just already existing sessions that are affected, but even new connections are as well. That explains why the reports usually were about pg_authid et. al. To fix 1), revalidate the rd_rel portion of a relcache entry when invalid. This implies a bit of extra complexity to deal with bootstrapping, but it's not too bad. The fix for 2) is simpler, simply always remove both the shared and local init files. Author: Andres Freund Reviewed-By: Alvaro Herrera Discussion: https://postgr.es/m/20180525203736.crkbg36muzxrjj5e@alap3.anarazel.de https://postgr.es/m/CAMa1XUhKSJd98JW4o9StWPrfS=11bPgG+_GDMxe25TvUY4Sugg@mail.gmail.com https://postgr.es/m/CAKMFJucqbuoDRfxPDX39WhA3vJyxweRg_zDVXzncr6+5wOguWA@mail.gmail.com https://postgr.es/m/CAGewt-ujGpMLQ09gXcUFMZaZsGJC98VXHEFbF-tpPB0fB13K+A@mail.gmail.com Backpatch: 9.3-
* Convert debug message from ereport to elogPeter Eisentraut2018-06-12
|
* Fix access to just-closed relcache entry.Tom Lane2018-06-11
| | | | | | | | | | | | It might be impossible for this to cause a problem in non-debug builds, since there'd be no opportunity for the relcache entry to get recycled before the fetch. It blows up nicely with -DRELCACHE_FORCE_RELEASE plus valgrind, though. Evidently introduced by careless refactoring in commit f0e44751d. Back-patch accordingly. Discussion: https://postgr.es/m/27543.1528758304@sss.pgh.pa.us
* Fix oversight from 9e149c8 with spin-lock handlingMichael Paquier2018-06-12
| | | | | | | | | Calling an external function while a pin-lock is held is a bad idea as those are designed to be short-lived. The stress of a first commit into a large git history may contribute to that. Reported-by: Andres Freund Discussion: https://postgr.es/m/20180611164952.vmxdpdpirdtkdsz6@alap3.anarazel.de
* Improve ExecFindInitialMatchingSubPlans's subplan renumbering logic.Tom Lane2018-06-11
| | | | | | | | | | | | We don't need two passes if we scan child partitions before parents, as that way the children's present_parts are up to date before they're needed. I (tgl) think there's actually a bug being fixed here, for the case of an intermediate partitioned table with no direct leaf children, but haven't attempted to construct a test case to prove it. David Rowley Discussion: https://postgr.es/m/CAKJS1f-6GODRNgEtdPxCnAPme2h2hTztB6LmtfdmcYAAOE0kQg@mail.gmail.com
* Improve commentary about run-time partition pruning data structures.Tom Lane2018-06-11
| | | | | | | | No code changes except for a couple of new Asserts. David Rowley and Tom Lane Discussion: https://postgr.es/m/CAKJS1f-6GODRNgEtdPxCnAPme2h2hTztB6LmtfdmcYAAOE0kQg@mail.gmail.com
* Adjust error messagePeter Eisentraut2018-06-11
| | | | | Makes it look more similar to other ones, and avoids the need for pluralization.
* Don't needlessly check the partition contraint twiceAlvaro Herrera2018-06-11
| | | | | | | | | | | | | | | | | | | | | Starting with commit f0e44751d717, ExecConstraints was in charge of running the partition constraint; commit 19c47e7c8202 modified that so that caller could request to skip that checking depending on some conditions, but that commit and 15ce775faa42 together introduced a small bug there which caused ExecInsert to request skipping the constraint check but have this not be honored -- in effect doing the check twice. This could have been fixed in a very small patch, but on further analysis of the involved function and its callsites, it turns out to be simpler to give the responsibility of checking the partition constraint fully to the caller, and return ExecConstraints to its original (pre-partitioning) shape where it only checked tuple descriptor-related constraints. Each caller must do partition constraint checking on its own schedule, which is more convenient after commit 2f178441044 anyway. Reported-by: David Rowley Author: David Rowley, Álvaro Herrera Reviewed-by: Amit Langote, Amit Khandekar, Simon Riggs Discussion: https://postgr.es/m/CAKJS1f8w8+awsxgea8wt7_UX8qzOQ=Tm1LD+U1fHqBAkXxkW2w@mail.gmail.com
* Move perlcritic files to new perlcheck directoryAndrew Dunstan2018-06-11
|
* Add a script to detect perl compile time errors and warningsAndrew Dunstan2018-06-11
| | | | | | Also add a function that centralizes the logic for locating all our perl files and use it in pgperlcritic and pgperltidy as well as the new pgperlcheck.
* Fix run-time partition pruning code to handle NULL values properly.Tom Lane2018-06-11
| | | | | | | | | | | | | | | | The previous coding just ignored pruning constraints that compare a partition key to a null-valued expression. This is silly, since really what we can do there is conclude that all partitions are rejected: the pruning operator is known strict so the comparison must always fail. This also fixes the logic to not ignore constisnull for a Const comparison value. That's probably an unreachable case, since the planner would normally have simplified away a strict operator with a constant-null input. But this code has no business assuming that. David Rowley, per a gripe from me Discussion: https://postgr.es/m/26279.1528670981@sss.pgh.pa.us
* Make new error code name match SQL standard more closelyPeter Eisentraut2018-06-11
| | | | Discussion: https://www.postgresql.org/message-id/dff3d555-bea4-ac24-29b2-29521b9d08e8%402ndquadrant.com
* Fix a couple of bugs with replication slot advancing featureMichael Paquier2018-06-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A review of the code has showed up a couple of issues fixed by this commit: - Physical slots have been using the confirmed LSN position as a start comparison point which is always 0/0, instead use the restart LSN position (logical slots need to use the confirmed LSN position, which was correct). - The actual slot update was incorrect for both physical and logical slots. Physical slots need to use their restart_lsn as base comparison point (confirmed_flush was used because of previous point), and logical slots need to begin reading WAL from restart_lsn (confirmed_flush was used as well), while confirmed_flush is compiled depending on the decoding context and record read, and is the LSN position returned back to the caller. - Never return 0/0 if a slot cannot be advanced. This way, if a slot is advanced while the activity is idle, then the same position is returned to the caller over and over without raising an error. Instead return the LSN the slot has been advanced to. With repetitive calls, the same position is returned hence caller can directly monitor the difference in progress in bytes by doing simply LSN difference calculations, which should be monotonic. Note that as the slot is owned by the backend advancing it, then the read of those fields is fine lock-less, while updates need to happen while the slot mutex is held, so fix that on the way as well. Other locks for in-memory data of replication slots have been already fixed previously. Some of those issues have been pointed out by Petr and Simon during the patch, while I noticed some of them after looking at the code. This also visibly takes of a recently-discovered bug causing assertion failures which can be triggered by a two-step slot forwarding which first advanced the slot to a WAL page boundary and secondly advanced it to the latest position, say 'FF/FFFFFFF' to make sure that the newest LSN is used as forward point. It would have been nice to drop a test for that, but the set of operators working on pg_lsn limits it, so this is left for a future exercise. Author: Michael Paquier Reviewed-by: Petr Jelinek, Simon Riggs Discussion: https://postgr.es/m/CANP8+jLyS=X-CAk59BJnsxKQfjwrmKicHQykyn52Qj-Q=9GLCw@mail.gmail.com Discussion: https://www.postgresql.org/message-id/2840048a-1184-417a-9da8-3299d207a1d7%40postgrespro.ru
* Assorted cosmetic cleanup of run-time-partition-pruning code.Tom Lane2018-06-10
| | | | | | | | | | Use "subplan" rather than "subnode" to refer to the child plans of a partitioning Append; this seems a bit more specific and hence clearer. Improve assorted comments. No non-cosmetic changes. David Rowley and Tom Lane Discussion: https://postgr.es/m/CAFj8pRBjrufA3ocDm8o4LPGNye9Y+pm1b9kCwode4X04CULG3g@mail.gmail.com
* Relocate partition pruning structs to a saner place.Tom Lane2018-06-10
| | | | | | | | | | | | | | | | These struct definitions were originally dropped into primnodes.h, which is a poor choice since that's mainly intended for primitive expression node types; these are not in that category. What they are is auxiliary info in Plan trees, so move them to plannodes.h. For consistency, also relocate some related code that was apparently placed with the aid of a dartboard. There's no interesting code changes in this commit, just reshuffling. David Rowley and Tom Lane Discussion: https://postgr.es/m/CAFj8pRBjrufA3ocDm8o4LPGNye9Y+pm1b9kCwode4X04CULG3g@mail.gmail.com
* Improve run-time partition pruning to handle any stable expression.Tom Lane2018-06-10
| | | | | | | | | | | | | The initial coding of the run-time-pruning feature only coped with cases where the partition key(s) are compared to Params. That is a bit silly; we can allow it to work with any non-Var-containing stable expression, as long as we take special care with expressions containing PARAM_EXEC Params. The code is hardly any longer this way, and it's considerably clearer (IMO at least). Per gripe from Pavel Stehule. David Rowley, whacked around a bit by me Discussion: https://postgr.es/m/CAFj8pRBjrufA3ocDm8o4LPGNye9Y+pm1b9kCwode4X04CULG3g@mail.gmail.com
* Fix and document lock handling for in-memory replication slot dataMichael Paquier2018-06-10
| | | | | | | | | | | | | | | | | | | | | | | | | | While debugging issues on HEAD for the new slot forwarding feature of Postgres 11, some monitoring of the code surrounding in-memory slot data has proved that the lock handling may cause inconsistent data to be read by read-only callers of slot functions, particularly pg_get_replication_slots() which fetches data for the system view pg_replication_slots, or modules looking directly at slot information. The code paths involved in those problems concern logical decoding initialization (down to 9.4) and WAL reservation for slots (new as of 10). A set of comments documenting all the lock handlings, particularly the dependency with LW locks for slots and the in_use flag as well as the internal mutex lock is added, based on a suggested by Simon Riggs. Some of the fixed code exists down to 9.4 where WAL decoding has been introduced, but as those race conditions are really unlikely going to happen as those concern code paths for slot and decoding creation, just fix the problem on HEAD. Author: Michael Paquier Discussion: https://postgr.es/m/20180528085747.GA27845@paquier.xyz
* Limit Parallel Hash's bucket array to MaxAllocSize.Thomas Munro2018-06-10
| | | | | | | | | | | | Make sure that we don't exceed MaxAllocSize when increasing the number of buckets. Perhaps later we'll remove that limit and use DSA_ALLOC_HUGE, but for now just prevent further increases like the non-parallel code. This change avoids the error from bug report #15225. Author: Thomas Munro Reviewed-By: Tom Lane Reported-by: Frits Jalvingh Discussion: https://postgr.es/m/152802081668.26724.16985037679312485972%40wrigleys.postgresql.org
* Fix typo in JIT README.Peter Geoghegan2018-06-09
| | | | | Author: Daniel Gustafsson Discussion: https://postgr.es/m/3747D478-41F9-439F-8074-AC81A5C76346@yesql.se
* Teach SHOW ALL to honor pg_read_all_settings membershipAlvaro Herrera2018-06-08
| | | | | | | | | | | | | | | | | Also, fix the pg_settings view to display source filename and line number when invoked by a pg_read_all_settings member. This addition by me (Álvaro). Also, fix wording of the comment in GetConfigOption regarding the restriction it implements, renaming the parameter for extra clarity. Noted by Michaël. These were all oversight in commit 25fff40798fc; backpatch to pg10, where that commit first appeared. Author: Laurenz Albe Reviewed-by: Michaël Paquier, Álvaro Herrera Discussion: https://postgr.es/m/1519917758.6586.8.camel@cybertec.at
* Fix typoPeter Eisentraut2018-06-08
|
* Add missing serial commasPeter Eisentraut2018-06-07
|
* Exclude VACUUMs from RunningXactDataSimon Riggs2018-06-07
| | | | | | | | | | | | | | | GetRunningTransactionData() should ignore VACUUM procs because in some cases they are assigned xids. This could lead to holding back xmin via the route of passing the xid to standby and then having that hold back xmin on master via feedback. Backpatch to 9.1 needed, but will only do so on supported versions. Backpatch once proven on the buildfarm. Reported-by: Greg Stark Author: Simon Riggs Reviewed-by: Amit Kapila Discussion: https://postgr.es/m/CANP8+jJBYt=4PpTfiPb0UrH1_iPhzsxKH5Op_Wec634F0ohnAw@mail.gmail.com
* Fix typo in READMEMagnus Hagander2018-06-07
| | | | Author: Daniel Gustafsson <daniel@yesql.se>
* Fix obsolete comment.Heikki Linnakangas2018-06-07
| | | | | | | | The 'orig_slot' argument was removed in commit c0a8ae7be392, but that commit forgot to update the comment. Author: Amit Langote Discussion: https://www.postgresql.org/message-id/194ac4bf-7b4a-c887-bf26-bc1a85ea995a@lab.ntt.co.jp
* Fix function code in error reportAlvaro Herrera2018-06-06
| | | | | | | | | | | | | This bug causes a lseek() failure to be reported as a "could not open" failure in the error message, muddling bug reports. I introduced this copy-and-pasteo in commit 78e122010422. Noticed while reviewing code for bug report #15221, from lily liang. In version 10 the affected function is only used by multixact.c and commit_ts, and only in corner-case circumstances, neither of which are involved in the reported bug (a pg_subtrans failure.) Author: Álvaro Herrera
* Fix spurious non-ASCII bytesPeter Eisentraut2018-06-04
|
* Fix typoPeter Eisentraut2018-06-04
|
* Put new command-line options into alphabetical orderPeter Eisentraut2018-06-04
|
* Reconcile nodes/*funcs.c with PostgreSQL 11 work.Noah Misch2018-05-31
| | | | | This covers new fields in two outfuncs.c functions having no readfuncs.c counterpart. Thus, this changes only debugging output.
* Fix compile-time warnings on all perl codeAndrew Dunstan2018-05-31
| | | | | | | | | | This patch does two things. First, it silences a number of compile-time warnings in the msvc tools files, mainly those due to the fact that in some cases we have more than one package per file. Second it supplies a dummy Perl library with just enough of the Windows API referred to in our code to let it run these checks cleanly, even on Unix machines where the code is never supposed to run. The dummy library should only be used for that purpose, as its README notes.
* Move _bt_upgrademetapage() into critical section.Teodor Sigaev2018-05-30
| | | | | | | | Any changes on page should be done in critical section, so move _bt_upgrademetapage into critical section. Improve comment. Found by Amit Kapila during post-commit review of 857f9c36. Author: Amit Kapila
* Initialize new jsonb iterator to zeroPeter Eisentraut2018-05-28
| | | | | | | Use palloc0() instead of palloc() to create a new JsonbIterator. Otherwise, the isScalar field is sometimes not initialized. There is probably no impact in practice, but it's cleaner this way and it avoids future problems.
* Return a value from Install.pm's lcopy functionAndrew Dunstan2018-05-28
| | | | | | | Commit 3a7cc727c was a little over eager about adding an explicit return to this function, whose value is checked in most call sites. This change reverses that and returns the expected value explicitly. It also adds a check to the one call site lacking one.
* Avoid use of unportable hex constant in convutils.pmAndrew Dunstan2018-05-27
| | | | Discussion: https://postgr.es/m/5a6d6de8-cff8-1ffb-946c-ccf381800ea1@2ndQuadrant.com
* Don't fall off the end of perl functionsAndrew Dunstan2018-05-27
| | | | | | | | | | | | | | | This complies with the perlcritic policy Subroutines::RequireFinalReturn, which is a severity 4 policy. Since we only currently check at severity level 5, the policy is raised to that level until we move to level 4 or lower, so that any new infringements will be caught. A small cosmetic piece of tidying of the pgperlcritic script is included. Mike Blackwell Discussion: https://postgr.es/m/CAESHdJpfFm_9wQnQ3koY3c91FoRQsO-fh02za9R3OEMndOn84A@mail.gmail.com
* Don't force a blank line before comments in perl codeAndrew Dunstan2018-05-27
| | | | | | Suggestion from Bruce Momjian Discussion: https://postgr.es/m/20180525190445.GA2213@momjian.us
* Update a couple of long-obsolete comments in pg_type.h.Tom Lane2018-05-26
|
* Fix misidentification of SQL statement type in plpgsql's exec_stmt_execsql.Tom Lane2018-05-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To distinguish SQL statements that are INSERT/UPDATE/DELETE from other ones, exec_stmt_execsql looked at the post-rewrite form of the statement rather than the original. This is problematic because it did that only during first execution of the statement (in a session), but the correct answer could change later due to addition or removal of DO INSTEAD rules during the session. That could lead to an Assert failure, as reported by Tushar Ahuja and Robert Haas. In non-assert builds, there's a hazard that we would fail to enforce STRICT behavior when we'd be expected to. That would happen if an initially present DO INSTEAD, that replaced the original statement with one of a different type, were removed; after that the statement should act "normally", including strictness enforcement, but it didn't. (The converse case of enforcing strictness when we shouldn't doesn't seem to be a hazard, as addition of a DO INSTEAD that changes the statement type would always lead to acting as though the statement returned zero rows, so that the strictness error could not fire.) To fix, inspect the original form of the statement not the post-rewrite form, making it valid to assume the answer can't change intra-session. This should lead to the same answer in every case except when there is a DO INSTEAD that changes the statement type; we will now set mod_stmt=true anyway, while we would not have done so before. That breaks the Assert in the SPI_OK_REWRITTEN code path, which expected the latter behavior. It might be all right to assert mod_stmt rather than !mod_stmt there, but I'm not entirely convinced that that'd always hold, so just remove the assertion altogether. This has been broken for a long time, so back-patch to all supported branches. Discussion: https://postgr.es/m/CA+TgmoZUrRN4xvZe_BbBn_Xp0BDwuMEue-0OyF0fJpfvU2Yc7Q@mail.gmail.com
* Update non-default collation tests for getObjectDescription() changes.Tom Lane2018-05-24
| | | | Sigh, also missed in commit b86b7bfa3. Per buildfarm.
* Improve English wording of some other getObjectDescription() messages.Tom Lane2018-05-24
| | | | | | | | | | | | | | | Print columns as "column C of <relation>" rather than "<relation> column C". This seems to read noticeably better in English, as evidenced by the regression test output changes, and the code change also makes it possible for translators to adjust the phrase order in other languages. Also change the output for OCLASS_DEFAULT from "default for %s" to "default value for %s". This seems to read better and is also more consistent with the output of, for instance, getObjectTypeDescription(). Kyotaro Horiguchi, per a complaint from me Discussion: https://postgr.es/m/20180522.182020.114074746.horiguchi.kyotaro@lab.ntt.co.jp
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-03 20:58:35 +0000