[COMMITTERS] pgsql: Improve RLS documentation with respect to COPY
Improve RLS documentation with respect to COPY Documentation for pg_restore said COPY TO does not support row security when in fact it should say COPY FROM. Fix that. While at it, make it clear that "COPY FROM" does not allow RLS to be enabled and INSERT should be used instead. Also that SELECT policies will apply to COPY TO statements. Back-patch to 9.5 where RLS first appeared. Author: Joe Conway Reviewed-By: Dean Rasheed and Robert Haas Discussion: https://postgr.es/m/5744FA24.3030008%40joeconway.com Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/53afdef662ef77a3f27fc36dbc0472f855069fd3 Modified Files -- doc/src/sgml/ref/copy.sgml | 9 + doc/src/sgml/ref/pg_dump.sgml| 5 + doc/src/sgml/ref/pg_restore.sgml | 2 +- 3 files changed, 15 insertions(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Improve RLS documentation with respect to COPY
Improve RLS documentation with respect to COPY Documentation for pg_restore said COPY TO does not support row security when in fact it should say COPY FROM. Fix that. While at it, make it clear that "COPY FROM" does not allow RLS to be enabled and INSERT should be used instead. Also that SELECT policies will apply to COPY TO statements. Back-patch to 9.5 where RLS first appeared. Author: Joe Conway Reviewed-By: Dean Rasheed and Robert Haas Discussion: https://postgr.es/m/5744FA24.3030008%40joeconway.com Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/51e9df7a1005fc7748c71cd359431f2a41ea678d Modified Files -- doc/src/sgml/ref/copy.sgml | 9 + doc/src/sgml/ref/pg_dump.sgml| 5 + doc/src/sgml/ref/pg_restore.sgml | 2 +- 3 files changed, 15 insertions(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Improve RLS documentation with respect to COPY
Improve RLS documentation with respect to COPY Documentation for pg_restore said COPY TO does not support row security when in fact it should say COPY FROM. Fix that. While at it, make it clear that "COPY FROM" does not allow RLS to be enabled and INSERT should be used instead. Also that SELECT policies will apply to COPY TO statements. Back-patch to 9.5 where RLS first appeared. Author: Joe Conway Reviewed-By: Dean Rasheed and Robert Haas Discussion: https://postgr.es/m/5744FA24.3030008%40joeconway.com Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/0a85c102254b72ec7ce16bc504206a1a5c84bd76 Modified Files -- doc/src/sgml/ref/copy.sgml | 9 + doc/src/sgml/ref/pg_dump.sgml| 5 + doc/src/sgml/ref/pg_restore.sgml | 2 +- 3 files changed, 15 insertions(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix tuple routing in cases where tuple descriptors don't match.
Fix tuple routing in cases where tuple descriptors don't match. The previous coding failed to work correctly when we have a multi-level partitioned hierarchy where tables at successive levels have different attribute numbers for the partition key attributes. To fix, have each PartitionDispatch object store a standalone TupleTableSlot initialized with the TupleDesc of the corresponding partitioned table, along with a TupleConversionMap to map tuples from the its parent's rowtype to own rowtype. After tuple routing chooses a leaf partition, we must use the leaf partition's tuple descriptor, not the root table's. To that end, a dedicated TupleTableSlot for tuple routing is now allocated in EState. Amit Langote Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/2ac3ef7a01df859c62d0a02333b646d65eaec5ff Modified Files -- src/backend/catalog/partition.c| 74 -- src/backend/commands/copy.c| 31 +- src/backend/executor/nodeModifyTable.c | 27 + src/include/catalog/partition.h| 7 src/include/nodes/execnodes.h | 3 ++ src/test/regress/expected/insert.out | 37 + src/test/regress/sql/insert.sql| 26 7 files changed, 190 insertions(+), 15 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Use TSConfigRelationId in AlterTSConfiguration()
I think that the commit message, especially for something being back-patched, should try to describe what user-visible problems the mistake causes, rather than just what was wrong at a code level. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Use TSConfigRelationId in AlterTSConfiguration()
Use TSConfigRelationId in AlterTSConfiguration() When we are altering a text search configuration, we are getting the tuple from pg_ts_config and using its OID, so use TSConfigRelationId when invoking any post-alter hooks and setting the object address. Further, in the functions called from AlterTSConfiguration(), we're saving information about the command via EventTriggerCollectAlterTSConfig(), so we should be setting commandCollected to true. Also add a regression test to test_ddl_deparse for ALTER TEXT SEARCH CONFIGURATION. Author: Artur Zakirov, a few additional comments by me Discussion: https://www.postgresql.org/message-id/57a71eba-f2c7-e7fd-6fc0-2126ec0b39bd%40postgrespro.ru Back-patch the fix for the InvokeObjectPostAlterHook() call to 9.3 where it was introduced, and the fix for the ObjectAddressSet() call and setting commandCollected to true to 9.5 where those changes to ProcessUtilitySlow() were introduced. Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/e8236921773dab92f884db2685aee49fdc747cfc Modified Files -- src/backend/commands/tsearchcmds.c | 4 ++-- src/backend/tcop/utility.c | 8 +++- src/test/modules/test_ddl_deparse/Makefile | 1 + src/test/modules/test_ddl_deparse/expected/alter_ts_config.out | 8 src/test/modules/test_ddl_deparse/sql/alter_ts_config.sql | 8 5 files changed, 26 insertions(+), 3 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Use TSConfigRelationId in AlterTSConfiguration()
Use TSConfigRelationId in AlterTSConfiguration() When we are altering a text search configuration, we are getting the tuple from pg_ts_config and using its OID, so use TSConfigRelationId when invoking any post-alter hooks and setting the object address. Further, in the functions called from AlterTSConfiguration(), we're saving information about the command via EventTriggerCollectAlterTSConfig(), so we should be setting commandCollected to true. Also add a regression test to test_ddl_deparse for ALTER TEXT SEARCH CONFIGURATION. Author: Artur Zakirov, a few additional comments by me Discussion: https://www.postgresql.org/message-id/57a71eba-f2c7-e7fd-6fc0-2126ec0b39bd%40postgrespro.ru Back-patch the fix for the InvokeObjectPostAlterHook() call to 9.3 where it was introduced, and the fix for the ObjectAddressSet() call and setting commandCollected to true to 9.5 where those changes to ProcessUtilitySlow() were introduced. Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/f0f2e56ac28c05f930ca76c432d61909c9a12cdb Modified Files -- src/backend/commands/tsearchcmds.c | 4 ++-- src/backend/tcop/utility.c | 8 +++- src/test/modules/test_ddl_deparse/Makefile | 1 + src/test/modules/test_ddl_deparse/expected/alter_ts_config.out | 8 src/test/modules/test_ddl_deparse/sql/alter_ts_config.sql | 8 5 files changed, 26 insertions(+), 3 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Use TSConfigRelationId in AlterTSConfiguration()
Use TSConfigRelationId in AlterTSConfiguration() When we are altering a text search configuration, we are getting the tuple from pg_ts_config and using its OID, so use TSConfigRelationId when invoking any post-alter hooks and setting the object address. Further, in the functions called from AlterTSConfiguration(), we're saving information about the command via EventTriggerCollectAlterTSConfig(), so we should be setting commandCollected to true. Also add a regression test to test_ddl_deparse for ALTER TEXT SEARCH CONFIGURATION. Author: Artur Zakirov, a few additional comments by me Discussion: https://www.postgresql.org/message-id/57a71eba-f2c7-e7fd-6fc0-2126ec0b39bd%40postgrespro.ru Back-patch the fix for the InvokeObjectPostAlterHook() call to 9.3 where it was introduced, and the fix for the ObjectAddressSet() call and setting commandCollected to true to 9.5 where those changes to ProcessUtilitySlow() were introduced. Branch -- REL9_4_STABLE Details --- http://git.postgresql.org/pg/commitdiff/ac1ec9c1f0365293e9fdc26f06545b3b48817230 Modified Files -- src/backend/commands/tsearchcmds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Use TSConfigRelationId in AlterTSConfiguration()
Use TSConfigRelationId in AlterTSConfiguration() When we are altering a text search configuration, we are getting the tuple from pg_ts_config and using its OID, so use TSConfigRelationId when invoking any post-alter hooks and setting the object address. Further, in the functions called from AlterTSConfiguration(), we're saving information about the command via EventTriggerCollectAlterTSConfig(), so we should be setting commandCollected to true. Also add a regression test to test_ddl_deparse for ALTER TEXT SEARCH CONFIGURATION. Author: Artur Zakirov, a few additional comments by me Discussion: https://www.postgresql.org/message-id/57a71eba-f2c7-e7fd-6fc0-2126ec0b39bd%40postgrespro.ru Back-patch the fix for the InvokeObjectPostAlterHook() call to 9.3 where it was introduced, and the fix for the ObjectAddressSet() call and setting commandCollected to true to 9.5 where those changes to ProcessUtilitySlow() were introduced. Branch -- REL9_3_STABLE Details --- http://git.postgresql.org/pg/commitdiff/0e3aadb682f0c76f6b21ac0058e3717eb7cc2b19 Modified Files -- src/backend/commands/tsearchcmds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Use TSConfigRelationId in AlterTSConfiguration()
Use TSConfigRelationId in AlterTSConfiguration() When we are altering a text search configuration, we are getting the tuple from pg_ts_config and using its OID, so use TSConfigRelationId when invoking any post-alter hooks and setting the object address. Further, in the functions called from AlterTSConfiguration(), we're saving information about the command via EventTriggerCollectAlterTSConfig(), so we should be setting commandCollected to true. Also add a regression test to test_ddl_deparse for ALTER TEXT SEARCH CONFIGURATION. Author: Artur Zakirov, a few additional comments by me Discussion: https://www.postgresql.org/message-id/57a71eba-f2c7-e7fd-6fc0-2126ec0b39bd%40postgrespro.ru Back-patch the fix for the InvokeObjectPostAlterHook() call to 9.3 where it was introduced, and the fix for the ObjectAddressSet() call and setting commandCollected to true to 9.5 where those changes to ProcessUtilitySlow() were introduced. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/12bd7dd317e8f4346fb3507578aca790ede6ebea Modified Files -- src/backend/commands/tsearchcmds.c | 4 ++-- src/backend/tcop/utility.c | 8 +++- src/test/modules/test_ddl_deparse/Makefile | 1 + src/test/modules/test_ddl_deparse/expected/alter_ts_config.out | 8 src/test/modules/test_ddl_deparse/sql/alter_ts_config.sql | 8 5 files changed, 26 insertions(+), 3 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix CREATE TABLE ... LIKE ... WITH OIDS.
Fix CREATE TABLE ... LIKE ... WITH OIDS. Having a WITH OIDS specification should result in the creation of an OID column, but commit b943f502b broke that in the case that there were LIKE tables without OIDS. Commentary in that patch makes it look like this was intentional, but if so it was based on a faulty reading of what inheritance does: the parent tables can add an OID column, but they can't subtract one. AFAICS, the behavior ought to be that you get an OID column if any of the inherited tables, LIKE tables, or WITH clause ask for one. Also, revert that patch's unnecessary split of transformCreateStmt's loop over the tableElts list into two passes. That seems to have been based on a misunderstanding as well: we already have two-pass processing here, we don't need three passes. Per bug #14474 from Jeff Dafoe. Back-patch to 9.6 where the misbehavior was introduced. Report: https://postgr.es/m/20161222145304.25620.47...@wrigleys.postgresql.org Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/1ead0208b2178089b024caa2d1465a3f3056a45c Modified Files -- src/backend/parser/parse_utilcmd.c | 52 + src/test/regress/expected/create_table_like.out | 9 - src/test/regress/sql/create_table_like.sql | 5 ++- 3 files changed, 30 insertions(+), 36 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix CREATE TABLE ... LIKE ... WITH OIDS.
Fix CREATE TABLE ... LIKE ... WITH OIDS. Having a WITH OIDS specification should result in the creation of an OID column, but commit b943f502b broke that in the case that there were LIKE tables without OIDS. Commentary in that patch makes it look like this was intentional, but if so it was based on a faulty reading of what inheritance does: the parent tables can add an OID column, but they can't subtract one. AFAICS, the behavior ought to be that you get an OID column if any of the inherited tables, LIKE tables, or WITH clause ask for one. Also, revert that patch's unnecessary split of transformCreateStmt's loop over the tableElts list into two passes. That seems to have been based on a misunderstanding as well: we already have two-pass processing here, we don't need three passes. Per bug #14474 from Jeff Dafoe. Back-patch to 9.6 where the misbehavior was introduced. Report: https://postgr.es/m/20161222145304.25620.47...@wrigleys.postgresql.org Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/68330c8b42ade797995fb84f46af7549c041ad1e Modified Files -- src/backend/parser/parse_utilcmd.c | 53 + src/test/regress/expected/create_table_like.out | 9 - src/test/regress/sql/create_table_like.sql | 5 ++- 3 files changed, 31 insertions(+), 36 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Update sequence_1.out for recent changes
Update sequence_1.out for recent changes Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/22434dd06bbc5774c7bbffa5bf2bef3ead50c2f2 Modified Files -- src/test/regress/expected/sequence_1.out | 33 ++-- 1 file changed, 27 insertions(+), 6 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: doc: Further speed improvements for HTML XSLT build
doc: Further speed improvements for HTML XSLT build Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/909cb78a8cce73c9678ddb3269b56e31b56e084b Modified Files -- doc/src/sgml/stylesheet-speedup-common.xsl | 6 doc/src/sgml/stylesheet-speedup-xhtml.xsl | 50 ++ 2 files changed, 56 insertions(+) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix handling of expanded objects in CoerceToDomain and CASE exec
Fix handling of expanded objects in CoerceToDomain and CASE execution. When the input value to a CoerceToDomain expression node is a read-write expanded datum, we should pass a read-only pointer to any domain CHECK expressions and then return the original read-write pointer as the expression result. Previously we were blindly passing the same pointer to all the consumers of the value, making it possible for a function in CHECK to modify or even delete the expanded value. (Since a plpgsql function will absorb a passed-in read-write expanded array as a local variable value, it will in fact delete the value on exit.) A similar hazard of passing the same read-write pointer to multiple consumers exists in domain_check() and in ExecEvalCase, so fix those too. The fix requires adding MakeExpandedObjectReadOnly calls at the appropriate places, which is simple enough except that we need to get the data type's typlen from somewhere. For the domain cases, solve this by redefining DomainConstraintRef.tcache as okay for callers to access; there wasn't any reason for the original convention against that, other than not wanting the API of typcache.c to be any wider than it had to be. For CASE, there's no good solution except to add a syscache lookup during executor start. Per bug #14472 from Marcos Castedo. Back-patch to 9.5 where expanded values were introduced. Discussion: https://postgr.es/m/15225.1482431...@sss.pgh.pa.us Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/cd1b215692d2cadf499936dba05f1f60bce59344 Modified Files -- src/backend/executor/execQual.c | 25 - src/backend/utils/adt/domains.c | 10 -- src/include/nodes/execnodes.h | 1 + src/include/utils/typcache.h | 2 +- src/test/regress/expected/case.out| 26 ++ src/test/regress/expected/plpgsql.out | 20 src/test/regress/sql/case.sql | 28 src/test/regress/sql/plpgsql.sql | 23 +++ 8 files changed, 127 insertions(+), 8 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix handling of expanded objects in CoerceToDomain and CASE exec
Fix handling of expanded objects in CoerceToDomain and CASE execution. When the input value to a CoerceToDomain expression node is a read-write expanded datum, we should pass a read-only pointer to any domain CHECK expressions and then return the original read-write pointer as the expression result. Previously we were blindly passing the same pointer to all the consumers of the value, making it possible for a function in CHECK to modify or even delete the expanded value. (Since a plpgsql function will absorb a passed-in read-write expanded array as a local variable value, it will in fact delete the value on exit.) A similar hazard of passing the same read-write pointer to multiple consumers exists in domain_check() and in ExecEvalCase, so fix those too. The fix requires adding MakeExpandedObjectReadOnly calls at the appropriate places, which is simple enough except that we need to get the data type's typlen from somewhere. For the domain cases, solve this by redefining DomainConstraintRef.tcache as okay for callers to access; there wasn't any reason for the original convention against that, other than not wanting the API of typcache.c to be any wider than it had to be. For CASE, there's no good solution except to add a syscache lookup during executor start. Per bug #14472 from Marcos Castedo. Back-patch to 9.5 where expanded values were introduced. Discussion: https://postgr.es/m/15225.1482431...@sss.pgh.pa.us Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/c472f2a3353dc4907b54ba90b720310bfb2434eb Modified Files -- src/backend/executor/execQual.c | 25 - src/backend/utils/adt/domains.c | 10 -- src/include/nodes/execnodes.h | 1 + src/include/utils/typcache.h | 2 +- src/test/regress/expected/case.out| 26 ++ src/test/regress/expected/plpgsql.out | 20 src/test/regress/sql/case.sql | 28 src/test/regress/sql/plpgsql.sql | 23 +++ 8 files changed, 127 insertions(+), 8 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix handling of expanded objects in CoerceToDomain and CASE exec
Fix handling of expanded objects in CoerceToDomain and CASE execution. When the input value to a CoerceToDomain expression node is a read-write expanded datum, we should pass a read-only pointer to any domain CHECK expressions and then return the original read-write pointer as the expression result. Previously we were blindly passing the same pointer to all the consumers of the value, making it possible for a function in CHECK to modify or even delete the expanded value. (Since a plpgsql function will absorb a passed-in read-write expanded array as a local variable value, it will in fact delete the value on exit.) A similar hazard of passing the same read-write pointer to multiple consumers exists in domain_check() and in ExecEvalCase, so fix those too. The fix requires adding MakeExpandedObjectReadOnly calls at the appropriate places, which is simple enough except that we need to get the data type's typlen from somewhere. For the domain cases, solve this by redefining DomainConstraintRef.tcache as okay for callers to access; there wasn't any reason for the original convention against that, other than not wanting the API of typcache.c to be any wider than it had to be. For CASE, there's no good solution except to add a syscache lookup during executor start. Per bug #14472 from Marcos Castedo. Back-patch to 9.5 where expanded values were introduced. Discussion: https://postgr.es/m/15225.1482431...@sss.pgh.pa.us Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/77cd0dc7e05a91be5deaed7af37eb055c1f080ed Modified Files -- src/backend/executor/execQual.c | 25 - src/backend/utils/adt/domains.c | 10 -- src/include/nodes/execnodes.h | 1 + src/include/utils/typcache.h | 2 +- src/test/regress/expected/case.out| 26 ++ src/test/regress/expected/plpgsql.out | 20 src/test/regress/sql/case.sql | 28 src/test/regress/sql/plpgsql.sql | 23 +++ 8 files changed, 127 insertions(+), 8 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Skip checkpoints, archiving on idle systems.
Skip checkpoints, archiving on idle systems. Some background activity (like checkpoints, archive timeout, standby snapshots) is not supposed to happen on an idle system. Unfortunately so far it was not easy to determine when a system is idle, which defeated some of the attempts to avoid redundant activity on an idle system. To make that easier, allow to make individual WAL insertions as not being "important". By checking whether any important activity happened since the last time an activity was performed, it now is easy to check whether some action needs to be repeated. Use the new facility for checkpoints, archive timeout and standby snapshots. The lack of a facility causes some issues in older releases, but in my opinion the consequences (superflous checkpoints / archived segments) aren't grave enough to warrant backpatching. Author: Michael Paquier, editorialized by Andres Freund Reviewed-By: Andres Freund, David Steele, Amit Kapila, Kyotaro HORIGUCHI Bug: #13685 Discussion: https://www.postgresql.org/message-id/20151016203031.3019.72...@wrigleys.postgresql.org https://www.postgresql.org/message-id/CAB7nPqQcPqxEM3S735Bd2RzApNqSNJVietAC=6kfkyv_45d...@mail.gmail.com Backpatch: - Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/6ef2eba3f57f17960b7cd4958e18aa79e357de2f Modified Files -- doc/src/sgml/config.sgml | 10 +-- src/backend/access/heap/heapam.c | 10 +-- src/backend/access/transam/xact.c | 2 +- src/backend/access/transam/xlog.c | 118 +++--- src/backend/access/transam/xlogfuncs.c| 2 +- src/backend/access/transam/xloginsert.c | 24 -- src/backend/postmaster/bgwriter.c | 8 +- src/backend/postmaster/checkpointer.c | 45 src/backend/replication/logical/message.c | 2 +- src/backend/storage/ipc/standby.c | 11 ++- src/include/access/xlog.h | 12 ++- src/include/access/xlog_internal.h| 4 +- src/include/access/xloginsert.h | 2 +- 13 files changed, 173 insertions(+), 77 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix broken error check in _hash_doinsert.
Fix broken error check in _hash_doinsert. You can't just cast a HashMetaPage to a Page, because the meta page data is stored after the page header, not at offset 0. Fortunately, this didn't break anything because it happens to find hashm_bsize at the offset at which it expects to find pd_pagesize_version, and the values are close enough to the same that this works out. Still, it's a bug, so back-patch to all supported versions. Mithun Cy, revised a bit by me. Branch -- REL9_3_STABLE Details --- http://git.postgresql.org/pg/commitdiff/603ad8ad298315cab79fa4e1c78095e4a3eca003 Modified Files -- src/backend/access/hash/hashinsert.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix broken error check in _hash_doinsert.
Fix broken error check in _hash_doinsert. You can't just cast a HashMetaPage to a Page, because the meta page data is stored after the page header, not at offset 0. Fortunately, this didn't break anything because it happens to find hashm_bsize at the offset at which it expects to find pd_pagesize_version, and the values are close enough to the same that this works out. Still, it's a bug, so back-patch to all supported versions. Mithun Cy, revised a bit by me. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/097e41439d69e11fb870e009b1ac64dda4f01c3d Modified Files -- src/backend/access/hash/hashinsert.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix broken error check in _hash_doinsert.
Fix broken error check in _hash_doinsert. You can't just cast a HashMetaPage to a Page, because the meta page data is stored after the page header, not at offset 0. Fortunately, this didn't break anything because it happens to find hashm_bsize at the offset at which it expects to find pd_pagesize_version, and the values are close enough to the same that this works out. Still, it's a bug, so back-patch to all supported versions. Mithun Cy, revised a bit by me. Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/17742a05110ee0015f2861e9a4e4b1158c7e69cf Modified Files -- src/backend/access/hash/hashinsert.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix broken error check in _hash_doinsert.
Fix broken error check in _hash_doinsert. You can't just cast a HashMetaPage to a Page, because the meta page data is stored after the page header, not at offset 0. Fortunately, this didn't break anything because it happens to find hashm_bsize at the offset at which it expects to find pd_pagesize_version, and the values are close enough to the same that this works out. Still, it's a bug, so back-patch to all supported versions. Mithun Cy, revised a bit by me. Branch -- REL9_2_STABLE Details --- http://git.postgresql.org/pg/commitdiff/de651a6e5db25d462bde0a47cb4f8f45c45a6a6d Modified Files -- src/backend/access/hash/hashinsert.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix broken error check in _hash_doinsert.
Fix broken error check in _hash_doinsert. You can't just cast a HashMetaPage to a Page, because the meta page data is stored after the page header, not at offset 0. Fortunately, this didn't break anything because it happens to find hashm_bsize at the offset at which it expects to find pd_pagesize_version, and the values are close enough to the same that this works out. Still, it's a bug, so back-patch to all supported versions. Mithun Cy, revised a bit by me. Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/aa04e5c3c1b1ba27d5e726d9afc291f475051ec0 Modified Files -- src/backend/access/hash/hashinsert.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix broken error check in _hash_doinsert.
Fix broken error check in _hash_doinsert. You can't just cast a HashMetaPage to a Page, because the meta page data is stored after the page header, not at offset 0. Fortunately, this didn't break anything because it happens to find hashm_bsize at the offset at which it expects to find pd_pagesize_version, and the values are close enough to the same that this works out. Still, it's a bug, so back-patch to all supported versions. Mithun Cy, revised a bit by me. Branch -- REL9_4_STABLE Details --- http://git.postgresql.org/pg/commitdiff/c2f78e5e02e72e7f74f549fa07a435b1264ba308 Modified Files -- src/backend/access/hash/hashinsert.c | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Make dblink try harder to form useful error messages
Make dblink try harder to form useful error messages When libpq encounters a connection-level error, e.g. runs out of memory while forming a result, there will be no error associated with PGresult, but a message will be placed into PGconn's error buffer. postgres_fdw takes care to use the PGconn error message when PGresult does not have one, but dblink has been negligent in that regard. Modify dblink to mirror what postgres_fdw has been doing. Back-patch to all supported branches. Author: Joe Conway Reviewed-By: Tom Lane Discussion: https://postgr.es/m/02fa2d90-2efd-00bc-fefc-c23c00eb671e%40joeconway.com Branch -- REL9_3_STABLE Details --- http://git.postgresql.org/pg/commitdiff/9b8507bfae9119427a5c3acf037c466a7e3d7046 Modified Files -- contrib/dblink/dblink.c | 31 ++- 1 file changed, 22 insertions(+), 9 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Make dblink try harder to form useful error messages
Make dblink try harder to form useful error messages When libpq encounters a connection-level error, e.g. runs out of memory while forming a result, there will be no error associated with PGresult, but a message will be placed into PGconn's error buffer. postgres_fdw takes care to use the PGconn error message when PGresult does not have one, but dblink has been negligent in that regard. Modify dblink to mirror what postgres_fdw has been doing. Back-patch to all supported branches. Author: Joe Conway Reviewed-By: Tom Lane Discussion: https://postgr.es/m/02fa2d90-2efd-00bc-fefc-c23c00eb671e%40joeconway.com Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/2f802d95b4904dbed3dfdca1b3a607cd085d2e20 Modified Files -- contrib/dblink/dblink.c | 31 ++- 1 file changed, 22 insertions(+), 9 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Make dblink try harder to form useful error messages
Make dblink try harder to form useful error messages When libpq encounters a connection-level error, e.g. runs out of memory while forming a result, there will be no error associated with PGresult, but a message will be placed into PGconn's error buffer. postgres_fdw takes care to use the PGconn error message when PGresult does not have one, but dblink has been negligent in that regard. Modify dblink to mirror what postgres_fdw has been doing. Back-patch to all supported branches. Author: Joe Conway Reviewed-By: Tom Lane Discussion: https://postgr.es/m/02fa2d90-2efd-00bc-fefc-c23c00eb671e%40joeconway.com Branch -- REL9_4_STABLE Details --- http://git.postgresql.org/pg/commitdiff/76943f54a743e3d7875a6772fec89bb57a8f2118 Modified Files -- contrib/dblink/dblink.c | 31 ++- 1 file changed, 22 insertions(+), 9 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Make dblink try harder to form useful error messages
Make dblink try harder to form useful error messages When libpq encounters a connection-level error, e.g. runs out of memory while forming a result, there will be no error associated with PGresult, but a message will be placed into PGconn's error buffer. postgres_fdw takes care to use the PGconn error message when PGresult does not have one, but dblink has been negligent in that regard. Modify dblink to mirror what postgres_fdw has been doing. Back-patch to all supported branches. Author: Joe Conway Reviewed-By: Tom Lane Discussion: https://postgr.es/m/02fa2d90-2efd-00bc-fefc-c23c00eb671e%40joeconway.com Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/51126ccdb1ce720b674405e11bcb5e7b8fa902fb Modified Files -- contrib/dblink/dblink.c | 31 ++- 1 file changed, 22 insertions(+), 9 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Make dblink try harder to form useful error messages
Make dblink try harder to form useful error messages When libpq encounters a connection-level error, e.g. runs out of memory while forming a result, there will be no error associated with PGresult, but a message will be placed into PGconn's error buffer. postgres_fdw takes care to use the PGconn error message when PGresult does not have one, but dblink has been negligent in that regard. Modify dblink to mirror what postgres_fdw has been doing. Back-patch to all supported branches. Author: Joe Conway Reviewed-By: Tom Lane Discussion: https://postgr.es/m/02fa2d90-2efd-00bc-fefc-c23c00eb671e%40joeconway.com Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/80ca22aa60a6138b5ada890339dd6a6e2397222d Modified Files -- contrib/dblink/dblink.c | 31 ++- 1 file changed, 22 insertions(+), 9 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Make dblink try harder to form useful error messages
Make dblink try harder to form useful error messages When libpq encounters a connection-level error, e.g. runs out of memory while forming a result, there will be no error associated with PGresult, but a message will be placed into PGconn's error buffer. postgres_fdw takes care to use the PGconn error message when PGresult does not have one, but dblink has been negligent in that regard. Modify dblink to mirror what postgres_fdw has been doing. Back-patch to all supported branches. Author: Joe Conway Reviewed-By: Tom Lane Discussion: https://postgr.es/m/02fa2d90-2efd-00bc-fefc-c23c00eb671e%40joeconway.com Branch -- REL9_2_STABLE Details --- http://git.postgresql.org/pg/commitdiff/44de099f89c2a2d94c78f80f09555fd9b5792583 Modified Files -- contrib/dblink/dblink.c | 31 ++- 1 file changed, 22 insertions(+), 9 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Code review for ATExecAttachPartition.
Code review for ATExecAttachPartition. Amit Langote. Most of this reported by Álvaro Herrera. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/3ee80672847c4100d5f9efdb9ea19cb96506d089 Modified Files -- src/backend/commands/tablecmds.c | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Protect dblink from invalid options when using postgres_fdw serv
Protect dblink from invalid options when using postgres_fdw server When dblink uses a postgres_fdw server name for its connection, it is possible for the connection to have options that are invalid with dblink (e.g. "updatable"). The recommended way to avoid this problem is to use dblink_fdw servers instead. However there are use cases for using postgres_fdw, and possibly other FDWs, for dblink connection options, therefore protect against trying to use any options that do not apply by using is_valid_dblink_option() when building the connection string from the options. Back-patch to 9.3. Although 9.2 supports FDWs for connection info, is_valid_dblink_option() did not yet exist, and neither did postgres_fdw, at least in the postgres source tree. Given the lack of previous complaints, fixing that seems too invasive/not worth it. Author: Corey Huinker Reviewed-By: Joe Conway Discussion: https://postgr.es/m/CADkLM%3DfWyXVEyYcqbcRnxcHutkP45UHU9WD7XpdZaMfe7S%3DRwA%40mail.gmail.com Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/150841fb94f651a8e452d7a452c3225c2dafdf16 Modified Files -- contrib/dblink/dblink.c | 35 +-- 1 file changed, 29 insertions(+), 6 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Protect dblink from invalid options when using postgres_fdw serv
Protect dblink from invalid options when using postgres_fdw server When dblink uses a postgres_fdw server name for its connection, it is possible for the connection to have options that are invalid with dblink (e.g. "updatable"). The recommended way to avoid this problem is to use dblink_fdw servers instead. However there are use cases for using postgres_fdw, and possibly other FDWs, for dblink connection options, therefore protect against trying to use any options that do not apply by using is_valid_dblink_option() when building the connection string from the options. Back-patch to 9.3. Although 9.2 supports FDWs for connection info, is_valid_dblink_option() did not yet exist, and neither did postgres_fdw, at least in the postgres source tree. Given the lack of previous complaints, fixing that seems too invasive/not worth it. Author: Corey Huinker Reviewed-By: Joe Conway Discussion: https://postgr.es/m/CADkLM%3DfWyXVEyYcqbcRnxcHutkP45UHU9WD7XpdZaMfe7S%3DRwA%40mail.gmail.com Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/c4448683893bd37b59003603bc9075d362e81b5a Modified Files -- contrib/dblink/dblink.c | 35 +-- 1 file changed, 29 insertions(+), 6 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Protect dblink from invalid options when using postgres_fdw serv
Protect dblink from invalid options when using postgres_fdw server When dblink uses a postgres_fdw server name for its connection, it is possible for the connection to have options that are invalid with dblink (e.g. "updatable"). The recommended way to avoid this problem is to use dblink_fdw servers instead. However there are use cases for using postgres_fdw, and possibly other FDWs, for dblink connection options, therefore protect against trying to use any options that do not apply by using is_valid_dblink_option() when building the connection string from the options. Back-patch to 9.3. Although 9.2 supports FDWs for connection info, is_valid_dblink_option() did not yet exist, and neither did postgres_fdw, at least in the postgres source tree. Given the lack of previous complaints, fixing that seems too invasive/not worth it. Author: Corey Huinker Reviewed-By: Joe Conway Discussion: https://postgr.es/m/CADkLM%3DfWyXVEyYcqbcRnxcHutkP45UHU9WD7XpdZaMfe7S%3DRwA%40mail.gmail.com Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/d5c05f27a43fd0bc777b13dd50de203bade2118d Modified Files -- contrib/dblink/dblink.c | 35 +-- 1 file changed, 29 insertions(+), 6 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Protect dblink from invalid options when using postgres_fdw serv
Protect dblink from invalid options when using postgres_fdw server When dblink uses a postgres_fdw server name for its connection, it is possible for the connection to have options that are invalid with dblink (e.g. "updatable"). The recommended way to avoid this problem is to use dblink_fdw servers instead. However there are use cases for using postgres_fdw, and possibly other FDWs, for dblink connection options, therefore protect against trying to use any options that do not apply by using is_valid_dblink_option() when building the connection string from the options. Back-patch to 9.3. Although 9.2 supports FDWs for connection info, is_valid_dblink_option() did not yet exist, and neither did postgres_fdw, at least in the postgres source tree. Given the lack of previous complaints, fixing that seems too invasive/not worth it. Author: Corey Huinker Reviewed-By: Joe Conway Discussion: https://postgr.es/m/CADkLM%3DfWyXVEyYcqbcRnxcHutkP45UHU9WD7XpdZaMfe7S%3DRwA%40mail.gmail.com Branch -- REL9_4_STABLE Details --- http://git.postgresql.org/pg/commitdiff/cb687e0acfdfa3699e4b19b597aba37f686b9f16 Modified Files -- contrib/dblink/dblink.c | 35 +-- 1 file changed, 29 insertions(+), 6 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Protect dblink from invalid options when using postgres_fdw serv
Protect dblink from invalid options when using postgres_fdw server When dblink uses a postgres_fdw server name for its connection, it is possible for the connection to have options that are invalid with dblink (e.g. "updatable"). The recommended way to avoid this problem is to use dblink_fdw servers instead. However there are use cases for using postgres_fdw, and possibly other FDWs, for dblink connection options, therefore protect against trying to use any options that do not apply by using is_valid_dblink_option() when building the connection string from the options. Back-patch to 9.3. Although 9.2 supports FDWs for connection info, is_valid_dblink_option() did not yet exist, and neither did postgres_fdw, at least in the postgres source tree. Given the lack of previous complaints, fixing that seems too invasive/not worth it. Author: Corey Huinker Reviewed-By: Joe Conway Discussion: https://postgr.es/m/CADkLM%3DfWyXVEyYcqbcRnxcHutkP45UHU9WD7XpdZaMfe7S%3DRwA%40mail.gmail.com Branch -- REL9_3_STABLE Details --- http://git.postgresql.org/pg/commitdiff/bd46cce21476792c71952e23543bd943b160d0f1 Modified Files -- contrib/dblink/dblink.c | 35 +-- 1 file changed, 29 insertions(+), 6 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Simplify tape block format.
Simplify tape block format. No more indirect blocks. The blocks form a linked list instead. This saves some memory, because we don't need to have a buffer in memory to hold the indirect block (or blocks). To reflect that, TAPE_BUFFER_OVERHEAD is reduced from 3 to 1 buffer, which allows using more memory for building the initial runs. Reviewed by Peter Geoghegan and Robert Haas. Discussion: https://www.postgresql.org/message-id/34678beb-938e-646e-db9f-a7def5c44ada%40iki.fi Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/01ec25631fe0eae6af67c29c61a358dc6b92ed3c Modified Files -- src/backend/utils/sort/logtape.c | 627 +++-- src/backend/utils/sort/tuplesort.c | 65 ++-- src/include/utils/logtape.h| 4 +- 3 files changed, 218 insertions(+), 478 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Give a useful error message if uuid-ossp is built without precon
Give a useful error message if uuid-ossp is built without preconfiguration. Before commit b8cc8f947, it was possible to build contrib/uuid-ossp without having told configure you meant to; you could just cd into that directory and "make". That no longer works because the code depends on configure to have done header and library probes, but the ensuing error messages are not so easy to interpret if you're not an old C hand. We've gotten a couple of complaints recently from people trying to do this the low-tech way, so add an explicit #error directing the user to use --with-uuid. (In principle we might want to do something similar in the other optionally-built contrib modules; but I don't think any of the others have ever worked without preconfiguration, so there are no bad habits to break people of.) Back-patch to 9.4 where the previous commit came in. Report: https://postgr.es/m/CAHeEsBf42AWTnk=1qjvfv+mygrfm07knsfuc86ono8nrjf3...@mail.gmail.com Report: https://postgr.es/m/cakydkbruazx+f6kpmzohqmtiuqctaw_w6dgvr6f0wtiopug...@mail.gmail.com Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/60ad2ff586b1bb37930460f4fbba9e4a1c83ded1 Modified Files -- contrib/uuid-ossp/uuid-ossp.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Give a useful error message if uuid-ossp is built without precon
Give a useful error message if uuid-ossp is built without preconfiguration. Before commit b8cc8f947, it was possible to build contrib/uuid-ossp without having told configure you meant to; you could just cd into that directory and "make". That no longer works because the code depends on configure to have done header and library probes, but the ensuing error messages are not so easy to interpret if you're not an old C hand. We've gotten a couple of complaints recently from people trying to do this the low-tech way, so add an explicit #error directing the user to use --with-uuid. (In principle we might want to do something similar in the other optionally-built contrib modules; but I don't think any of the others have ever worked without preconfiguration, so there are no bad habits to break people of.) Back-patch to 9.4 where the previous commit came in. Report: https://postgr.es/m/CAHeEsBf42AWTnk=1qjvfv+mygrfm07knsfuc86ono8nrjf3...@mail.gmail.com Report: https://postgr.es/m/cakydkbruazx+f6kpmzohqmtiuqctaw_w6dgvr6f0wtiopug...@mail.gmail.com Branch -- REL9_4_STABLE Details --- http://git.postgresql.org/pg/commitdiff/2807080fb995110466c2207da2f6bbebe28875f4 Modified Files -- contrib/uuid-ossp/uuid-ossp.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Give a useful error message if uuid-ossp is built without precon
Give a useful error message if uuid-ossp is built without preconfiguration. Before commit b8cc8f947, it was possible to build contrib/uuid-ossp without having told configure you meant to; you could just cd into that directory and "make". That no longer works because the code depends on configure to have done header and library probes, but the ensuing error messages are not so easy to interpret if you're not an old C hand. We've gotten a couple of complaints recently from people trying to do this the low-tech way, so add an explicit #error directing the user to use --with-uuid. (In principle we might want to do something similar in the other optionally-built contrib modules; but I don't think any of the others have ever worked without preconfiguration, so there are no bad habits to break people of.) Back-patch to 9.4 where the previous commit came in. Report: https://postgr.es/m/CAHeEsBf42AWTnk=1qjvfv+mygrfm07knsfuc86ono8nrjf3...@mail.gmail.com Report: https://postgr.es/m/cakydkbruazx+f6kpmzohqmtiuqctaw_w6dgvr6f0wtiopug...@mail.gmail.com Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/b86515da1a73d0a2e23aca728f18b5f9e809e89f Modified Files -- contrib/uuid-ossp/uuid-ossp.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Give a useful error message if uuid-ossp is built without precon
Give a useful error message if uuid-ossp is built without preconfiguration. Before commit b8cc8f947, it was possible to build contrib/uuid-ossp without having told configure you meant to; you could just cd into that directory and "make". That no longer works because the code depends on configure to have done header and library probes, but the ensuing error messages are not so easy to interpret if you're not an old C hand. We've gotten a couple of complaints recently from people trying to do this the low-tech way, so add an explicit #error directing the user to use --with-uuid. (In principle we might want to do something similar in the other optionally-built contrib modules; but I don't think any of the others have ever worked without preconfiguration, so there are no bad habits to break people of.) Back-patch to 9.4 where the previous commit came in. Report: https://postgr.es/m/CAHeEsBf42AWTnk=1qjvfv+mygrfm07knsfuc86ono8nrjf3...@mail.gmail.com Report: https://postgr.es/m/cakydkbruazx+f6kpmzohqmtiuqctaw_w6dgvr6f0wtiopug...@mail.gmail.com Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/1cfdb29c7d6621f81d3835e20fd846552c08ec9a Modified Files -- contrib/uuid-ossp/uuid-ossp.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Fix base backup rate limiting in presence of slow i/o
On 21 December 2016 at 20:20, Magnus Hagander wrote: > On Wed, Dec 21, 2016 at 6:55 PM, Dean Rasheed >> basebackup.c: In function ‘throttle’: >> basebackup.c:1284:8: warning: variable ‘wait_result’ set but not used >> [-Wunused-but-set-variable] >> int wait_result; > > Interesting. > > ff44fba4 replaced the latch in walsender, which was not backported (of > course). > > But it also added a CHECK_FOR_INTERRUPTS there. > > 9.4 does not have a CHECK_FOR_INTERRUPTS anywhere near there. Perhaps what's > really needed is to put one of those in regardless? > Yeah, it seems reasonable that there should be a CHECK_FOR_INTERRUPTS() there. I'm not really familiar with that code, but it looks like the signal handler in 9.4 might not set that latch, so throttle() would have to rely on setting ImmediateInterruptOK to make the sleep interruptable, in which case the wait result would be irrelevant, right? Regards, Dean -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
