Re: High Availability, Load Balancing, and Replication Feature Matrix
> Oops. Forgot to attach the patch. > >> In the table no bull mark is in "No conflict resolution necessary" row >> for pgpool-II. Actually this is wrong. Pgpool-II does not need >> conflict resolution. >> >> Also in the same page "Pgpool-II has this capability." (here "this" >> means "Multiple-Server Parallel Query Execution") This used to be true >> long time ago but current stable versions of Pgpool-II do not support >> this any more. >> >> Attached patch fixes these. If there's no objection, I am going to commit this. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
Table Partitioning
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/12/ddl-partitioning.html Description: With version 12 using declarative partitioning request that the column used for patitioning is part of the PRIMARY KEY of the table as you can see in the error message below. ERROR: insufficient columns in PRIMARY KEY constraint definition DETAIL: PRIMARY KEY constraint on table "ztest" lacks column "mtime" which is part of the partition key. If I've well understood, this was not the case in previous versions, but it becomes mandatory in version 12 (and maybe 11 too). Such restriction is not mentioned in the documentation for version 12 and would be suitable to be. Best regards
Re: High Availability, Load Balancing, and Replication Feature Matrix
On Thu, Jul 30, 2020 at 04:02:25PM +0900, Tatsuo Ishii wrote: > > > Oops. Forgot to attach the patch. > > > >> In the table no bull mark is in "No conflict resolution necessary" row > >> for pgpool-II. Actually this is wrong. Pgpool-II does not need > >> conflict resolution. > >> > >> Also in the same page "Pgpool-II has this capability." (here "this" > >> means "Multiple-Server Parallel Query Execution") This used to be true > >> long time ago but current stable versions of Pgpool-II do not support > >> this any more. > >> > >> Attached patch fixes these. > > If there's no objection, I am going to commit this. +1 -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
Re: Table Partitioning
On Thu, Jul 30, 2020 at 01:33:29PM +, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/12/ddl-partitioning.html > Description: > > With version 12 using declarative partitioning request that the column used > for patitioning is part of the PRIMARY KEY of the table as you can see in > the error message below. > > ERROR: insufficient columns in PRIMARY KEY constraint definition > DETAIL: PRIMARY KEY constraint on table "ztest" lacks column "mtime" which > is part of the partition key. > > If I've well understood, this was not the case in previous versions, but it > becomes mandatory in version 12 (and maybe 11 too). Such restriction is not > mentioned in the documentation for version 12 and would be suitable to be. Can you give us a reproducible test case? -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
Re: Table Partitioning
Bruce Momjian writes: > On Thu, Jul 30, 2020 at 01:33:29PM +, PG Doc comments form wrote: >> If I've well understood, this was not the case in previous versions, but it >> becomes mandatory in version 12 (and maybe 11 too). Such restriction is not >> mentioned in the documentation for version 12 and would be suitable to be. > Can you give us a reproducible test case? I don't think this is correct at all. The facility for pkeys or unique constraints on partitioned tables simply didn't exist before v11: $ psql psql (10.13) Type "help" for help. postgres=# create table p(f1 int primary key, f2 int) partition by list(f2); ERROR: primary key constraints are not supported on partitioned tables LINE 1: create table p(f1 int primary key, f2 int) partition by list... ^ postgres=# create table p(f1 int unique, f2 int) partition by list(f2); ERROR: unique constraints are not supported on partitioned tables LINE 1: create table p(f1 int unique, f2 int) partition by list(f2); ^ so the fact that they're restricted in this way as of v11 and up does not represent any loss of functionality. regards, tom lane
Re: High Availability, Load Balancing, and Replication Feature Matrix
> On Thu, Jul 30, 2020 at 04:02:25PM +0900, Tatsuo Ishii wrote: >> >> > Oops. Forgot to attach the patch. >> > >> >> In the table no bull mark is in "No conflict resolution necessary" row >> >> for pgpool-II. Actually this is wrong. Pgpool-II does not need >> >> conflict resolution. >> >> >> >> Also in the same page "Pgpool-II has this capability." (here "this" >> >> means "Multiple-Server Parallel Query Execution") This used to be true >> >> long time ago but current stable versions of Pgpool-II do not support >> >> this any more. >> >> >> >> Attached patch fixes these. >> >> If there's no objection, I am going to commit this. > > +1 Fix pushed to all supported branches. Thanks! -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
Re: [DOCS] Let's document a bytea bug
Hi Anna! > 23 мая 2018 г., в 20:33, Anna Akenteva написал(а): > > > Some time ago I've encountered a problem with the bytea type: we can't SELECT > bytea strings whose textual representation is too big to fit into > StringInfoData. > And as a side effect, pg_dump refuses to dump tables with big bytea strings. > > It's a bug, it's pretty confusing, but it seems like there's no pretty way > to fix it so far. Here's a link to a recent discussion on the issue: > https://www.postgresql.org/message-id/flat/c8bdf802d41ec37003ec3b726db79...@postgrespro.ru#c8bdf802d41ec37003ec3b726db79...@postgrespro.ru > > Since it won't be fixed anytime soon, I thought it could be worth documenting. > Attaching a patch for the documentation: I added some text to the "Binary > Data Types" > part where I tried to describe the issue and to explain how to deal with it. > > My patch in plain text (for convenience): > > It is not recommended to use bytea strings whose textual representation > exceeds 1GB, as it may not be possible to SELECT them due to output size > limitations. Consequently, a table containing such big strings cannot be > properly processed by pg_dump, as pg_dump will try to SELECT these values > from the > table and fail. The exact size limit advised for bytea strings depends on > their > content, the external format and encoding that you are using, the context in > which they will be selected. The general rule is that when you use SELECT, > the returned tuple should not exceed 1GB. Although even if SELECT does not > work, you can still retrieve big bytea strings using COPY in binary format. Thanks for this message. It took me a while to find out what was the problem. +1 for documenting this, maybe even with exact error like [ 2020-07-30 01:20:32.248 MSK pg_dump - 10.3.3.30,XX000 ]:ERROR: invalid memory alloc request size 1472599557 It's really really scary. My first feeling was that it's TOAST corruption. Best regards, Andrey Borodin.
