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
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
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,
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
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
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_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
--
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_4_STABLE
Details
---
http://git.postgresql.org/pg/commitdiff/05740485486e160066c1a31399bfafc52f69c21b
Modified Files
--
src/interfaces/ecpg/ecpglib/data.c | 3 +--
1 file changed, 1 inserti
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
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
19 matches
Mail list logo
