pgsql: Set relispartition correctly for index partitions

Set relispartition correctly for index partitions Oversight in commit 8b08f7d4820f: pg_class.relispartition was not being set for index partitions, which is a bit odd, and was also causing the code to unnecessarily call has_superclass() when simply checking the flag was enough. Author: Álvaro

pgsql: Ignore nextOid when replaying an ONLINE checkpoint.

Ignore nextOid when replaying an ONLINE checkpoint. The nextOid value is from the start of the checkpoint and may well be stale compared to values from more recent XLOG_NEXTOID records. Previously, we adopted it anyway, allowing the OID counter to go backwards during a crash. While this should

pgsql: Ignore nextOid when replaying an ONLINE checkpoint.

Ignore nextOid when replaying an ONLINE checkpoint. The nextOid value is from the start of the checkpoint and may well be stale compared to values from more recent XLOG_NEXTOID records. Previously, we adopted it anyway, allowing the OID counter to go backwards during a crash. While this should

pgsql: Ignore nextOid when replaying an ONLINE checkpoint.

Ignore nextOid when replaying an ONLINE checkpoint. The nextOid value is from the start of the checkpoint and may well be stale compared to values from more recent XLOG_NEXTOID records. Previously, we adopted it anyway, allowing the OID counter to go backwards during a crash. While this should

pgsql: Ignore nextOid when replaying an ONLINE checkpoint.

Ignore nextOid when replaying an ONLINE checkpoint. The nextOid value is from the start of the checkpoint and may well be stale compared to values from more recent XLOG_NEXTOID records. Previously, we adopted it anyway, allowing the OID counter to go backwards during a crash. While this should

pgsql: Ignore nextOid when replaying an ONLINE checkpoint.

Ignore nextOid when replaying an ONLINE checkpoint. The nextOid value is from the start of the checkpoint and may well be stale compared to values from more recent XLOG_NEXTOID records. Previously, we adopted it anyway, allowing the OID counter to go backwards during a crash. While this should

pgsql: Do not select new object OIDs that match recently-dead entries.

Do not select new object OIDs that match recently-dead entries. When selecting a new OID, we take care to avoid picking one that's already in use in the target table, so as not to create duplicates after the OID counter has wrapped around. However, up to now we used SnapshotDirty when scanning

pgsql: Do not select new object OIDs that match recently-dead entries.

Do not select new object OIDs that match recently-dead entries. When selecting a new OID, we take care to avoid picking one that's already in use in the target table, so as not to create duplicates after the OID counter has wrapped around. However, up to now we used SnapshotDirty when scanning

pgsql: Do not select new object OIDs that match recently-dead entries.

Do not select new object OIDs that match recently-dead entries. When selecting a new OID, we take care to avoid picking one that's already in use in the target table, so as not to create duplicates after the OID counter has wrapped around. However, up to now we used SnapshotDirty when scanning

pgsql: Do not select new object OIDs that match recently-dead entries.

Do not select new object OIDs that match recently-dead entries. When selecting a new OID, we take care to avoid picking one that's already in use in the target table, so as not to create duplicates after the OID counter has wrapped around. However, up to now we used SnapshotDirty when scanning

pgsql: Do not select new object OIDs that match recently-dead entries.

Do not select new object OIDs that match recently-dead entries. When selecting a new OID, we take care to avoid picking one that's already in use in the target table, so as not to create duplicates after the OID counter has wrapped around. However, up to now we used SnapshotDirty when scanning

pgsql: Make local copy of client hostnames in backend status array.

Make local copy of client hostnames in backend status array. The other strings, application_name and query string, were snapshotted to local memory in pgstat_read_current_status(), but we forgot to do that for client hostnames. As a result, the client hostname would appear to change in the local

pgsql: Make local copy of client hostnames in backend status array.

Make local copy of client hostnames in backend status array. The other strings, application_name and query string, were snapshotted to local memory in pgstat_read_current_status(), but we forgot to do that for client hostnames. As a result, the client hostname would appear to change in the local

pgsql: Make local copy of client hostnames in backend status array.

Make local copy of client hostnames in backend status array. The other strings, application_name and query string, were snapshotted to local memory in pgstat_read_current_status(), but we forgot to do that for client hostnames. As a result, the client hostname would appear to change in the local

pgsql: Make local copy of client hostnames in backend status array.

Make local copy of client hostnames in backend status array. The other strings, application_name and query string, were snapshotted to local memory in pgstat_read_current_status(), but we forgot to do that for client hostnames. As a result, the client hostname would appear to change in the local

pgsql: Allocate enough shared string memory for stats of auxiliary proc

Allocate enough shared string memory for stats of auxiliary processes. This fixes a bug whereby the st_appname, st_clienthostname, and st_activity_raw fields for auxiliary processes point beyond the end of their respective shared memory segments. As a result, the application_name of a backend

pgsql: Make local copy of client hostnames in backend status array.

Make local copy of client hostnames in backend status array. The other strings, application_name and query string, were snapshotted to local memory in pgstat_read_current_status(), but we forgot to do that for client hostnames. As a result, the client hostname would appear to change in the local

pgsql: Make local copy of client hostnames in backend status array.

Make local copy of client hostnames in backend status array. The other strings, application_name and query string, were snapshotted to local memory in pgstat_read_current_status(), but we forgot to do that for client hostnames. As a result, the client hostname would appear to change in the local

pgsql: Allocate enough shared string memory for stats of auxiliary proc

Allocate enough shared string memory for stats of auxiliary processes. This fixes a bug whereby the st_appname, st_clienthostname, and st_activity_raw fields for auxiliary processes point beyond the end of their respective shared memory segments. As a result, the application_name of a backend

pgsql: Fix ALTER TABLE .. ATTACH PARTITION ... DEFAULT

Fix ALTER TABLE .. ATTACH PARTITION ... DEFAULT If the table being attached contained values that contradict the default partition's partition constraint, it would fail to complain, because CommandCounterIncrement changes in 4dba331cb3dc coupled with some bogus coding in the existing

Re: pgsql: Fix interference between cavering indexes and partitioned tables

On Wed, Apr 11, 2018 at 9:17 AM, Teodor Sigaev wrote: >> Several of the failing animals aren't using optimization, so it can't be >> just that. I think it might make sense considering reverting and trying > > Yep, but on my notebook - only with -02 I suggest using Valgrind to

pgsql: Invoke submake-generated-headers during "make check", too.

Invoke submake-generated-headers during "make check", too. The MAKELEVEL hack to prevent submake-generated-headers from doing anything in child make runs means that we have to explicitly invoke it at top level for "make check", too, in case somebody proceeds directly to that without an explicit

pgsql: Temporary revert 5c6110c6a960ad6fe1b0d0fec6ae36ef4eb913f5

Temporary revert 5c6110c6a960ad6fe1b0d0fec6ae36ef4eb913f5 It discovers one more bug in CompareIndexInfo(), should be fixed first. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/9282e13a089fb8915b02e45792998996530e Modified Files --

Re: pgsql: Fix interference between cavering indexes and partitioned tables

Andres Freund wrote: On 2018-04-11 19:04:53 +0300, Teodor Sigaev wrote: Seems, something is wrong here, investigating... pg_upgrade test fails only with -O2 on my box. Assert, debug could be any. Several of the failing animals aren't using optimization, so it can't be just that. I think

Re: pgsql: Fix interference between cavering indexes and partitioned tables

On 2018-04-11 19:04:53 +0300, Teodor Sigaev wrote: > > > Seems, something is wrong here, investigating... > > pg_upgrade test fails only with -O2 on my box. Assert, debug could be any. Several of the failing animals aren't using optimization, so it can't be just that. I think it might make

Re: pgsql: Fix interference between cavering indexes and partitioned tables

Seems, something is wrong here, investigating... pg_upgrade test fails only with -O2 on my box. Assert, debug could be any. -- Teodor Sigaev E-mail: teo...@sigaev.ru WWW: http://www.sigaev.ru/

pgsql: Fix clashing function names between jsonb_plperl and jsonb_plper

Fix clashing function names between jsonb_plperl and jsonb_plperlu This prevented them from being installed at the same time. Author: Dagfinn Ilmari Mannsåker Branch -- master Details ---

Re: pgsql: Fix interference between cavering indexes and partitioned tables

Seems, something is wrong here, investigating... Teodor Sigaev wrote: Fix interference between cavering indexes and partitioned tables The bug is caused due to the original IndexStmt that DefineIndex receives being overwritten when processing the INCLUDE columns. Use separate list of index

pgsql: Fix interference between cavering indexes and partitioned tables

Fix interference between cavering indexes and partitioned tables The bug is caused due to the original IndexStmt that DefineIndex receives being overwritten when processing the INCLUDE columns. Use separate list of index params to propagate to child tables. Add tests covering this case. Amit

pgsql: doc: Add more information about logical replication privileges

doc: Add more information about logical replication privileges In particular, the requirement to have SELECT privilege for the initial table copy was previously not documented. Author: Shinoda, Noriyoshi Branch -- REL_10_STABLE Details ---

pgsql: doc: Fix typos in pgbench documentation

doc: Fix typos in pgbench documentation Author: Fabien COELHO Reviewed-by: Edmund Horner Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/036ca6f7bb186ae8564fb9e3a27852757a9450be Modified Files --

Re: pgsql: Support partition pruning at execution time

On 10 April 2018 at 08:55, Tom Lane wrote: > Alvaro Herrera writes: >> David Rowley wrote: >>> Okay, I've written and attached a fix for this. I'm not 100% certain >>> that this is the cause of the problem on pademelon, but the code does >>> look