[COMMITTERS] pgsql: Fix minor memory leak in Standby startup
Fix minor memory leak in Standby startup StandbyRecoverPreparedTransactions() leaked the buffer used for two phase state file. This was leaked once at startup and at every shutdown checkpoint seen. Backpatch to 9.6 Stas Kelvich Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/67c6bd1ca3ce75778138bf4713444a5a6b46032e Modified Files -- src/backend/access/transam/twophase.c | 2 ++ 1 file changed, 2 insertions(+) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix minor memory leak in Standby startup
Fix minor memory leak in Standby startup StandbyRecoverPreparedTransactions() leaked the buffer used for two phase state file. This was leaked once at startup and at every shutdown checkpoint seen. Backpatch to 9.6 Stas Kelvich Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/d7c45172a673be1fc9e51e98e45a44c14d1ee78d Modified Files -- src/backend/access/transam/twophase.c | 2 ++ 1 file changed, 2 insertions(+) -- 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 print database's tablespace in pg_dump -C --no-tablespaces
Don't print database's tablespace in pg_dump -C --no-tablespaces output. If the database has a non-default tablespace, we emitted a TABLESPACE clause in the CREATE DATABASE command emitted by -C, even if --no-tablespaces was also specified. This seems wrong, and it's inconsistent with what pg_dumpall does, so change it. Per bug #14315 from Danylo Hlynskyi. Back-patch to 9.5. The bug is much older, but it'd be a more invasive change before 9.5 because dumpDatabase() hasn't got an easy way to get to the outputNoTablespaces flag. Doesn't seem worth the work given the lack of previous complaints. Report: <[email protected]> Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/142a110b312fa2d6bbc4eba4df196c35e0caf7bb Modified Files -- src/bin/pg_dump/pg_dump.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 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 print database's tablespace in pg_dump -C --no-tablespaces
Don't print database's tablespace in pg_dump -C --no-tablespaces output. If the database has a non-default tablespace, we emitted a TABLESPACE clause in the CREATE DATABASE command emitted by -C, even if --no-tablespaces was also specified. This seems wrong, and it's inconsistent with what pg_dumpall does, so change it. Per bug #14315 from Danylo Hlynskyi. Back-patch to 9.5. The bug is much older, but it'd be a more invasive change before 9.5 because dumpDatabase() hasn't got an easy way to get to the outputNoTablespaces flag. Doesn't seem worth the work given the lack of previous complaints. Report: <[email protected]> Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/e97e9c57bd22b2dfbfaf41f7d5c69789f7fad554 Modified Files -- src/bin/pg_dump/pg_dump.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 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 print database's tablespace in pg_dump -C --no-tablespaces
Don't print database's tablespace in pg_dump -C --no-tablespaces output. If the database has a non-default tablespace, we emitted a TABLESPACE clause in the CREATE DATABASE command emitted by -C, even if --no-tablespaces was also specified. This seems wrong, and it's inconsistent with what pg_dumpall does, so change it. Per bug #14315 from Danylo Hlynskyi. Back-patch to 9.5. The bug is much older, but it'd be a more invasive change before 9.5 because dumpDatabase() hasn't got an easy way to get to the outputNoTablespaces flag. Doesn't seem worth the work given the lack of previous complaints. Report: <[email protected]> Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/a88cee90fdfb2c125d56cb08164ca9a9ca39a75d Modified Files -- src/bin/pg_dump/pg_dump.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Allow pg_dump to dump non-extension members of an extension-owne
Allow pg_dump to dump non-extension members of an extension-owned schema. Previously, if a schema was created by an extension, a normal pg_dump run (not --binary-upgrade) would summarily skip every object in that schema. In a case where an extension creates a schema and then users create other objects within that schema, this does the wrong thing: we want pg_dump to skip the schema but still create the non-extension-owned objects. There's no easy way to fix this pre-9.6, because in earlier versions the "dump" status for a schema is just a bool and there's no way to distinguish "dump me" from "dump my members". However, as of 9.6 we do have enough state to represent that, so this is a simple correction of the logic in selectDumpableNamespace. In passing, make some cosmetic fixes in nearby code. Martín Marqués, reviewed by Michael Paquier Discussion: <[email protected]> Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/31eb14504de311c98db2d1306ac61427bcdad863 Modified Files -- src/bin/pg_dump/pg_dump.c | 28 ++- src/test/modules/test_pg_dump/t/001_base.pl| 206 - .../modules/test_pg_dump/test_pg_dump--1.0.sql | 24 +++ 3 files changed, 247 insertions(+), 11 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Allow pg_dump to dump non-extension members of an extension-owne
Allow pg_dump to dump non-extension members of an extension-owned schema. Previously, if a schema was created by an extension, a normal pg_dump run (not --binary-upgrade) would summarily skip every object in that schema. In a case where an extension creates a schema and then users create other objects within that schema, this does the wrong thing: we want pg_dump to skip the schema but still create the non-extension-owned objects. There's no easy way to fix this pre-9.6, because in earlier versions the "dump" status for a schema is just a bool and there's no way to distinguish "dump me" from "dump my members". However, as of 9.6 we do have enough state to represent that, so this is a simple correction of the logic in selectDumpableNamespace. In passing, make some cosmetic fixes in nearby code. Martín Marqués, reviewed by Michael Paquier Discussion: <[email protected]> Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/df5d9bb8d5074138e6fea63ac8acd9b95a0eb859 Modified Files -- src/bin/pg_dump/pg_dump.c | 28 ++- src/test/modules/test_pg_dump/t/001_base.pl| 206 - .../modules/test_pg_dump/test_pg_dump--1.0.sql | 24 +++ 3 files changed, 247 insertions(+), 11 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 two src/test/modules Makefiles
Fix two src/test/modules Makefiles commit_ts and test_pg_dump were declaring targets before including the PGXS stanza, which meant that the "all" target customarily defined as the first (and therefore default target) was not the default anymore. Fix that by moving those target definitions to after PGXS. commit_ts was initially good, but I broke it in commit 9def031bd2; test_pg_dump was born broken, probably copying from commit_ts' mistake. In passing, fix a comment mistake in test_pg_dump/Makefile. Backpatch to 9.6. Noted by Tom Lane. Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/e012e7845423a6428ce82bf3a21f6efc958351fb Modified Files -- src/test/modules/commit_ts/Makefile| 10 +- src/test/modules/test_pg_dump/Makefile | 12 ++-- 2 files changed, 11 insertions(+), 11 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 two src/test/modules Makefiles
Fix two src/test/modules Makefiles commit_ts and test_pg_dump were declaring targets before including the PGXS stanza, which meant that the "all" target customarily defined as the first (and therefore default target) was not the default anymore. Fix that by moving those target definitions to after PGXS. commit_ts was initially good, but I broke it in commit 9def031bd2; test_pg_dump was born broken, probably copying from commit_ts' mistake. In passing, fix a comment mistake in test_pg_dump/Makefile. Backpatch to 9.6. Noted by Tom Lane. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/19acee8c5adb68b96222e41c084efbc9b31d397a Modified Files -- src/test/modules/commit_ts/Makefile| 10 +- src/test/modules/test_pg_dump/Makefile | 12 ++-- 2 files changed, 11 insertions(+), 11 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 mdtruncate() to close fd.c handle of deleted segments.
Fix mdtruncate() to close fd.c handle of deleted segments. mdtruncate() forgot to FileClose() a segment's mdfd_vfd, when deleting it. That lead to a fd.c handle to a truncated file being kept open until backend exit. The issue appears to have been introduced way back in 1a5c450f3024ac5, before that the handle was closed inside FileUnlink(). The impact of this bug is limited - only VACUUM and ON COMMIT TRUNCATE for temporary tables, truncate files in place (i.e. TRUNCATE itself is not affected), and the relation has to be bigger than 1GB. The consequences of a leaked fd.c handle aren't severe either. Discussion: <[email protected]> Backpatch: all supported releases Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/769fd9d8e06bf862334a0e04134a3d2c665e5e5b Modified Files -- src/backend/storage/smgr/md.c | 1 + 1 file changed, 1 insertion(+) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix mdtruncate() to close fd.c handle of deleted segments.
Fix mdtruncate() to close fd.c handle of deleted segments. mdtruncate() forgot to FileClose() a segment's mdfd_vfd, when deleting it. That lead to a fd.c handle to a truncated file being kept open until backend exit. The issue appears to have been introduced way back in 1a5c450f3024ac5, before that the handle was closed inside FileUnlink(). The impact of this bug is limited - only VACUUM and ON COMMIT TRUNCATE for temporary tables, truncate files in place (i.e. TRUNCATE itself is not affected), and the relation has to be bigger than 1GB. The consequences of a leaked fd.c handle aren't severe either. Discussion: <[email protected]> Backpatch: all supported releases Branch -- REL9_3_STABLE Details --- http://git.postgresql.org/pg/commitdiff/d2a5b2b28f24e2e98a799fa8877f790ba8e68ab2 Modified Files -- src/backend/storage/smgr/md.c | 1 + 1 file changed, 1 insertion(+) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix mdtruncate() to close fd.c handle of deleted segments.
Fix mdtruncate() to close fd.c handle of deleted segments. mdtruncate() forgot to FileClose() a segment's mdfd_vfd, when deleting it. That lead to a fd.c handle to a truncated file being kept open until backend exit. The issue appears to have been introduced way back in 1a5c450f3024ac5, before that the handle was closed inside FileUnlink(). The impact of this bug is limited - only VACUUM and ON COMMIT TRUNCATE for temporary tables, truncate files in place (i.e. TRUNCATE itself is not affected), and the relation has to be bigger than 1GB. The consequences of a leaked fd.c handle aren't severe either. Discussion: <[email protected]> Backpatch: all supported releases Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/26ce63ce76f91eac7570fcb893321ed0233d62ff Modified Files -- src/backend/storage/smgr/md.c | 1 + 1 file changed, 1 insertion(+) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix mdtruncate() to close fd.c handle of deleted segments.
Fix mdtruncate() to close fd.c handle of deleted segments. mdtruncate() forgot to FileClose() a segment's mdfd_vfd, when deleting it. That lead to a fd.c handle to a truncated file being kept open until backend exit. The issue appears to have been introduced way back in 1a5c450f3024ac5, before that the handle was closed inside FileUnlink(). The impact of this bug is limited - only VACUUM and ON COMMIT TRUNCATE for temporary tables, truncate files in place (i.e. TRUNCATE itself is not affected), and the relation has to be bigger than 1GB. The consequences of a leaked fd.c handle aren't severe either. Discussion: <[email protected]> Backpatch: all supported releases Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/f6802936a53671c9db24273ab2ae94291a68afcd Modified Files -- src/backend/storage/smgr/md.c | 1 + 1 file changed, 1 insertion(+) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix mdtruncate() to close fd.c handle of deleted segments.
Fix mdtruncate() to close fd.c handle of deleted segments. mdtruncate() forgot to FileClose() a segment's mdfd_vfd, when deleting it. That lead to a fd.c handle to a truncated file being kept open until backend exit. The issue appears to have been introduced way back in 1a5c450f3024ac5, before that the handle was closed inside FileUnlink(). The impact of this bug is limited - only VACUUM and ON COMMIT TRUNCATE for temporary tables, truncate files in place (i.e. TRUNCATE itself is not affected), and the relation has to be bigger than 1GB. The consequences of a leaked fd.c handle aren't severe either. Discussion: <[email protected]> Backpatch: all supported releases Branch -- REL9_2_STABLE Details --- http://git.postgresql.org/pg/commitdiff/f5462dedb70417f57e76b4f90d68d7d099e5b046 Modified Files -- src/backend/storage/smgr/md.c | 1 + 1 file changed, 1 insertion(+) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix mdtruncate() to close fd.c handle of deleted segments.
Fix mdtruncate() to close fd.c handle of deleted segments. mdtruncate() forgot to FileClose() a segment's mdfd_vfd, when deleting it. That lead to a fd.c handle to a truncated file being kept open until backend exit. The issue appears to have been introduced way back in 1a5c450f3024ac5, before that the handle was closed inside FileUnlink(). The impact of this bug is limited - only VACUUM and ON COMMIT TRUNCATE for temporary tables, truncate files in place (i.e. TRUNCATE itself is not affected), and the relation has to be bigger than 1GB. The consequences of a leaked fd.c handle aren't severe either. Discussion: <[email protected]> Backpatch: all supported releases Branch -- REL9_4_STABLE Details --- http://git.postgresql.org/pg/commitdiff/075cfbe4a966aa9717941ac8dce48434c4706aa5 Modified Files -- src/backend/storage/smgr/md.c | 1 + 1 file changed, 1 insertion(+) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix mdtruncate() to close fd.c handle of deleted segments.
Fix mdtruncate() to close fd.c handle of deleted segments. mdtruncate() forgot to FileClose() a segment's mdfd_vfd, when deleting it. That lead to a fd.c handle to a truncated file being kept open until backend exit. The issue appears to have been introduced way back in 1a5c450f3024ac5, before that the handle was closed inside FileUnlink(). The impact of this bug is limited - only VACUUM and ON COMMIT TRUNCATE for temporary tables, truncate files in place (i.e. TRUNCATE itself is not affected), and the relation has to be bigger than 1GB. The consequences of a leaked fd.c handle aren't severe either. Discussion: <[email protected]> Backpatch: all supported releases Branch -- REL9_1_STABLE Details --- http://git.postgresql.org/pg/commitdiff/08fdfe7a8a2f7516172a0d89b678a1b6c21c5afb Modified Files -- src/backend/storage/smgr/md.c | 1 + 1 file changed, 1 insertion(+) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Faster PageIsVerified() for the all zeroes case.
Faster PageIsVerified() for the all zeroes case. That's primarily useful for testing very large relations, using sparse files. Discussion: <[email protected]> Reviewed-By: Peter Geoghegan Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/417fefaf089fc0b73607cbbe8bcd0bc9e89d08ef Modified Files -- src/backend/storage/page/bufpage.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Improve scalability of md.c for large relations.
Improve scalability of md.c for large relations. So far md.c used a linked list of segments. That proved to be a problem when processing large relations, because every smgr.c/md.c level access to a page incurred walking through a linked list of all preceding segments. Thus making accessing pages O(#segments). Replace the linked list of segments hanging off SMgrRelationData with an array of opened segments. That allows O(1) access to individual segments, if they've previously been opened. Discussion: <[email protected]> Reviewed-By: Peter Geoghegan, Tom Lane (in an older version) Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/45e191e3aa62d47a8bc1a33f784286b2051f45cb Modified Files -- src/backend/storage/smgr/md.c | 393 ++-- src/backend/storage/smgr/smgr.c | 4 +- src/include/storage/smgr.h | 8 +- 3 files changed, 229 insertions(+), 176 deletions(-) -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
