aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAge
...
* 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
* Improve translatability of some getObjectDescription() messages.Tom Lane2018-05-24
| | | | | | | | | | | | | | | | Refactor some cases in getObjectDescription so that the translator has more control over phrase order in the translated messages. This doesn't cause any changes in the English results. (I was sorely tempted to reorder "... belonging to role %s in schema %s" into "... in schema %s belonging to role %s", but refrained.) In principle we could back-patch this, but since translators have not complained about these cases previously, it seems better not to thrash the translatable strings in back branches. Kyotaro Horiguchi, tweaked a bit by me Discussion: https://postgr.es/m/20180522.182020.114074746.horiguchi.kyotaro@lab.ntt.co.jp
* Fix objectaddress.c code for publication relations.Tom Lane2018-05-24
| | | | | | | | | | | | | | | | | | | | getObjectDescription and getObjectIdentity failed to schema-qualify the name of the published table, which is bad in getObjectDescription and unforgivable in getObjectIdentity. Actually, getObjectIdentity failed to emit the table's name at all unless "objname" output is requested, which accidentally works for some (all?) extant callers but is clearly not the intended API. Somebody had also not gotten the memo that the output of getObjectIdentity is not to be translated. To fix getObjectDescription, I made it call getRelationDescription, which required refactoring the translatable string for the case, but is more future-proof in case we ever publish relations that aren't plain tables. While at it, I made the English output look like "publication of table X in publication Y"; the added "of" seems to me to make it read much better. Back-patch to v10 where publications were introduced. Discussion: https://postgr.es/m/20180522.182020.114074746.horiguchi.kyotaro@lab.ntt.co.jp
* Properly schema-qualify additional object types in getObjectDescription().Tom Lane2018-05-24
| | | | | | | | | | | | | | | | | Collations, conversions, extended statistics objects (in >= v10), and all four types of text search objects have schema-qualified names. getObjectDescription() ignored that and would emit just the base name of the object, potentially producing wrong or at least highly misleading output. Fix it to add the schema name whenever the object is not "visible" in the current search path, as is the rule for other schema-qualifiable object types. Although in common situations the output won't change, this seems to me (tgl) to be a bug worthy of back-patching, hence do so. Kyotaro Horiguchi, per a complaint from me Discussion: https://postgr.es/m/20180522.182020.114074746.horiguchi.kyotaro@lab.ntt.co.jp
* Preserve information on use of git-external-diffAndrew Dunstan2018-05-24
| | | | | | | | Now that the Working with git wiki page no longer suggests producing context diffs, we should preserve the information on how to use git-external-diff for those people who want to view context format diffs. The most obvious place is in the script itself, so that's what's done here.
* Fix simple_prompt() to disable echo on Windows when stdin != terminal.Tom Lane2018-05-23
| | | | | | | | | | | | | | | | | | | | If echo = false, simple_prompt() is supposed to prevent echoing the input (for password input). However, the Windows implementation applied the mode change to STD_INPUT_HANDLE. That would not have the desired effect if stdin isn't actually the terminal, for instance if the user is piping something into psql. Fix it to apply the mode change to the correct input file, so that passwords do not echo in such cases. In passing, shorten and de-uglify this code by using #elif rather than an #if nest and removing some duplicated code. Back-patch to all supported versions. To simplify that, also back-patch the portions of commit 9daec77e1 that got rid of an unnecessary malloc/free in the same area. Matthew Stickney (cosmetic changes by me) Discussion: https://postgr.es/m/502a1fff-862b-da52-1031-f68df6ed5a2d@gmail.com
* Remove configure's check for nonstandard "long long" printf modifiers.Tom Lane2018-05-23
| | | | | | | | | | | | | | | | | We used to claim to support platforms using 'q' or 'I64' as the printf length modifier for long long int, by dint of replacing snprintf with our own code which uses the C99 standard 'll' modifier. But that is only adequate if we use INT64_MODIFIER only in snprintf-based calls, not directly with the platform's native printf or fprintf. Which hasn't been the case for years. We had not noticed, partially because of inadequate test coverage, and partially because the buildfarm is almost completely bare of machines that won't take 'll'. The last one seems to have been frogmouth, which was adjusted recently so that it will take 'll'. We might as well just give up on the pretense that anything else works, and save ourselves some configure cycles. Discussion: https://postgr.es/m/13103.1526749980@sss.pgh.pa.us Discussion: https://postgr.es/m/24769.1526772680@sss.pgh.pa.us
* Fix incorrect ordering of operations in pg_resetwal and pg_rewind.Tom Lane2018-05-23
| | | | | | | | | | | | | | | | | | | | | Commit c37b3d08c dropped its added GetDataDirectoryCreatePerm call into the wrong place in pg_resetwal.c, namely after the chdir to DataDir. That broke invocations using a relative path, as reported by Tushar Ahuja. We could have left it where it was and changed the argument to be ".", but that'd result in a rather confusing error message in event of a failure, so re-ordering seems like a better solution. Similarly reorder operations in pg_rewind.c. The issue there is that it doesn't seem like a good idea to do any actual operations before the not-root check (on Unix) or the restricted token acquisition (on Windows). I don't know that this is an actual bug, but I'm definitely not convinced that it isn't, either. Assorted other code review for c37b3d08c and da9b580d8: fix some misspelled or otherwise badly worded comments, put the #include for <sys/stat.h> where it actually belongs, etc. Discussion: https://postgr.es/m/aeb9c3a7-3c3f-a57f-1a18-c8d4fcdc2a1f@enterprisedb.com
* Accept "B" in all memory-unit GUCs, and improve error messages.Heikki Linnakangas2018-05-23
| | | | | | | | | | | | | | | | | | | | Commit 6e7baa3227 added support for "B" unit, for specifying config options in bytes. However, it was only accepted in GUC_UNIT_BYTE settings, wal_segment_size and track_activity_query_size, and not e.g. in work_mem. This patch makes it consistent, so that "B" accepted in all the same contexts where "kB", "MB", and so forth are accepted. Add "B" to the list of accepted units in the error hint, along with "kB", "MB", etc. Add an entry in the conversion table for "TB" to "B" conversion. A terabyte is out of range for any GUC_UNIT_BYTE option, so you always get an "out of range" error with that, but without it, you get a confusing error message that claims that "TB" is not an accepted unit, with a hint that nevertheless lists "TB" as an accepted unit. Reviewed-by: Alexander Korotkov, Andres Freund Discussion: https://www.postgresql.org/message-id/1bfe7f4a-7e22-aa6e-7b37-f4d222ed2d67@iki.fi
* Widen COPY FROM's current-line-number counter from 32 to 64 bits.Tom Lane2018-05-22
| | | | | | | | | | | | | | | Because the code for the HEADER option skips a line when this counter is zero, a very long COPY FROM WITH HEADER operation would drop a line every 2^32 lines. A lesser but still unfortunate problem is that errors would show a wrong input line number for errors occurring beyond the 2^31'st input line. While such large input streams seemed impractical when this code was first written, they're not any more. Widening the counter (and some associated variables) to uint64 should be enough to prevent problems for the foreseeable future. David Rowley Discussion: https://postgr.es/m/CAKJS1f88yh-6wwEfO6QLEEvH3BEugOq2QX1TOja0vCauoynmOQ@mail.gmail.com
* Add missing files to src/backend/lib/README.Heikki Linnakangas2018-05-22
| | | | | | | | | The README lists all the files available in the directory, along with short descriptions of each, but a few newly added ones were missing. While we're at it, reorder the list into alphabetical order. Author: Takeshi Ideriha Discussion: https://www.postgresql.org/message-id/4E72940DA2BF16479384A86D54D0988A56793487@G01JPEXMBKW04
* Fix typo in comment.Heikki Linnakangas2018-05-22
|
* Stamp 11beta1.REL_11_BETA1Tom Lane2018-05-21
|
* Update SQL features listPeter Eisentraut2018-05-21
|
* Translation updatesPeter Eisentraut2018-05-21
| | | | | Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 3a5a71cccad5c68e01008e9e3a4f06930197a05e
* Fix SQL:2008 FETCH FIRST syntax to allow parameters.Andrew Gierth2018-05-21
| | | | | | | | | | | | | | | | | | | OFFSET <x> ROWS FETCH FIRST <y> ROWS ONLY syntax is supposed to accept <simple value specification>, which includes parameters as well as literals. When this syntax was added all those years ago, it was done inconsistently, with <x> and <y> being different subsets of the standard syntax. Rectify that by making <x> and <y> accept the same thing, and allowing either a (signed) numeric literal or a c_expr there, which allows for parameters, variables, and parenthesized arbitrary expressions. Per bug #15200 from Lukas Eder. Backpatch all the way, since this has been broken from the start. Discussion: https://postgr.es/m/877enz476l.fsf@news-spur.riddles.org.uk Discussion: http://postgr.es/m/152647780335.27204.16895288237122418685@wrigleys.postgresql.org
* Improve spelling of new FINALFUNC_MODIFY aggregate attribute.Tom Lane2018-05-21
| | | | | | | | I'd used SHARABLE as a value originally, but Peter Eisentraut points out that dictionaries agree that SHAREABLE is the preferred spelling. Run around and change that before it's too late. Discussion: https://postgr.es/m/d2e1afd4-659c-50d6-1b20-7cfd3675e909@2ndquadrant.com
* pg_basebackup: Remove short option -kPeter Eisentraut2018-05-21
| | | | | | | | -k meant --no-verify-checksums, which is the opposite of what initdb uses -k for. After discussion, a short option does not seem necessary, so just keep the long option. Discussion: https://www.postgresql.org/message-id/flat/d510f8aa-19e1-d06e-7630-ad27f7441d68%402ndquadrant.com
* Fix unsafe usage of strerror(errno) within ereport().Tom Lane2018-05-21
| | | | | | | | This is the converse of the unsafe-usage-of-%m problem: the reason ereport/elog provide that format code is mainly to dodge the hazard of errno getting changed before control reaches functions within the arguments of the macro. I only found one instance of this hazard, but it's been there since 9.4 :-(.
* Fix unportable usage of printf("%m").Tom Lane2018-05-20
| | | | | | | | | While glibc's version of printf accepts %m, most others do not; to be portable, we have to do it the hard way with strerror(errno). pg_verify_checksums evidently did not get that memo. Noted while fooling around with NetBSD-current, which generates a compiler warning for this mistake.
* printf("%lf") is not portable, so omit the "l".Tom Lane2018-05-20
| | | | | | | | | | | | The "l" (ell) width spec means something in the corresponding scanf usage, but not here. While modern POSIX says that applying "l" to "f" and other floating format specs is a no-op, SUSv2 says it's undefined. Buildfarm experience says that some old compilers emit warnings about it, and at least one old stdio implementation (mingw's "ANSI" option) actually produces wrong answers and/or crashes. Discussion: https://postgr.es/m/21670.1526769114@sss.pgh.pa.us Discussion: https://postgr.es/m/c085e1da-0d64-1c15-242d-c921f32e0d5c@dunslane.net
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-04 12:44:09 +0000