[COMMITTERS] pgsql: Fix pg_basebackup so that it accepts 0 as a valid compression le
Fix pg_basebackup so that it accepts 0 as a valid compression level. The help message for pg_basebackup specifies that the numbers 0 through 9 are accepted as valid values of -Z option. But, previously -Z 0 was rejected as an invalid compression level. Per discussion, it's better to make pg_basebackup treat 0 as valid compression level meaning no compression, like pg_dump. Back-patch to all supported versions. Reported-By: Jeff Janes Reviewed-By: Amit Kapila Discussion: CAMkU=1x+GwjSayc57v6w87ij6iRGFWt=hvfm0b64b1_bpvk...@mail.gmail.com Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/928e92fda30fa61688534802c849797c9986dc4c Modified Files -- doc/src/sgml/ref/pg_basebackup.sgml | 2 +- src/bin/pg_basebackup/pg_basebackup.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix pg_basebackup so that it accepts 0 as a valid compression le
Fix pg_basebackup so that it accepts 0 as a valid compression level. The help message for pg_basebackup specifies that the numbers 0 through 9 are accepted as valid values of -Z option. But, previously -Z 0 was rejected as an invalid compression level. Per discussion, it's better to make pg_basebackup treat 0 as valid compression level meaning no compression, like pg_dump. Back-patch to all supported versions. Reported-By: Jeff Janes Reviewed-By: Amit Kapila Discussion: CAMkU=1x+GwjSayc57v6w87ij6iRGFWt=hvfm0b64b1_bpvk...@mail.gmail.com Branch -- REL9_2_STABLE Details --- http://git.postgresql.org/pg/commitdiff/a216177599928d409d90fe06678e1cc6fb2be234 Modified Files -- doc/src/sgml/ref/pg_basebackup.sgml | 2 +- src/bin/pg_basebackup/pg_basebackup.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix pg_basebackup so that it accepts 0 as a valid compression le
Fix pg_basebackup so that it accepts 0 as a valid compression level. The help message for pg_basebackup specifies that the numbers 0 through 9 are accepted as valid values of -Z option. But, previously -Z 0 was rejected as an invalid compression level. Per discussion, it's better to make pg_basebackup treat 0 as valid compression level meaning no compression, like pg_dump. Back-patch to all supported versions. Reported-By: Jeff Janes Reviewed-By: Amit Kapila Discussion: CAMkU=1x+GwjSayc57v6w87ij6iRGFWt=hvfm0b64b1_bpvk...@mail.gmail.com Branch -- REL9_1_STABLE Details --- http://git.postgresql.org/pg/commitdiff/366f4a96248dc85a37b17c78ce41d2a531377ba0 Modified Files -- doc/src/sgml/ref/pg_basebackup.sgml | 2 +- src/bin/pg_basebackup/pg_basebackup.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix pg_basebackup so that it accepts 0 as a valid compression le
Fix pg_basebackup so that it accepts 0 as a valid compression level. The help message for pg_basebackup specifies that the numbers 0 through 9 are accepted as valid values of -Z option. But, previously -Z 0 was rejected as an invalid compression level. Per discussion, it's better to make pg_basebackup treat 0 as valid compression level meaning no compression, like pg_dump. Back-patch to all supported versions. Reported-By: Jeff Janes Reviewed-By: Amit Kapila Discussion: CAMkU=1x+GwjSayc57v6w87ij6iRGFWt=hvfm0b64b1_bpvk...@mail.gmail.com Branch -- REL9_4_STABLE Details --- http://git.postgresql.org/pg/commitdiff/dbe56f2a1d8774b38e0277eb13e1cf4585ba489c Modified Files -- doc/src/sgml/ref/pg_basebackup.sgml | 2 +- src/bin/pg_basebackup/pg_basebackup.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix pg_basebackup so that it accepts 0 as a valid compression le
Fix pg_basebackup so that it accepts 0 as a valid compression level. The help message for pg_basebackup specifies that the numbers 0 through 9 are accepted as valid values of -Z option. But, previously -Z 0 was rejected as an invalid compression level. Per discussion, it's better to make pg_basebackup treat 0 as valid compression level meaning no compression, like pg_dump. Back-patch to all supported versions. Reported-By: Jeff Janes Reviewed-By: Amit Kapila Discussion: CAMkU=1x+GwjSayc57v6w87ij6iRGFWt=hvfm0b64b1_bpvk...@mail.gmail.com Branch -- REL9_3_STABLE Details --- http://git.postgresql.org/pg/commitdiff/013f423729a8e7b75bbb80db5212fe320a146343 Modified Files -- doc/src/sgml/ref/pg_basebackup.sgml | 2 +- src/bin/pg_basebackup/pg_basebackup.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix pg_basebackup so that it accepts 0 as a valid compression le
Fix pg_basebackup so that it accepts 0 as a valid compression level. The help message for pg_basebackup specifies that the numbers 0 through 9 are accepted as valid values of -Z option. But, previously -Z 0 was rejected as an invalid compression level. Per discussion, it's better to make pg_basebackup treat 0 as valid compression level meaning no compression, like pg_dump. Back-patch to all supported versions. Reported-By: Jeff Janes Reviewed-By: Amit Kapila Discussion: CAMkU=1x+GwjSayc57v6w87ij6iRGFWt=hvfm0b64b1_bpvk...@mail.gmail.com Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/74d8c95b7456faefdd4244acf854361711fb42ce Modified Files -- doc/src/sgml/ref/pg_basebackup.sgml | 2 +- src/bin/pg_basebackup/pg_basebackup.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: doc: mention dependency on collation libraries
Re: Bruce Momjian 2016-07-26 <[email protected]> > I mentioned snapshot restore and replication as a way to highlight that > it is binary transfer that is the problem, not pg_dump. > > You are right about pg_upgrade not fixing the problem, but since it only > runs on the same machine, I don't see it as a good example. Ok, go for it! Christoph -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fixed array checking code for "unsigned long long" datatypes in
Fixed array checking code for "unsigned long long" datatypes in libecpg. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/3ebc88e568053fa16766e05155eb005cc72978db Modified Files -- src/interfaces/ecpg/ecpglib/data.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fixed array checking code for "unsigned long long" datatypes in
Fixed array checking code for "unsigned long long" datatypes in libecpg. Branch -- REL9_2_STABLE Details --- http://git.postgresql.org/pg/commitdiff/295edbecf73eb479257077c4c70e36f55ee6d3ef Modified Files -- src/interfaces/ecpg/ecpglib/data.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fixed array checking code for "unsigned long long" datatypes in
Fixed array checking code for "unsigned long long" datatypes in libecpg. Branch -- REL9_4_STABLE Details --- http://git.postgresql.org/pg/commitdiff/05740485486e160066c1a31399bfafc52f69c21b Modified Files -- src/interfaces/ecpg/ecpglib/data.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fixed array checking code for "unsigned long long" datatypes in
Fixed array checking code for "unsigned long long" datatypes in libecpg. Branch -- REL9_3_STABLE Details --- http://git.postgresql.org/pg/commitdiff/3ca359426c09d4a928f4603f531bed2f46648bcb Modified Files -- src/interfaces/ecpg/ecpglib/data.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fixed array checking code for "unsigned long long" datatypes in
Fixed array checking code for "unsigned long long" datatypes in libecpg. Branch -- REL9_1_STABLE Details --- http://git.postgresql.org/pg/commitdiff/c15f502b642386ea9aaf7f9cb0c5c07ef1c9f27b Modified Files -- src/interfaces/ecpg/ecpglib/data.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fixed array checking code for "unsigned long long" datatypes in
Fixed array checking code for "unsigned long long" datatypes in libecpg. Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/dc6b20c6bed779399ddc8da53de3e1749666a098 Modified Files -- src/interfaces/ecpg/ecpglib/data.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: pg_rewind docs: clarify handling of remote servers
pg_rewind docs: clarify handling of remote servers Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/878bd9accb553f6eee32af8acdb7ee3e54a74e23 Modified Files -- doc/src/sgml/ref/pg_rewind.sgml | 94 + 1 file changed, 49 insertions(+), 45 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Remove unused arguments from pg_replication_origin_xact_reset fu
Remove unused arguments from pg_replication_origin_xact_reset function. The document specifies that pg_replication_origin_xact_reset function doesn't have any argument variables. But previously it was actually defined so as to have two argument variables, though they were not used at all. That is, the pg_proc entry for that function was incorrect. This patch fixes the pg_proc entry and removes those two arguments from the function definition. No back-patch because this change needs a catalog version bump although the issue exists in 9.5 as well. Instead, a note about those unused argument variables will be added to 9.5 document later. Catalog version bumped due to the change of pg_proc. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/dd5eb805d5e5384963f09c9986845a544ef41810 Modified Files -- src/include/catalog/catversion.h | 2 +- src/include/catalog/pg_proc.h| 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Don't CHECK_FOR_INTERRUPTS between WaitLatch and ResetLatch.
Don't CHECK_FOR_INTERRUPTS between WaitLatch and ResetLatch. This coding pattern creates a race condition, because if an interesting interrupt happens after we've checked InterruptPending but before we reset our latch, the latch-setting done by the signal handler would get lost, and then we might block at WaitLatch in the next iteration without ever noticing the interrupt condition. You can put the CHECK_FOR_INTERRUPTS before WaitLatch or after ResetLatch, but not between them. Aside from fixing the bugs, add some explanatory comments to latch.h to perhaps forestall the next person from making the same mistake. In HEAD, also replace gather_readnext's direct call of HandleParallelMessages with CHECK_FOR_INTERRUPTS. It does not seem clean or useful for this one caller to bypass ProcessInterrupts and go straight to HandleParallelMessages; not least because that fails to consider the InterruptPending flag, resulting in useless work both here (if InterruptPending isn't set) and in the next CHECK_FOR_INTERRUPTS call (if it is). This thinko seems to have been introduced in the initial coding of storage/ipc/shm_mq.c (commit ec9037df2), and then blindly copied into all the subsequent parallel-query support logic. Back-patch relevant hunks to 9.4 to extirpate the error everywhere. Discussion: <[email protected]> Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/887feefe87b9099c2967ec31ce20df4dfa9b Modified Files -- src/backend/executor/nodeGather.c| 5 ++--- src/backend/libpq/pqmq.c | 2 +- src/backend/storage/ipc/shm_mq.c | 18 +- src/include/storage/latch.h | 16 src/test/modules/test_shm_mq/setup.c | 6 +++--- src/test/modules/test_shm_mq/test.c | 2 +- 6 files changed, 32 insertions(+), 17 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Don't CHECK_FOR_INTERRUPTS between WaitLatch and ResetLatch.
Don't CHECK_FOR_INTERRUPTS between WaitLatch and ResetLatch. This coding pattern creates a race condition, because if an interesting interrupt happens after we've checked InterruptPending but before we reset our latch, the latch-setting done by the signal handler would get lost, and then we might block at WaitLatch in the next iteration without ever noticing the interrupt condition. You can put the CHECK_FOR_INTERRUPTS before WaitLatch or after ResetLatch, but not between them. Aside from fixing the bugs, add some explanatory comments to latch.h to perhaps forestall the next person from making the same mistake. In HEAD, also replace gather_readnext's direct call of HandleParallelMessages with CHECK_FOR_INTERRUPTS. It does not seem clean or useful for this one caller to bypass ProcessInterrupts and go straight to HandleParallelMessages; not least because that fails to consider the InterruptPending flag, resulting in useless work both here (if InterruptPending isn't set) and in the next CHECK_FOR_INTERRUPTS call (if it is). This thinko seems to have been introduced in the initial coding of storage/ipc/shm_mq.c (commit ec9037df2), and then blindly copied into all the subsequent parallel-query support logic. Back-patch relevant hunks to 9.4 to extirpate the error everywhere. Discussion: <[email protected]> Branch -- REL9_4_STABLE Details --- http://git.postgresql.org/pg/commitdiff/45e5496042c86e49ed5395573251b7c955de3b62 Modified Files -- src/backend/storage/ipc/shm_mq.c | 18 +- src/include/storage/latch.h | 16 2 files changed, 25 insertions(+), 9 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Don't CHECK_FOR_INTERRUPTS between WaitLatch and ResetLatch.
Don't CHECK_FOR_INTERRUPTS between WaitLatch and ResetLatch. This coding pattern creates a race condition, because if an interesting interrupt happens after we've checked InterruptPending but before we reset our latch, the latch-setting done by the signal handler would get lost, and then we might block at WaitLatch in the next iteration without ever noticing the interrupt condition. You can put the CHECK_FOR_INTERRUPTS before WaitLatch or after ResetLatch, but not between them. Aside from fixing the bugs, add some explanatory comments to latch.h to perhaps forestall the next person from making the same mistake. In HEAD, also replace gather_readnext's direct call of HandleParallelMessages with CHECK_FOR_INTERRUPTS. It does not seem clean or useful for this one caller to bypass ProcessInterrupts and go straight to HandleParallelMessages; not least because that fails to consider the InterruptPending flag, resulting in useless work both here (if InterruptPending isn't set) and in the next CHECK_FOR_INTERRUPTS call (if it is). This thinko seems to have been introduced in the initial coding of storage/ipc/shm_mq.c (commit ec9037df2), and then blindly copied into all the subsequent parallel-query support logic. Back-patch relevant hunks to 9.4 to extirpate the error everywhere. Discussion: <[email protected]> Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/8ef3d9fae496d80fc1d100d49b46891ae9c2c0fc Modified Files -- src/backend/libpq/pqmq.c | 2 +- src/backend/storage/ipc/shm_mq.c | 18 +- src/include/storage/latch.h | 16 src/test/modules/test_shm_mq/setup.c | 6 +++--- src/test/modules/test_shm_mq/test.c | 2 +- 5 files changed, 30 insertions(+), 14 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Minor cleanup for access/transam/parallel.c.
Minor cleanup for access/transam/parallel.c. ParallelMessagePending *must* be marked volatile, because it's set by a signal handler. On the other hand, it's pointless for HandleParallelMessageInterrupt to save/restore errno; that must be, and is, done at the outer level of the SIGUSR1 signal handler. Calling CHECK_FOR_INTERRUPTS() inside HandleParallelMessages, which itself is called from CHECK_FOR_INTERRUPTS(), seems both useless and hazardous. The comment claiming that this is needed to handle the error queue going away is certainly misguided, in any case. Improve a couple of error message texts, and use ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE to report loss of parallel worker connection, since that's what's used in e.g. tqueue.c. (Maybe it would be worth inventing a dedicated ERRCODE for this type of failure? But I do not think ERRCODE_INTERNAL_ERROR is appropriate.) Minor stylistic cleanups. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/a5fe473ad79d8d2c85a625621c165e8c601274e4 Modified Files -- src/backend/access/transam/parallel.c | 25 - src/include/access/parallel.h | 13 ++--- 2 files changed, 18 insertions(+), 20 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
