[COMMITTERS] pgsql: Message string improvements

Message string improvements Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/55c0da38be611899ae6d185b72b5ffcadc9d78c9 Modified Files -- src/bin/pg_basebackup/pg_receivexlog.c | 10 ++ src/bin/pg_basebackup/pg_recvlogical.c |2 +- src/interf

[COMMITTERS] pgsql: Fix parse tree of DROP TRANSFORM and COMMENT ON TRANSFORM

Fix parse tree of DROP TRANSFORM and COMMENT ON TRANSFORM The plain C string language name needs to be wrapped in makeString() so that the parse tree is copyable. This is detectable by -DCOPY_PARSE_PLAN_TREES. Add a test case for the COMMENT case. Also make the quoting in the error messages mor

Re: [COMMITTERS] pgsql: Change pg_seclabel.provider and pg_shseclabel.provider to type "

and...@anarazel.de (Andres Freund) writes: > On 2015-05-19 00:08:05 +, Tom Lane wrote: >> Note: for lack of a suitable testing environment, I've not really exercised >> this change. I trust the buildfarm will show up any mistakes. > Shouldn't src/test/modules/dummy_seclabel/ exercise this wit

Re: [COMMITTERS] pgsql: Change pg_seclabel.provider and pg_shseclabel.provider to type "

On 2015-05-19 00:08:05 +, Tom Lane wrote: > Note: for lack of a suitable testing environment, I've not really exercised > this change. I trust the buildfarm will show up any mistakes. Shouldn't src/test/modules/dummy_seclabel/ exercise this without further dependencies? Greetings, Andres Fr

[COMMITTERS] pgsql: Change pg_seclabel.provider and pg_shseclabel.provider to type "

Change pg_seclabel.provider and pg_shseclabel.provider to type "name". These were "text", but that's a bad idea because it has collation-dependent ordering. No index in template0 should have collation-dependent ordering, especially not indexes on shared catalogs. There was general agreement that

[COMMITTERS] pgsql: Attach ON CONFLICT SET ... WHERE to the correct planstate.

Attach ON CONFLICT SET ... WHERE to the correct planstate. The previous coding was a leftover from attempting to hang all the on conflict logic onto modify table's child nodes. It appears to not have actually caused problems except for explain. Add test exercising the broken and some other code p

Re: [COMMITTERS] pgsql: Separate block sampling functions

I wrote: > Andrew Dunstan writes: >> What is the current state of this? Are we sticking with what Tom >> classified as drive-by breakage? > Since I was the one complaining, I'm willing to do the legwork to > insert a compatibility shim. I probably won't get to it today though, > this being rele

[COMMITTERS] pgsql: Put back a backwards-compatible version of sampling support func

Put back a backwards-compatible version of sampling support functions. Commit 83e176ec18d2a91dbea1d0d1bd94c38dc47cd77c removed the longstanding support functions for block sampling without any consideration of the impact this would have on third-party FDWs. The new API is not notably more functio

[COMMITTERS] pgsql: Don't MultiXactIdIsRunning when in recovery

Don't MultiXactIdIsRunning when in recovery In 9.1 and earlier, it is possible for index_getnext() to try to examine a heap buffer for possible HOT-prune when in recovery; this causes a problem when a multixact is found in a tuple's Xmax, because GetMultiXactIdMembers refuses to run when in recove

[COMMITTERS] pgsql: Don't MultiXactIdIsRunning when in recovery

Don't MultiXactIdIsRunning when in recovery In 9.1 and earlier, it is possible for index_getnext() to try to examine a heap buffer for possible HOT-prune when in recovery; this causes a problem when a multixact is found in a tuple's Xmax, because GetMultiXactIdMembers refuses to run when in recove

[COMMITTERS] pgsql: Don't MultiXactIdIsRunning when in recovery

Don't MultiXactIdIsRunning when in recovery In 9.1 and earlier, it is possible for index_getnext() to try to examine a heap buffer for possible HOT-prune when in recovery; this causes a problem when a multixact is found in a tuple's Xmax, because GetMultiXactIdMembers refuses to run when in recove

[COMMITTERS] pgsql: Stamp 9.0.20.

Stamp 9.0.20. Branch -- REL9_0_STABLE Details --- http://git.postgresql.org/pg/commitdiff/730912f9a3111ead7200756eca14fedf44a449e9 Modified Files -- configure| 18 +- configure.in |2 +- doc/bug.template

[COMMITTERS] pgsql: Stamp 9.1.16.

Stamp 9.1.16. Branch -- REL9_1_STABLE Details --- http://git.postgresql.org/pg/commitdiff/46c877ee466ba213ae31ddee0b61b03fc12d90f7 Modified Files -- configure| 18 +- configure.in |2 +- doc/bug.template

[COMMITTERS] pgsql: Stamp 9.2.11.

Stamp 9.2.11. Branch -- REL9_2_STABLE Details --- http://git.postgresql.org/pg/commitdiff/520fecfae5681bf6974156d7c50bd9fe3cd9f3f1 Modified Files -- configure| 18 +- configure.in |2 +- doc/bug.template

[COMMITTERS] pgsql: Stamp 9.3.7.

Stamp 9.3.7. Branch -- REL9_3_STABLE Details --- http://git.postgresql.org/pg/commitdiff/8c479a8c7ba908f932df29966598341de1a989c1 Modified Files -- configure| 18 +- configure.in |2 +- doc/bug.template

[COMMITTERS] pgsql: Stamp 9.4.2.

Stamp 9.4.2. Branch -- REL9_4_STABLE Details --- http://git.postgresql.org/pg/commitdiff/7aeba23ee2cab86c78a80e3face3ca62ca87b5d7 Modified Files -- configure| 18 +- configure.in |2 +- doc/bug.template

Re: [COMMITTERS] pgsql: Recognize "REGRESS_OPTS += ..." syntax in MSVC build scripts.

Michael Paquier writes: > On Tue, May 19, 2015 at 2:40 AM, Tom Lane wrote: >> Recognize "REGRESS_OPTS += ..." syntax in MSVC build scripts. >> >> Necessitated by commit b14cf229f4bd7238be2e31d873dc5dd241d3871e. >> Per buildfarm. > Perhaps \+? could be spread to REGRESS as well in fetchTests? I

Re: [COMMITTERS] pgsql: Recognize "REGRESS_OPTS += ..." syntax in MSVC build scripts.

On Tue, May 19, 2015 at 2:40 AM, Tom Lane wrote: > Recognize "REGRESS_OPTS += ..." syntax in MSVC build scripts. > > Necessitated by commit b14cf229f4bd7238be2e31d873dc5dd241d3871e. > Per buildfarm. Perhaps \+? could be spread to REGRESS as well in fetchTests? -- Michael -- Sent via pgsql-com

[COMMITTERS] pgsql: Recognize "REGRESS_OPTS += ..." syntax in MSVC build scripts.

Recognize "REGRESS_OPTS += ..." syntax in MSVC build scripts. Necessitated by commit b14cf229f4bd7238be2e31d873dc5dd241d3871e. Per buildfarm. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/f5916bb7b53f8a77c95c00c5b287659958891178 Modified Files -- src/t

Re: [COMMITTERS] pgsql: Separate block sampling functions

On 18 May 2015 at 10:53, Tom Lane wrote: > Andrew Dunstan writes: > > What is the current state of this? Are we sticking with what Tom > > classified as drive-by breakage? > > Since I was the one complaining, I'm willing to do the legwork to > insert a compatibility shim. I probably won't get t

[COMMITTERS] pgsql: Fix error message in pre_sync_fname.

Fix error message in pre_sync_fname. The old one didn't include %m anywhere, and required extra translation. Report by Peter Eisentraut. Fix by me. Review by Tom Lane. Branch -- REL9_4_STABLE Details --- http://git.postgresql.org/pg/commitdiff/20affd62e22d5bbf2d945dd25920d1aa54844933 M

Re: [COMMITTERS] pgsql: Recursively fsync() the data directory after a crash.

On Mon, May 18, 2015 at 1:00 PM, Alvaro Herrera wrote: > Robert Haas wrote: >> On Mon, May 18, 2015 at 12:39 PM, Tom Lane wrote: > >> >> Uh, doesn't that change the translated strings? Is that a problem? >> > >> > Better an untranslated message than a translated one that lacks critical >> > info

[COMMITTERS] pgsql: Fix error message in pre_sync_fname.

Fix error message in pre_sync_fname. The old one didn't include %m anywhere, and required extra translation. Report by Peter Eisentraut. Fix by me. Review by Tom Lane. Branch -- REL9_1_STABLE Details --- http://git.postgresql.org/pg/commitdiff/b965c808ab8189be5716f9572c6d00124767ed80 M

[COMMITTERS] pgsql: Fix error message in pre_sync_fname.

Fix error message in pre_sync_fname. The old one didn't include %m anywhere, and required extra translation. Report by Peter Eisentraut. Fix by me. Review by Tom Lane. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/922de19ef25e559b1a7ad5c583ee4439e53cae98 Modified

[COMMITTERS] pgsql: Fix error message in pre_sync_fname.

Fix error message in pre_sync_fname. The old one didn't include %m anywhere, and required extra translation. Report by Peter Eisentraut. Fix by me. Review by Tom Lane. Branch -- REL9_3_STABLE Details --- http://git.postgresql.org/pg/commitdiff/8388680ce4fedbd4054f1a651d705bc191343a06 M

[COMMITTERS] pgsql: Fix error message in pre_sync_fname.

Fix error message in pre_sync_fname. The old one didn't include %m anywhere, and required extra translation. Report by Peter Eisentraut. Fix by me. Review by Tom Lane. Branch -- REL9_0_STABLE Details --- http://git.postgresql.org/pg/commitdiff/89c8fb65b22346f64849a719aea79a4f817193f0 M

[COMMITTERS] pgsql: Fix error message in pre_sync_fname.

Fix error message in pre_sync_fname. The old one didn't include %m anywhere, and required extra translation. Report by Peter Eisentraut. Fix by me. Review by Tom Lane. Branch -- REL9_2_STABLE Details --- http://git.postgresql.org/pg/commitdiff/b9215bc5d05a31ce056e7abb2c73cd864e6d0811 M

Re: [COMMITTERS] pgsql: Recursively fsync() the data directory after a crash.

Robert Haas wrote: > On Mon, May 18, 2015 at 12:39 PM, Tom Lane wrote: > >> Uh, doesn't that change the translated strings? Is that a problem? > > > > Better an untranslated message than a translated one that lacks critical > > info. But anyway, there are likely other instances of that same str

Re: [COMMITTERS] pgsql: Recursively fsync() the data directory after a crash.

Robert Haas writes: > On Mon, May 18, 2015 at 12:39 PM, Tom Lane wrote: >> Better an untranslated message than a translated one that lacks critical >> info. But anyway, there are likely other instances of that same string >> *with* %m ... > Probably not, because of the way the message is worded

Re: [COMMITTERS] pgsql: Recursively fsync() the data directory after a crash.

On Mon, May 18, 2015 at 12:39 PM, Tom Lane wrote: > Bruce Momjian writes: >> On Mon, May 18, 2015 at 12:15:03PM -0400, Tom Lane wrote: >>> It's a trivial enough change that I wouldn't see a problem with doing it >>> now. But if you do, please get it in by say 2PM EDT. > >> Uh, doesn't that chang

Re: [COMMITTERS] pgsql: Recursively fsync() the data directory after a crash.

Bruce Momjian writes: > On Mon, May 18, 2015 at 12:15:03PM -0400, Tom Lane wrote: >> It's a trivial enough change that I wouldn't see a problem with doing it >> now. But if you do, please get it in by say 2PM EDT. > Uh, doesn't that change the translated strings? Is that a problem? Better an u

Re: [COMMITTERS] pgsql: Recursively fsync() the data directory after a crash.

On Mon, May 18, 2015 at 12:15:03PM -0400, Tom Lane wrote: > Robert Haas writes: > > On Mon, May 18, 2015 at 11:04 AM, Tom Lane wrote: > >> Huh? All the ones that are reporting kernel call failures certainly > >> have %m. > > > Oops, you're right. I was looking at the wrong code. Yeah, that >

Re: [COMMITTERS] pgsql: Recursively fsync() the data directory after a crash.

Robert Haas writes: > On Mon, May 18, 2015 at 11:04 AM, Tom Lane wrote: >> Huh? All the ones that are reporting kernel call failures certainly >> have %m. > Oops, you're right. I was looking at the wrong code. Yeah, that > should probably be fixed. I'm not sure it's a good idea to do that >

Re: [COMMITTERS] pgsql: Recursively fsync() the data directory after a crash.

On Mon, May 18, 2015 at 11:04 AM, Tom Lane wrote: > Robert Haas writes: >> On Sun, May 17, 2015 at 9:44 PM, Peter Eisentraut wrote: >>> If there a reason why in pre_sync_fname(), the error message does not >>> contain a %m? > >> For consistency with the rest of the file, I suppose. Not sure why

Re: [COMMITTERS] pgsql: hstore_plpython: Fix regression tests under Python 3

Peter Eisentraut writes: > hstore_plpython: Fix regression tests under Python 3 jaguarundi's latest results say we're not quite done with this :-( http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jaguarundi&dt=2015-05-17%2018%3A42%3A03 although I have no idea why this run failed when the

Re: [COMMITTERS] pgsql: Recursively fsync() the data directory after a crash.

Robert Haas writes: > On Sun, May 17, 2015 at 9:44 PM, Peter Eisentraut wrote: >> If there a reason why in pre_sync_fname(), the error message does not >> contain a %m? > For consistency with the rest of the file, I suppose. Not sure why > it's like that, but all the functions in the file do it

Re: [COMMITTERS] pgsql: Separate block sampling functions

Andrew Dunstan writes: > What is the current state of this? Are we sticking with what Tom > classified as drive-by breakage? Since I was the one complaining, I'm willing to do the legwork to insert a compatibility shim. I probably won't get to it today though, this being release wrap day. In t

Re: [COMMITTERS] pgsql: Separate block sampling functions

On 05/15/2015 07:44 AM, Andrew Dunstan wrote: On 05/15/2015 06:04 AM, Simon Riggs wrote: On 15 May 2015 at 04:59, Tom Lane > wrote: The difference there was that that was specifically adding a new feature of value to FDWs. This is just drive-by breakage

[COMMITTERS] pgsql: Permit use of vsprintf() in PostgreSQL code.

Permit use of vsprintf() in PostgreSQL code. The next commit needs it. Back-patch to 9.0 (all supported versions). Branch -- REL9_0_STABLE Details --- http://git.postgresql.org/pg/commitdiff/19f7adc0137fdd1fb20f1e59d4ced1ac19b67ecf Modified Files -- src/include/port.h |

[COMMITTERS] pgsql: Permit use of vsprintf() in PostgreSQL code.

Permit use of vsprintf() in PostgreSQL code. The next commit needs it. Back-patch to 9.0 (all supported versions). Branch -- REL9_1_STABLE Details --- http://git.postgresql.org/pg/commitdiff/b544dcdad219cbd14837b149f63e3703952c992f Modified Files -- src/include/port.h |

[COMMITTERS] pgsql: Permit use of vsprintf() in PostgreSQL code.

Permit use of vsprintf() in PostgreSQL code. The next commit needs it. Back-patch to 9.0 (all supported versions). Branch -- REL9_2_STABLE Details --- http://git.postgresql.org/pg/commitdiff/1e6652aea503b16ea99662832d07241bf47f21f3 Modified Files -- src/include/port.h |

[COMMITTERS] pgsql: Permit use of vsprintf() in PostgreSQL code.

Permit use of vsprintf() in PostgreSQL code. The next commit needs it. Back-patch to 9.0 (all supported versions). Branch -- REL9_4_STABLE Details --- http://git.postgresql.org/pg/commitdiff/f7c4fe7d95a3f323df3b0dc3b5fa9d708a0c Modified Files -- src/include/port.h |

[COMMITTERS] pgsql: Permit use of vsprintf() in PostgreSQL code.

Permit use of vsprintf() in PostgreSQL code. The next commit needs it. Back-patch to 9.0 (all supported versions). Branch -- REL9_3_STABLE Details --- http://git.postgresql.org/pg/commitdiff/d5abbd11479d1bc2e1439d3764251f9cb3b60755 Modified Files -- src/include/port.h |

[COMMITTERS] pgsql: Permit use of vsprintf() in PostgreSQL code.

Permit use of vsprintf() in PostgreSQL code. The next commit needs it. Back-patch to 9.0 (all supported versions). Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/cac18a76bb6b08f1ecc2a85e46c9d2ab82dd9d23 Modified Files -- src/include/port.h |6

[COMMITTERS] pgsql: Translation updates

Translation updates Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 7da40afeb612deb39a77da4071ea1d5800706863 Branch -- REL9_2_STABLE Details --- http://git.postgresql.org/pg/commitdiff/6f8b6abd97711ea4f5f4f7bf92d93d32156e15d4 Modified Files -

[COMMITTERS] pgsql: Translation updates

Translation updates Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 3ce9e5ca72c3948b4c592e82a5ddb9b69b97d14b Branch -- REL9_3_STABLE Details --- http://git.postgresql.org/pg/commitdiff/b9403dedc5b157801c19bcba1a135aac7cef2d4a Modified Files -

[COMMITTERS] pgsql: Translation updates

Translation updates Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 3fd92c72461f8fa03989609f4f2513fe1d865582 Branch -- REL9_1_STABLE Details --- http://git.postgresql.org/pg/commitdiff/b584e45c9d9b70fba06ade7279763acf49e8af14 Modified Files -

[COMMITTERS] pgsql: Translation updates

Translation updates Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: d5e6d568c213297ebd5530ad14fb26d75ed66c25 Branch -- REL9_4_STABLE Details --- http://git.postgresql.org/pg/commitdiff/05da36196f559b9fcf016fa6a70dfd33d6936a78 Modified Files -

[COMMITTERS] pgsql: Translation updates

Translation updates Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 511b3ec7bc5df139d5516d89767238be682aa5ca Branch -- REL9_0_STABLE Details --- http://git.postgresql.org/pg/commitdiff/69cb7b977bfddcdf7e14b93c550fa810eca4876b Modified Files -

Re: [COMMITTERS] pgsql: Recursively fsync() the data directory after a crash.

On Sun, May 17, 2015 at 9:44 PM, Peter Eisentraut wrote: > On 5/4/15 2:23 PM, Robert Haas wrote: >> Recursively fsync() the data directory after a crash. >> >> Otherwise, if there's another crash, some writes from after the first >> crash might make it to disk while writes from before the crash fa

[COMMITTERS] pgsql: Fix typo in comment.

Fix typo in comment. Jim Nasby Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/8cc7a4c5fdbe43b9b16b4cf3e07c8115107a8d4e Modified Files -- src/backend/executor/nodeIndexscan.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- Sent via pgsq

Re: [COMMITTERS] pgsql: Add archive_mode='always' option.

On 05/18/2015 09:46 AM, Fujii Masao wrote: On Sat, May 16, 2015 at 12:55 AM, Heikki Linnakangas wrote: -/* If we have lost the stats collector, try to start a new one */ -if (PgStatPID == 0 && pmState == PM_RUN) -PgStatPID = pgstat_start(); Seems the above code which

[COMMITTERS] pgsql: Put back stats-collector restarting code, removed accidentally.

Put back stats-collector restarting code, removed accidentally. Removed that code snippet accidentally in the archive_mode='always' patch. Also, use varname-tags for archive_command in the docs. Fujii Masao Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/4df1328950