[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

[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

[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

[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

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 --

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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] >>