Re: clarifying trigger/rule behavior on logical replication subscribers
On Wed, 7 Jun 2023 at 10:17, Jonathan S. Katz wrote: > > Hi, > > While answering a question on "do triggers fire on a logical replication > subscriber by default?" I tried to look up a reference to this behavior > in the docs. There wasn't a clear reference point, but on the > architecture page[1], I found this line that was closest to the answer: > > "The apply process on the subscriber database always runs with > session_replication_role set to replica, which produces the usual > effects on triggers and constraints." > > which assumes that the reader knows what the "usual effects" are. > > Attached is a patch that disambiguates this. > Thanks for the patch, one small change required, "literal>" should be "": + enable triggers and rules on a table using the + ALTER TABLE command + and the literal>ENABLE TRIGGER and ENABLE RULE Regards, Vignesh
Re: create table explicitly mention that unique|primary key constraint will create an
On Fri, 19 Jan 2024 at 16:16, Laurenz Albe wrote: > > On Thu, 2024-01-18 at 15:54 +0100, Peter Eisentraut wrote: > > On 27.11.23 03:30, Laurenz Albe wrote: > > > True; I don't find it documented that all objects in pg_class share a > > > namespace and that constraints are implemented by indexes of the same > > > name. But I think that the first part is a property of schemas and had > > > better be documented there. > > > > It is documented prominently on the CREATE INDEX reference page. We > > could document it in more places, of course. I find the specific change > > proposal for ddl.sgml a bit weird, though, because this is a very > > introductory section, and you are referring people to pg_class (what is > > that?!?) for details. If we want to put something there, it should > > respect the order in which that chapter introduces concepts. > > > > The changes on create_table.sgml seem ok. Although I had actually > > expected that the system applies the find-a-unique-name routine rather > > than taking the constraint name for the index name unaltered. > > > > Perhaps taking the create_table.sgml changes and combination with the > > existing text on CREATE INDEX is sufficient. > > Ah, I didn't see the CREATE INDEX page. (As an aside: too much > conceptual stuff is documented in our reference pages, but that's a > different issue.) > > For me, the intuitive place to look for information like that is the > "Data Definition" chapter, so I think we should mention it there. > I agree that "pg_class" is too advanced for that chapter, even though > there is an earlier reference to it under "System Columns". > > In the attached patch, I have copied the enumeration of relations from > the CREATE INDEX page. I think this small redundance is alright, but I > wouldn't mind if this gets removed from CREATE INDEX. > > The rest is unmodified. CFBot shows that the patch does not apply anymore as in [1]: === Applying patches on top of PostgreSQL commit ID d282e88e50521a457fa1b36e55f43bac02a3167f === === applying patch ./v3-0001-Doc-All-relations-share-a-namespace.patch ... patching file doc/src/sgml/ref/create_table.sgml Hunk #1 FAILED at 1001. Hunk #2 FAILED at 1054. Hunk #3 succeeded at 1118 (offset 27 lines). 2 out of 3 hunks FAILED -- saving rejects to file doc/src/sgml/ref/create_table.sgml.rej Please post an updated version for the same. [1] - http://cfbot.cputube.org/patch_46_4747.log Regards, Vignesh
Re: Ambiguous description on new columns
On Wed, 22 May 2024 at 08:18, Peter Smith wrote: > > On Tue, May 21, 2024 at 8:40 PM PG Doc comments form > wrote: > > > > The following documentation comment has been logged on the website: > > > > Page: https://www.postgresql.org/docs/16/logical-replication-col-lists.html > > Description: > > > > The documentation on this page mentions: > > > > "If no column list is specified, any columns added later are automatically > > replicated." > > > > It feels ambiguous what this could mean. Does it mean: > > > > 1/ That if you alter the table on the publisher and add a new column, it > > will be replicated > > > > 2/ If you add a column list later and add a column to it, it will be > > replicated > > > > In both cases, does the subscriber automatically create this column if it > > wasn't there before? > > No, the subscriber will not automatically create the column. That is > already clearly said at the top of the same page you linked "The table > on the subscriber side must have at least all the columns that are > published." > > All that "If no column list..." paragraph was trying to say is: > > CREATE PUBLICATION pub FOR TABLE T; > > is not quite the same as: > > CREATE PUBLICATION pub FOR TABLE T(a,b,c); > > The difference is, in the 1st case if you then ALTER the TABLE T to > have a new column 'd' then that will automatically start replicating > the 'd' data without having to do anything to either the PUBLICATION > or the SUBSCRIPTION. Of course, if TABLE T at the subscriber side does > not have a column 'd' then you'll get an error because your subscriber > table needs to have *at least* all the replicated columns. (I > demonstrate this error below) > > Whereas in the 2nd case, even though you ALTER'ed the TABLE T to have > a new column 'd' then that won't be replicated because 'd' was not > named in the PUBLICATION's column list. > > > > Here's an example where you can see this in action > > Here is an example of the 1st case -- it shows 'd' is automatically > replicated and also shows the subscriber-side error caused by the > missing column: > > test_pub=# CREATE TABLE T(a int,b int, c int); > test_pub=# CREATE PUBLICATION pub FOR TABLE T; > > test_sub=# CREATE TABLE T(a int,b int, c int); > test_sub=# CREATE SUBSCRIPTION sub CONNECTION 'dbname=test_pub' PUBLICATION > pub; > > See the replication happening > test_pub=# INSERT INTO T VALUES (1,2,3); > test_sub=# SELECT * FROM t; > a | b | c > ---+---+--- > 1 | 2 | 3 > (1 row) > > Now alter the publisher table T and insert some new data > test_pub=# ALTER TABLE T ADD COLUMN d int; > test_pub=# INSERT INTO T VALUES (5,6,7,8); > > This will cause subscription errors like: > 2024-05-22 11:53:19.098 AEST [16226] ERROR: logical replication > target relation "public.t" is missing replicated column: "d" > > > > I think the following small change will remove any ambiguity: > > BEFORE > If no column list is specified, any columns added later are > automatically replicated. > > SUGGESTION > If no column list is specified, any columns added to the table later > are automatically replicated. > > ~~ > > I attached a small patch to make the above change. > > Thoughts? A minor suggestion, the rest looks good: It would enhance clarity to include a line break following "If no column list is specified, any columns added to the table later are": - If no column list is specified, any columns added later are automatically + If no column list is specified, any columns added to the table later are automatically replicated. This means that having a column list which names all columns Regards, Vignesh
Re: Ambiguous description on new columns
On Thu, 30 May 2024 at 06:21, Peter Smith wrote: > > On Wed, May 29, 2024 at 8:04 PM vignesh C wrote: > > > > On Wed, 22 May 2024 at 14:26, Peter Smith wrote: > > > > > > On Tue, May 21, 2024 at 8:40 PM PG Doc comments form > > > wrote: > > > > > > > > The following documentation comment has been logged on the website: > > > > > > > > Page: > > > > https://www.postgresql.org/docs/16/logical-replication-col-lists.html > > > > Description: > > > > > > > > The documentation on this page mentions: > > > > > > > > "If no column list is specified, any columns added later are > > > > automatically > > > > replicated." > > > > > > > > It feels ambiguous what this could mean. Does it mean: > > > > > > > > 1/ That if you alter the table on the publisher and add a new column, it > > > > will be replicated > > > > > > > > 2/ If you add a column list later and add a column to it, it will be > > > > replicated > > > > > > > > In both cases, does the subscriber automatically create this column if > > > > it > > > > wasn't there before? > > > > > > No, the subscriber will not automatically create the column. That is > > > already clearly said at the top of the same page you linked "The table > > > on the subscriber side must have at least all the columns that are > > > published." > > > > > > All that "If no column list..." paragraph was trying to say is: > > > > > > CREATE PUBLICATION pub FOR TABLE T; > > > > > > is not quite the same as: > > > > > > CREATE PUBLICATION pub FOR TABLE T(a,b,c); > > > > > > The difference is, in the 1st case if you then ALTER the TABLE T to > > > have a new column 'd' then that will automatically start replicating > > > the 'd' data without having to do anything to either the PUBLICATION > > > or the SUBSCRIPTION. Of course, if TABLE T at the subscriber side does > > > not have a column 'd' then you'll get an error because your subscriber > > > table needs to have *at least* all the replicated columns. (I > > > demonstrate this error below) > > > > > > Whereas in the 2nd case, even though you ALTER'ed the TABLE T to have > > > a new column 'd' then that won't be replicated because 'd' was not > > > named in the PUBLICATION's column list. > > > > > > > > > > > > Here's an example where you can see this in action > > > > > > Here is an example of the 1st case -- it shows 'd' is automatically > > > replicated and also shows the subscriber-side error caused by the > > > missing column: > > > > > > test_pub=# CREATE TABLE T(a int,b int, c int); > > > test_pub=# CREATE PUBLICATION pub FOR TABLE T; > > > > > > test_sub=# CREATE TABLE T(a int,b int, c int); > > > test_sub=# CREATE SUBSCRIPTION sub CONNECTION 'dbname=test_pub' > > > PUBLICATION pub; > > > > > > See the replication happening > > > test_pub=# INSERT INTO T VALUES (1,2,3); > > > test_sub=# SELECT * FROM t; > > > a | b | c > > > ---+---+--- > > > 1 | 2 | 3 > > > (1 row) > > > > > > Now alter the publisher table T and insert some new data > > > test_pub=# ALTER TABLE T ADD COLUMN d int; > > > test_pub=# INSERT INTO T VALUES (5,6,7,8); > > > > > > This will cause subscription errors like: > > > 2024-05-22 11:53:19.098 AEST [16226] ERROR: logical replication > > > target relation "public.t" is missing replicated column: "d" > > > > > > > > > > > > I think the following small change will remove any ambiguity: > > > > > > BEFORE > > > If no column list is specified, any columns added later are > > > automatically replicated. > > > > > > SUGGESTION > > > If no column list is specified, any columns added to the table later > > > are automatically replicated. > > > > > > ~~ > > > > > > I attached a small patch to make the above change. > > > > A small recommendation: > > It would enhance clarity to include a line break following "If no > > column list is specified, any columns added to the table later are": > > - If no column list is specified, any columns added later are > > automatically > > + If no column list is specified, any columns added to the table > > later are automatically > > replicated. This means that having a column list which names all columns > > Hi Vignesh, > > IIUC you're saying my v1 patch *content* and rendering is OK, but you > only wanted the SGML text to have better wrapping for < 80 chars > lines. So I have attached a patch v2 with improved wrapping. If you > meant something different then please explain. Yes, that is what I meant and the updated patch looks good. Regards, Vignesh
Re: Ambiguous description on new columns
On Fri, 31 May 2024 at 08:58, vignesh C wrote: > > On Thu, 30 May 2024 at 06:21, Peter Smith wrote: > > > > On Wed, May 29, 2024 at 8:04 PM vignesh C wrote: > > > > > > On Wed, 22 May 2024 at 14:26, Peter Smith wrote: > > > > > > > > On Tue, May 21, 2024 at 8:40 PM PG Doc comments form > > > > wrote: > > > > > > > > > > The following documentation comment has been logged on the website: > > > > > > > > > > Page: > > > > > https://www.postgresql.org/docs/16/logical-replication-col-lists.html > > > > > Description: > > > > > > > > > > The documentation on this page mentions: > > > > > > > > > > "If no column list is specified, any columns added later are > > > > > automatically > > > > > replicated." > > > > > > > > > > It feels ambiguous what this could mean. Does it mean: > > > > > > > > > > 1/ That if you alter the table on the publisher and add a new column, > > > > > it > > > > > will be replicated > > > > > > > > > > 2/ If you add a column list later and add a column to it, it will be > > > > > replicated > > > > > > > > > > In both cases, does the subscriber automatically create this column > > > > > if it > > > > > wasn't there before? > > > > > > > > No, the subscriber will not automatically create the column. That is > > > > already clearly said at the top of the same page you linked "The table > > > > on the subscriber side must have at least all the columns that are > > > > published." > > > > > > > > All that "If no column list..." paragraph was trying to say is: > > > > > > > > CREATE PUBLICATION pub FOR TABLE T; > > > > > > > > is not quite the same as: > > > > > > > > CREATE PUBLICATION pub FOR TABLE T(a,b,c); > > > > > > > > The difference is, in the 1st case if you then ALTER the TABLE T to > > > > have a new column 'd' then that will automatically start replicating > > > > the 'd' data without having to do anything to either the PUBLICATION > > > > or the SUBSCRIPTION. Of course, if TABLE T at the subscriber side does > > > > not have a column 'd' then you'll get an error because your subscriber > > > > table needs to have *at least* all the replicated columns. (I > > > > demonstrate this error below) > > > > > > > > Whereas in the 2nd case, even though you ALTER'ed the TABLE T to have > > > > a new column 'd' then that won't be replicated because 'd' was not > > > > named in the PUBLICATION's column list. > > > > > > > > > > > > > > > > Here's an example where you can see this in action > > > > > > > > Here is an example of the 1st case -- it shows 'd' is automatically > > > > replicated and also shows the subscriber-side error caused by the > > > > missing column: > > > > > > > > test_pub=# CREATE TABLE T(a int,b int, c int); > > > > test_pub=# CREATE PUBLICATION pub FOR TABLE T; > > > > > > > > test_sub=# CREATE TABLE T(a int,b int, c int); > > > > test_sub=# CREATE SUBSCRIPTION sub CONNECTION 'dbname=test_pub' > > > > PUBLICATION pub; > > > > > > > > See the replication happening > > > > test_pub=# INSERT INTO T VALUES (1,2,3); > > > > test_sub=# SELECT * FROM t; > > > > a | b | c > > > > ---+---+--- > > > > 1 | 2 | 3 > > > > (1 row) > > > > > > > > Now alter the publisher table T and insert some new data > > > > test_pub=# ALTER TABLE T ADD COLUMN d int; > > > > test_pub=# INSERT INTO T VALUES (5,6,7,8); > > > > > > > > This will cause subscription errors like: > > > > 2024-05-22 11:53:19.098 AEST [16226] ERROR: logical replication > > > > target relation "public.t" is missing replicated column: "d" > > > > > > > > > > > > > > > > I think the following small change will remove any ambiguity: > > > > > > > > BEFORE > > > > If no column list is specified, any columns added later are > > > > automatically replicated. > > > > > > > > SUGGESTION > > > > If no column list is specified, any columns added to the table later > > > > are automatically replicated. > > > > > > > > ~~ > > > > > > > > I attached a small patch to make the above change. > > > > > > A small recommendation: > > > It would enhance clarity to include a line break following "If no > > > column list is specified, any columns added to the table later are": > > > - If no column list is specified, any columns added later are > > > automatically > > > + If no column list is specified, any columns added to the table > > > later are automatically > > > replicated. This means that having a column list which names all > > > columns > > > > Hi Vignesh, > > > > IIUC you're saying my v1 patch *content* and rendering is OK, but you > > only wanted the SGML text to have better wrapping for < 80 chars > > lines. So I have attached a patch v2 with improved wrapping. If you > > meant something different then please explain. > > Yes, that is what I meant and the updated patch looks good. Adding Amit to get his opinion on the same. Regards, Vignesh
Title updation while documentation is generated using STYLE=website
Hi, While building the documentation with make STYLE=website html, I noticed inconsistencies in the formatting of the starting letter of each word in the titles. For instance: "Obtaining Information about an Error" becomes "Obtaining Information About An Error" in html/plpgsql-control-structures.html. "Multiple Statements in a Simple Query" changes to "Multiple Statements In A Simple Query" in html/protocol-flow.html. "Returning from a Function" remains unchanged in html/plpgsql-control-structures.html. "Obtaining Information about an Error" is also unchanged in html/plpgsql-control-structures.html. "RETURN NEXT and RETURN QUERY" changes to "RETURN NEXT And RETURN QUERY" in html/plpgsql-control-structures.html. There are many similar cases throughout the code. I believe this might be related to the stylesheet, as the original text appears intact when I copy the generated HTML and paste it into Notepad. I could not get details about this from [1]. How is the styling being applied for the titles? Please share the link to this if it is available. [1] - https://www.postgresql.org/docs/current/docguide-build.html Regards, Vignesh
Re: pg_createsubscriber: publication-name and subscription-name options do not exist
On Mon, 2 Dec 2024 at 15:00, Shubham Khanna wrote: > > On Mon, Dec 2, 2024 at 2:57 PM PG Doc comments form > wrote: > > > > The following documentation comment has been logged on the website: > > > > Page: https://www.postgresql.org/docs/17/app-pgcreatesubscriber.html > > Description: > > > > The page https://www.postgresql.org/docs/17/app-pgcreatesubscriber.html > > mentions these two options: > > “If publication-name option is not specified …“ > > “If subscription-name is not specified …“ > > > > while `pg_createsubscriber --help` returns: > > > > --publication=NAME publication name > > --replication-slot=NAME replication slot name > > --subscription=NAME subscription name > > > > I suppose that the options should be respectively --publication and > > --subscription. > > > > I have updated the Documentation for pg_createsubscriber with the > suggested changes. The attached Patch contains the required changes. Thanks for the patch, one suggestion: We can change "subscription" to "subscription option" to keep it consistent with publication option documentation just above a few lines which mentions it like "If publication option is not specified": Create a subscription for each specified database on the target server. - If subscription-name is not specified, the subscription + If subscription is not specified, the subscription has the following name pattern: pg_createsubscriber_%u_%x (parameters: Regards, Vignesh
