[COMMITTERS] pgsql: Fix thinkos in BRIN summarization

Fix thinkos in BRIN summarization The previous commit contained a thinko that made a single-range summarization request process from there to end of table. Fix by setting the correct end range point. Per buildfarm. Branch -- master Details ---

[COMMITTERS] pgsql: Fix thinkos in BRIN summarization

Fix thinkos in BRIN summarization The previous commit contained a thinko that made a single-range summarization request process from there to end of table. Fix by setting the correct end range point. Per buildfarm. Branch -- REL_10_STABLE Details ---

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

Peter Geoghegan wrote: > Andres Freund wrote: > > Staring at the vacuumlazy hunk I think I might have found a related bug: > > heap_update_tuple() just copies the old xmax to the new tuple's xmax if > > a multixact and still running. It does so without verifying liveliness >

Re: [COMMITTERS] pgsql: Fix BRIN summarization concurrent with extension

Tom Lane wrote: > Alvaro Herrera <alvhe...@alvh.no-ip.org> writes: > > Fix BRIN summarization concurrent with extension > > Buildfarm is entirely unhappy ... Will fix shortly. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x

[COMMITTERS] pgsql: Fix BRIN summarization concurrent with extension

Fix BRIN summarization concurrent with extension If a process is extending a table concurrently with some BRIN summarization process, it is possible for the latter to miss pages added by the former because the number of pages is computed ahead of time. Fix by determining a fresh relation size

[COMMITTERS] pgsql: Fix BRIN summarization concurrent with extension

Fix BRIN summarization concurrent with extension If a process is extending a table concurrently with some BRIN summarization process, it is possible for the latter to miss pages added by the former because the number of pages is computed ahead of time. Fix by determining a fresh relation size

[COMMITTERS] pgsql: Fix BRIN summarization concurrent with extension

Fix BRIN summarization concurrent with extension If a process is extending a table concurrently with some BRIN summarization process, it is possible for the latter to miss pages added by the former because the number of pages is computed ahead of time. Fix by determining a fresh relation size

[COMMITTERS] pgsql: Fix BRIN summarization concurrent with extension

Fix BRIN summarization concurrent with extension If a process is extending a table concurrently with some BRIN summarization process, it is possible for the latter to miss pages added by the former because the number of pages is computed ahead of time. Fix by determining a fresh relation size

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

Stephen Frost wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > Andres Freund writes: > > > Do we care about people upgrading to unreleased versions? We could do > > > nothing, document it in the release notes, or ??? > > > > Do nothing. > > Agreed. Not much we can do

[COMMITTERS] pgsql: Revert bogus fixes of HOT-freezing bug

Revert bogus fixes of HOT-freezing bug It turns out we misdiagnosed what the real problem was. Revert the previous changes, because they may have worse consequences going forward. A better fix is forthcoming. The simplistic test case is kept, though disabled. Discussion:

[COMMITTERS] pgsql: Revert bogus fixes of HOT-freezing bug

Revert bogus fixes of HOT-freezing bug It turns out we misdiagnosed what the real problem was. Revert the previous changes, because they may have worse consequences going forward. A better fix is forthcoming. The simplistic test case is kept, though disabled. Discussion:

[COMMITTERS] pgsql: Revert bogus fixes of HOT-freezing bug

Revert bogus fixes of HOT-freezing bug It turns out we misdiagnosed what the real problem was. Revert the previous changes, because they may have worse consequences going forward. A better fix is forthcoming. The simplistic test case is kept, though disabled. Discussion:

[COMMITTERS] pgsql: Revert bogus fixes of HOT-freezing bug

Revert bogus fixes of HOT-freezing bug It turns out we misdiagnosed what the real problem was. Revert the previous changes, because they may have worse consequences going forward. A better fix is forthcoming. The simplistic test case is kept, though disabled. Discussion:

[COMMITTERS] pgsql: Revert bogus fixes of HOT-freezing bug

Revert bogus fixes of HOT-freezing bug It turns out we misdiagnosed what the real problem was. Revert the previous changes, because they may have worse consequences going forward. A better fix is forthcoming. The simplistic test case is kept, though disabled. Discussion:

[COMMITTERS] pgsql: Revert bogus fixes of HOT-freezing bug

Revert bogus fixes of HOT-freezing bug It turns out we misdiagnosed what the real problem was. Revert the previous changes, because they may have worse consequences going forward. A better fix is forthcoming. The simplistic test case is kept, though disabled. Discussion:

Re: [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

Andres Freund wrote: > I spent some time discussing this with Robert today (with both of us > alternating between feeling the other and ourselves as stupid), and the > conclusion I think is that the problem is on the pruning, rather than > the freezing side. Thanks both for spending some more

[COMMITTERS] pgsql: Fix autovacuum work item error handling

Fix autovacuum work item error handling In autovacuum's "work item" processing, a few strings were allocated in the current transaction's memory context, which goes away during error handling; if an error happened during execution of the work item, the pfree() calls to clean up afterwards would

[COMMITTERS] pgsql: Fix autovacuum work item error handling

Fix autovacuum work item error handling In autovacuum's "work item" processing, a few strings were allocated in the current transaction's memory context, which goes away during error handling; if an error happened during execution of the work item, the pfree() calls to clean up afterwards would

[COMMITTERS] pgsql: Add more tests for reloptions

Add more tests for reloptions This is preparation for a future patch to extensively change how reloptions work. Author: Nikolay Shaplov Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/2615372.orqtEn8VGB@x200m Branch -- master Details ---

[COMMITTERS] pgsql: Make OWNER TO subcommand mention consistent

Make OWNER TO subcommand mention consistent We say 'OWNER TO' in the synopsis; let's use that form elsewhere. There is a paragraph in the section that refers to various subcommands very loosely (including OWNER); I didn't think it was an improvement to change that one. This is a fairly

[COMMITTERS] pgsql: Make release notes aware that --xlog-method was renamed

Make release notes aware that --xlog-method was renamed Author: David G. Johnston Discussion: https:/postgr.es/m/cakfquwacsb-okojqxgen0r7byxirwvr7otykdbjoygif2vb...@mail.gmail.com Branch -- REL_10_STABLE Details ---

[COMMITTERS] pgsql: Make release notes aware that --xlog-method was renamed

Make release notes aware that --xlog-method was renamed Author: David G. Johnston Discussion: https:/postgr.es/m/cakfquwacsb-okojqxgen0r7byxirwvr7otykdbjoygif2vb...@mail.gmail.com Branch -- master Details ---

Re: [COMMITTERS] pgsql: Fix traversal of half-frozen update chains

Peter Geoghegan wrote: > Wouldn't this last "if" test, to cover the pg_upgrade case, be better > targeted by comparing *raw* xmin to FrozenTransactionId? You're using > the potentially distinct xmin value returned by > HeapTupleHeaderGetXmin() for the test here. I think we should be > directly

[COMMITTERS] pgsql: REASSIGN OWNED BY doc: s/privileges/membership/

REASSIGN OWNED BY doc: s/privileges/membership/ Reported by: David G. Johnston Discussion: https://postgr.es/m/cakfquwajwqjqel9xc1xnnmtybg32edazkjxijzigbosgss_...@mail.gmail.com Branch -- master Details ---

[COMMITTERS] pgsql: Rework DefineIndex relkind check

Rework DefineIndex relkind check Simplify coding using a switch rather than nested if tests. Author: Álvaro Reviewed-by: Robert Haas, Amit Langote, Michaël Paquier Discussion: https://postgr.es/m/20171013163820.pai7djcaxrntaxtn@alvherre.pgsql Branch -- master Details ---

[COMMITTERS] pgsql: Infer functional dependency past RelabelType

Infer functional dependency past RelabelType Vars hidden within a RelabelType would not be detected as compatible with some functional dependency. Repair by properly ignoring the RelabelType. Author: David Rowley Reviewed-by: Tomas Vondra Discussion:

[COMMITTERS] pgsql: Infer functional dependency past RelabelType

Infer functional dependency past RelabelType Vars hidden within a RelabelType would not be detected as compatible with some functional dependency. Repair by properly ignoring the RelabelType. Author: David Rowley Reviewed-by: Tomas Vondra Discussion:

[COMMITTERS] pgsql: Fix traversal of half-frozen update chains

Fix traversal of half-frozen update chains When some tuple versions in an update chain are frozen due to them being older than freeze_min_age, the xmax/xmin trail can become broken. This breaks HOT (and probably other things). A subsequent VACUUM can break things in more serious ways, such as

[COMMITTERS] pgsql: Fix traversal of half-frozen update chains

Fix traversal of half-frozen update chains When some tuple versions in an update chain are frozen due to them being older than freeze_min_age, the xmax/xmin trail can become broken. This breaks HOT (and probably other things). A subsequent VACUUM can break things in more serious ways, such as

[COMMITTERS] pgsql: Fix traversal of half-frozen update chains

Fix traversal of half-frozen update chains When some tuple versions in an update chain are frozen due to them being older than freeze_min_age, the xmax/xmin trail can become broken. This breaks HOT (and probably other things). A subsequent VACUUM can break things in more serious ways, such as

[COMMITTERS] pgsql: Fix traversal of half-frozen update chains

Fix traversal of half-frozen update chains When some tuple versions in an update chain are frozen due to them being older than freeze_min_age, the xmax/xmin trail can become broken. This breaks HOT (and probably other things). A subsequent VACUUM can break things in more serious ways, such as

[COMMITTERS] pgsql: Fix traversal of half-frozen update chains

Fix traversal of half-frozen update chains When some tuple versions in an update chain are frozen due to them being older than freeze_min_age, the xmax/xmin trail can become broken. This breaks HOT (and probably other things). A subsequent VACUUM can break things in more serious ways, such as

[COMMITTERS] pgsql: Fix traversal of half-frozen update chains

Fix traversal of half-frozen update chains When some tuple versions in an update chain are frozen due to them being older than freeze_min_age, the xmax/xmin trail can become broken. This breaks HOT (and probably other things). A subsequent VACUUM can break things in more serious ways, such as

[COMMITTERS] pgsql: Fix coding rules violations in walreceiver.c

Fix coding rules violations in walreceiver.c 1. Since commit b1a9bad9e744 we had pstrdup() inside a spinlock-protected critical section; reported by Andreas Seltenreich. Turn those into strlcpy() to stack-allocated variables instead. Backpatch to 9.6. 2. Since commit 9ed551e0a4fd we had a

[COMMITTERS] pgsql: Fix coding rules violations in walreceiver.c

Fix coding rules violations in walreceiver.c 1. Since commit b1a9bad9e744 we had pstrdup() inside a spinlock-protected critical section; reported by Andreas Seltenreich. Turn those into strlcpy() to stack-allocated variables instead. Backpatch to 9.6. 2. Since commit 9ed551e0a4fd we had a

[COMMITTERS] pgsql: Fix coding rules violations in walreceiver.c

Fix coding rules violations in walreceiver.c 1. Since commit b1a9bad9e744 we had pstrdup() inside a spinlock-protected critical section; reported by Andreas Seltenreich. Turn those into strlcpy() to stack-allocated variables instead. Backpatch to 9.6. 2. Since commit 9ed551e0a4fd we had a

[COMMITTERS] pgsql: Fix coding rules violations in walreceiver.c

Fix coding rules violations in walreceiver.c 1. Since commit b1a9bad9e744 we had pstrdup() inside a spinlock-protected critical section; reported by Andreas Seltenreich. Turn those into strlcpy() to stack-allocated variables instead. Backpatch to 9.6. 2. Since commit 9ed551e0a4fd we had a

[COMMITTERS] pgsql: Fix coding rules violations in walreceiver.c

Fix coding rules violations in walreceiver.c 1. Since commit b1a9bad9e744 we had pstrdup() inside a spinlock-protected critical section; reported by Andreas Seltenreich. Turn those into strlcpy() to stack-allocated variables instead. Backpatch to 9.6. 2. Since commit 9ed551e0a4fd we had a

[COMMITTERS] pgsql: Fix coding rules violations in walreceiver.c

Fix coding rules violations in walreceiver.c 1. Since commit b1a9bad9e744 we had pstrdup() inside a spinlock-protected critical section; reported by Andreas Seltenreich. Turn those into strlcpy() to stack-allocated variables instead. Backpatch to 9.6. 2. Since commit 9ed551e0a4fd we had a

[COMMITTERS] pgsql: Fix coding rules violations in walreceiver.c

Fix coding rules violations in walreceiver.c 1. Since commit b1a9bad9e744 we had pstrdup() inside a spinlock-protected critical section; reported by Andreas Seltenreich. Turn those into strlcpy() to stack-allocated variables instead. Backpatch to 9.6. 2. Since commit 9ed551e0a4fd we had a

[COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

Fix freezing of a dead HOT-updated tuple Vacuum calls page-level HOT prune to remove dead HOT tuples before doing liveness checks (HeapTupleSatisfiesVacuum) on the remaining tuples. But concurrent transaction commit/abort may turn DEAD some of the HOT tuples that survived the prune, before

[COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

Fix freezing of a dead HOT-updated tuple Vacuum calls page-level HOT prune to remove dead HOT tuples before doing liveness checks (HeapTupleSatisfiesVacuum) on the remaining tuples. But concurrent transaction commit/abort may turn DEAD some of the HOT tuples that survived the prune, before

[COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

Fix freezing of a dead HOT-updated tuple Vacuum calls page-level HOT prune to remove dead HOT tuples before doing liveness checks (HeapTupleSatisfiesVacuum) on the remaining tuples. But concurrent transaction commit/abort may turn DEAD some of the HOT tuples that survived the prune, before

[COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

Fix freezing of a dead HOT-updated tuple Vacuum calls page-level HOT prune to remove dead HOT tuples before doing liveness checks (HeapTupleSatisfiesVacuum) on the remaining tuples. But concurrent transaction commit/abort may turn DEAD some of the HOT tuples that survived the prune, before

[COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

Fix freezing of a dead HOT-updated tuple Vacuum calls page-level HOT prune to remove dead HOT tuples before doing liveness checks (HeapTupleSatisfiesVacuum) on the remaining tuples. But concurrent transaction commit/abort may turn DEAD some of the HOT tuples that survived the prune, before

[COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

Fix freezing of a dead HOT-updated tuple Vacuum calls page-level HOT prune to remove dead HOT tuples before doing liveness checks (HeapTupleSatisfiesVacuum) on the remaining tuples. But concurrent transaction commit/abort may turn DEAD some of the HOT tuples that survived the prune, before

[COMMITTERS] pgsql: Test BRIN autosummarization

Test BRIN autosummarization There was no coverage for this code. Reported-by: Nikolay Shaplov, Tom Lane Discussion: https://postgr.es/m/2700647.XEouBYNZic@x200m https://postgr.es/m/13849.1506114...@sss.pgh.pa.us Branch -- master Details ---

[COMMITTERS] pgsql: Test BRIN autosummarization

Test BRIN autosummarization There was no coverage for this code. Reported-by: Nikolay Shaplov, Tom Lane Discussion: https://postgr.es/m/2700647.XEouBYNZic@x200m https://postgr.es/m/13849.1506114...@sss.pgh.pa.us Branch -- REL_10_STABLE Details ---

[COMMITTERS] pgsql: Document further existing locks as wait events

Document further existing locks as wait events Reported-by: Jeremy Schneider Author: Michael Paquier Discussion: https://postgr.es/m/ca+fndazapcwfy8lp-pflnugfaxru1vflyrgdup-l-kwcbj8...@mail.gmail.com Branch -- REL_10_STABLE Details ---

[COMMITTERS] pgsql: Document further existing locks as wait events

Document further existing locks as wait events Reported-by: Jeremy Schneider Author: Michael Paquier Discussion: https://postgr.es/m/ca+fndazapcwfy8lp-pflnugfaxru1vflyrgdup-l-kwcbj8...@mail.gmail.com Branch -- master Details ---

Re: [COMMITTERS] pgsql: Fix erroneous documentation about noise word GROUP.

Tom Lane wrote: > Fix erroneous documentation about noise word GROUP. > > GRANT, REVOKE, and some allied commands allow the noise word GROUP > before a role name (cf. grantee production in gram.y). This option > does not exist elsewhere, but it had nonetheless snuck into the > documentation for

[COMMITTERS] pgsql: src/test/ldap: Fix test function in Linux port

src/test/ldap: Fix test function in Linux port Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c29145f00df2aa873672ab9f1b3fc4ec6a0ec05d Modified Files -- src/test/ldap/t/001_auth.pl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- Sent via

[COMMITTERS] pgsql: Fix translatable string

Fix translatable string Discussion: https://postgr.es/m/20170828130545.sdajqlpr37hmmd6a@alvherre.pgsql Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8d5ec8ee38090989d1f626d9dc477960206bd9dc Modified Files -- src/bin/pg_rewind/libpq_fetch.c |

[COMMITTERS] pgsql: Correct base backup throttling

Correct base backup throttling Throttling for sending a base backup in walsender is broken for the case where there is a lot of WAL traffic, because the latch used to put the walsender to sleep is also signalled by regular WAL traffic (and each signal causes an additional batch of data to be

[COMMITTERS] pgsql: Correct base backup throttling

Correct base backup throttling Throttling for sending a base backup in walsender is broken for the case where there is a lot of WAL traffic, because the latch used to put the walsender to sleep is also signalled by regular WAL traffic (and each signal causes an additional batch of data to be

[COMMITTERS] pgsql: Fix translatable string

Fix translatable string Discussion: https://postgr.es/m/20170828130545.sdajqlpr37hmmd6a@alvherre.pgsql Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/863d75439e8733b4bf6195a2c8a09966f04d8fbe Modified Files -- src/bin/pg_rewind/libpq_fetch.c | 10

[COMMITTERS] pgsql: Fix translatable string

Fix translatable string Discussion: https://postgr.es/m/20170828130545.sdajqlpr37hmmd6a@alvherre.pgsql Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a1af1e7cfaefbef38e6b85ac632ed488744b3fd0 Modified Files -- src/bin/pg_rewind/libpq_fetch.c |

[COMMITTERS] pgsql: Fix translatable string

Fix translatable string Discussion: https://postgr.es/m/20170828130545.sdajqlpr37hmmd6a@alvherre.pgsql Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/bd75335a83bf0564d6d256d1b78499a5ea489d74 Modified Files -- src/bin/pg_rewind/libpq_fetch.c |

Re: [COMMITTERS] pgsql: Provisional list of Major Features

Simon Riggs wrote: > On 1 September 2017 at 15:13, Tom Lane wrote: > > Simon Riggs writes: > >> Provisional list of Major Features > >> Branch > >> -- > >> REL_10_STABLE > > > > If you don't commit that to HEAD, it's going to disappear the next > >

[COMMITTERS] pgsql: Fix two-phase commit test for recovery mode

Fix two-phase commit test for recovery mode The original code had a race condition because it never ensured the standby was caught up before proceeding; add a wait similar to every other place that does this. Author: Michaël Paquier Discussion:

[COMMITTERS] pgsql: Fix two-phase commit test for recovery mode

Fix two-phase commit test for recovery mode The original code had a race condition because it never ensured the standby was caught up before proceeding; add a wait similar to every other place that does this. Author: Michaël Paquier Discussion:

[COMMITTERS] pgsql: Restore behavior for replication origin drop

Restore behavior for replication origin drop Do for replication origins what the previous commit did for replication slots: restore the original behavior of replication origin drop to raise an error rather than blocking, because users might be depending on the original behavior. Maintain the

[COMMITTERS] pgsql: Restore behavior for replication origin drop

Restore behavior for replication origin drop Do for replication origins what the previous commit did for replication slots: restore the original behavior of replication origin drop to raise an error rather than blocking, because users might be depending on the original behavior. Maintain the

[COMMITTERS] pgsql: Add a WAIT option to DROP_REPLICATION_SLOT

Add a WAIT option to DROP_REPLICATION_SLOT Commit 9915de6c1cb2 changed the default behavior of DROP_REPLICATION_SLOT so that it would wait until any session holding the slot active would release it, instead of raising an error. But users are already depending on the original behavior, so revert

[COMMITTERS] pgsql: Add a WAIT option to DROP_REPLICATION_SLOT

Add a WAIT option to DROP_REPLICATION_SLOT Commit 9915de6c1cb2 changed the default behavior of DROP_REPLICATION_SLOT so that it would wait until any session holding the slot active would release it, instead of raising an error. But users are already depending on the original behavior, so revert

[COMMITTERS] pgsql: Simplify autovacuum work-item implementation

Simplify autovacuum work-item implementation The initial implementation of autovacuum work-items used a dynamic shared memory area (DSA). However, it's argued that dynamic shared memory is not portable enough, so we cannot rely on it being supported everywhere; at the same time, autovacuum

[COMMITTERS] pgsql: Simplify autovacuum work-item implementation

Simplify autovacuum work-item implementation The initial implementation of autovacuum work-items used a dynamic shared memory area (DSA). However, it's argued that dynamic shared memory is not portable enough, so we cannot rely on it being supported everywhere; at the same time, autovacuum

[COMMITTERS] pgsql: Fix error handling path in autovacuum launcher

Fix error handling path in autovacuum launcher The original code (since 00e6a16d01) was assuming aborting the transaction in autovacuum launcher was sufficient to release all resources, but in reality the launcher runs quite a lot of code out of any transactions. Re-introduce individual cleanup

[COMMITTERS] pgsql: Fix error handling path in autovacuum launcher

Fix error handling path in autovacuum launcher The original code (since 00e6a16d01) was assuming aborting the transaction in autovacuum launcher was sufficient to release all resources, but in reality the launcher runs quite a lot of code out of any transactions. Re-introduce individual cleanup

[COMMITTERS] pgsql: Reword comment for clarity

Reword comment for clarity Reported by Masahiko Sawada Discussion: https://postgr.es/m/CAD21AoB+ycZ2z-4Ye=6mfq_r0av5r6cvvpw4koypdp6bhqq...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/2336f842843e5bd26779692b39eaf0ef9d4d31da Modified Files

[COMMITTERS] pgsql: Reword some unclear comments

Reword some unclear comments Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1924ef41668773ad62d845eebc11ff35f17446ad Modified Files -- src/backend/access/heap/heapam.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) -- Sent via

[COMMITTERS] pgsql: Reword some unclear comments

Reword some unclear comments Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/pg/commitdiff/962b26b674d29fa2834afbd760a9229bc42a5876 Modified Files -- src/backend/access/heap/heapam.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) -- Sent via

[COMMITTERS] pgsql: Reword some unclear comments

Reword some unclear comments Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9cc510fe89a3f013091bf7234ca893ba74a15094 Modified Files -- src/backend/access/heap/heapam.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) -- Sent via

[COMMITTERS] pgsql: Reword some unclear comments

Reword some unclear comments Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e829db0b19bda06996a1c7104ca1251c8eacaa2c Modified Files -- src/backend/access/heap/heapam.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) -- Sent via

[COMMITTERS] pgsql: Reword some unclear comments

Reword some unclear comments Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/77d2c00af78ee12ae0d1cea34605f1e7af3f6d93 Modified Files -- src/backend/access/heap/heapam.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) -- Sent via

[COMMITTERS] pgsql: Fix typo in comment

Fix typo in comment Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f5d54ef97abdd1df3d6bfe0320a565ecce742abe Modified Files -- src/backend/utils/sort/tuplesort.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgsql-committers

[COMMITTERS] pgsql: Fix replication origin-related race conditions

Fix replication origin-related race conditions Similar to what was fixed in commit 9915de6c1cb2 for replication slots, but this time it's related to replication origins: DROP SUBSCRIPTION attempts to drop the replication origin, but that fails if the replication worker process hasn't yet marked

[COMMITTERS] pgsql: Fix inadequacies in recently added wait events

Fix inadequacies in recently added wait events In commit 9915de6c1cb2, we introduced a new wait point for replication slots and incorrectly labelled it as wait event PG_WAIT_LOCK. That's wrong, so invent an appropriate new wait event instead, and document it properly. While at it, fix numerous

[COMMITTERS] pgsql: Fix build on zlib-less environments

Fix build on zlib-less environments Commit 4d57e8381677 added support for getting I/O errors out of zlib, but it introduced a portability problem for systems without zlib. Repair by wrapping the zlib call inside #ifdef and restore the original code in the other branch. This serves to illustrate

[COMMITTERS] pgsql: Fix build on zlib-less environments

Fix build on zlib-less environments Commit 4d57e8381677 added support for getting I/O errors out of zlib, but it introduced a portability problem for systems without zlib. Repair by wrapping the zlib call inside #ifdef and restore the original code in the other branch. This serves to illustrate

[COMMITTERS] pgsql: Fix build on zlib-less environments

Fix build on zlib-less environments Commit 4d57e8381677 added support for getting I/O errors out of zlib, but it introduced a portability problem for systems without zlib. Repair by wrapping the zlib call inside #ifdef and restore the original code in the other branch. This serves to illustrate

[COMMITTERS] pgsql: Fix build on zlib-less environments

Fix build on zlib-less environments Commit 4d57e8381677 added support for getting I/O errors out of zlib, but it introduced a portability problem for systems without zlib. Repair by wrapping the zlib call inside #ifdef and restore the original code in the other branch. This serves to illustrate

[COMMITTERS] pgsql: Fix pg_dump's errno checking for zlib I/O

Fix pg_dump's errno checking for zlib I/O Some error reports were reporting strerror(errno), which for some error conditions coming from zlib are wrong, resulting in confusing reports such as pg_restore: [compress_io] could not read from input file: Success which makes no sense. To correctly

[COMMITTERS] pgsql: Fix pg_dump's errno checking for zlib I/O

Fix pg_dump's errno checking for zlib I/O Some error reports were reporting strerror(errno), which for some error conditions coming from zlib are wrong, resulting in confusing reports such as pg_restore: [compress_io] could not read from input file: Success which makes no sense. To correctly

[COMMITTERS] pgsql: Fix pg_dump's errno checking for zlib I/O

Fix pg_dump's errno checking for zlib I/O Some error reports were reporting strerror(errno), which for some error conditions coming from zlib are wrong, resulting in confusing reports such as pg_restore: [compress_io] could not read from input file: Success which makes no sense. To correctly

[COMMITTERS] pgsql: Fix pg_dump's errno checking for zlib I/O

Fix pg_dump's errno checking for zlib I/O Some error reports were reporting strerror(errno), which for some error conditions coming from zlib are wrong, resulting in confusing reports such as pg_restore: [compress_io] could not read from input file: Success which makes no sense. To correctly

[COMMITTERS] pgsql: Update copyright in recently added files

Update copyright in recently added files Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/5e3254f0865d2e3372cfd29249063bdaedfa4b00 Modified Files -- src/backend/replication/logical/proto.c | 2 +- src/common/sha2.c | 2 +-

[COMMITTERS] pgsql: Fix concurrent locking of tuple update chain

Fix concurrent locking of tuple update chain If several sessions are concurrently locking a tuple update chain with nonconflicting lock modes using an old snapshot, and they all succeed, it may happen that some of them fail because of restarting the loop (due to a concurrent Xmax change) and

[COMMITTERS] pgsql: Fix concurrent locking of tuple update chain

Fix concurrent locking of tuple update chain If several sessions are concurrently locking a tuple update chain with nonconflicting lock modes using an old snapshot, and they all succeed, it may happen that some of them fail because of restarting the loop (due to a concurrent Xmax change) and

[COMMITTERS] pgsql: Fix concurrent locking of tuple update chain

Fix concurrent locking of tuple update chain If several sessions are concurrently locking a tuple update chain with nonconflicting lock modes using an old snapshot, and they all succeed, it may happen that some of them fail because of restarting the loop (due to a concurrent Xmax change) and

[COMMITTERS] pgsql: Fix concurrent locking of tuple update chain

Fix concurrent locking of tuple update chain If several sessions are concurrently locking a tuple update chain with nonconflicting lock modes using an old snapshot, and they all succeed, it may happen that some of them fail because of restarting the loop (due to a concurrent Xmax change) and

[COMMITTERS] pgsql: Fix concurrent locking of tuple update chain

Fix concurrent locking of tuple update chain If several sessions are concurrently locking a tuple update chain with nonconflicting lock modes using an old snapshot, and they all succeed, it may happen that some of them fail because of restarting the loop (due to a concurrent Xmax change) and

[COMMITTERS] pgsql: Remove obsolete comments about functional dependencies

Remove obsolete comments about functional dependencies Initial submitted versions of the functional dependencies patch ignored row groups that were smaller than a configured size. However, that consideration was removed in late stages of the patch just before commit, but some comments referring

[COMMITTERS] pgsql: Make PostgresNode easily subclassable

Make PostgresNode easily subclassable This module becomes much more useful if we allow it to be used as base class for external projects. To achieve this, change the exported get_new_node function into a class method instead, and use the standard Perl idiom of accepting the class as first

[COMMITTERS] pgsql: Make PostgresNode easily subclassable

Make PostgresNode easily subclassable This module becomes much more useful if we allow it to be used as base class for external projects. To achieve this, change the exported get_new_node function into a class method instead, and use the standard Perl idiom of accepting the class as first

[COMMITTERS] pgsql: Fix race conditions in replication slot operations

Fix race conditions in replication slot operations It is relatively easy to get a replication slot to look as still active while one process is in the process of getting rid of it; when some other process tries to "acquire" the slot, it would fail with an error message of "replication slot XYZ is

[COMMITTERS] pgsql: Fix typo in comment

Fix typo in comment Commit fd31cd265138 renamed the variable to skipping_blocks, but forgot to update this comment. Noticed while inspecting code. Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/afd56b8521c562f7ed20d04159aa597516d74bf5 Modified Files

[COMMITTERS] pgsql: Fix typo in comment

Fix typo in comment Commit fd31cd265138 renamed the variable to skipping_blocks, but forgot to update this comment. Noticed while inspecting code. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/de38489b926e3e5af84f22cf4788fe4498e13c72 Modified Files

[COMMITTERS] pgsql: pg_upgrade i18n: Fix "%s server/cluster" wording

pg_upgrade i18n: Fix "%s server/cluster" wording The original wording was impossible to translate correctly. Discussion: https://postgr.es/m/20170523002827.lzc2jkzh2gubclqb@alvherre.pgsql Branch -- master Details ---

[COMMITTERS] pgsql: Fix typo in v10 release notes

Fix typo in v10 release notes The new functions return a list of files in the corresponding directory, not the name of the directory itself. Pointed out by Gianni Ciolli. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/2036f71b751152e443beecfdd8bffbb4e17447c2

  1   2   3   4   5   6   7   8   9   10   >