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_baseb
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_baseb
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_baseb
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_baseb
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_baseb
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_baseb
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 machi
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(+),
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 inserti
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 inserti
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 inserti
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 inserti
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 inserti
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
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,
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
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
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
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 hand
19 matches
Mail list logo
