On Sat, 16 Mar 2024 at 21:13, Euler Taveira <eu...@eulerto.com> wrote: > > On Fri, Mar 15, 2024, at 3:34 AM, Amit Kapila wrote: > > Did you consider adding options for publication/subscription/slot > names as mentioned in my previous email? As discussed in a few emails > above, it would be quite confusing for users to identify the logical > replication objects once the standby is converted to subscriber. > > > Yes. I was wondering to implement after v1 is pushed. I started to write a > code > for it but I wasn't sure about the UI. The best approach I came up with was > multiple options in the same order. (I don't provide short options to avoid > possible portability issues with the order.) It means if I have 3 databases > and > the following command-line: > > pg_createsubscriber ... --database pg1 --database pg2 --database3 > --publication > pubx --publication puby --publication pubz > > pubx, puby and pubz are created in the database pg1, pg2, and pg3 > respectively. > > It seems we care only for publications created on the primary. Isn't > it possible that some of the publications have been replicated to > standby by that time, for example, in case failure happens after > creating a few publications? IIUC, we don't care for standby cleanup > after failure because it can't be used for streaming replication > anymore. So, the only choice the user has is to recreate the standby > and start the pg_createsubscriber again. This sounds questionable to > me as to whether users would like this behavior. Does anyone else have > an opinion on this point? > > > If it happens after creating a publication and before promotion, the cleanup > routine will drop the publications on primary and it will eventually be > applied > to the standby via replication later. > > I see the below note in the patch: > + If <application>pg_createsubscriber</application> fails while processing, > + then the data directory is likely not in a state that can be recovered. > It > + is true if the target server was promoted. In such a case, creating a new > + standby server is recommended. > > By reading this it is not completely clear whether the standby is not > recoverable in case of any error or only an error after the target > server is promoted. If others agree with this behavior then we should > write the detailed reason for this somewhere in the comments as well > unless it is already explained. > > > I rewrote the sentence to make it clear that only if the server is promoted, > the target server will be in a state that cannot be reused. It provides a > message saying it too. > > pg_createsubscriber: target server reached the consistent state > pg_createsubscriber: hint: If pg_createsubscriber fails after this point, you > must recreate the physical replica before continuing. > > I'm attaching a new version (v30) that adds: > > * 3 new options (--publication, --subscription, --replication-slot) to assign > names to the objects. The --database option used to ignore duplicate names, > however, since these new options rely on the number of database options to > match the number of object name options, it is forbidden from now on. The > duplication is also forbidden for the object names to avoid errors earlier. > * rewrite the paragraph related to unusuable target server after > pg_createsubscriber fails.
1) Maximum size of the object name is 64, we can have a check so that we don't specify more than the maximum allowed length: + case 3: + if (!simple_string_list_member(&opt.replslot_names, optarg)) + { + simple_string_list_append(&opt.replslot_names, optarg); + num_replslots++; + } + else + { + pg_log_error("duplicate replication slot \"%s\"", optarg); + exit(1); + } + break; If we allow something like this: ./pg_createsubscriber -U postgres -D data_N2/ -P "port=5431 user=postgres" -p 5432 -s /home/vignesh/postgres/inst/bin/ -d db1 -d db2 -d db3 --replication-slot="testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttes1" --replication-slot="testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttes2" --replication-slot="testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttes3" In this case creation of replication slot will fail: pg_createsubscriber: error: could not create replication slot "testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttes" on database "db2": ERROR: replication slot "testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttes" already exists 2) Similarly here too: + case 4: + if (!simple_string_list_member(&opt.sub_names, optarg)) + { + simple_string_list_append(&opt.sub_names, optarg); + num_subs++; + } + else + { + pg_log_error("duplicate subscription \"%s\"", optarg); + exit(1); + } + break; If we allow something like this: ./pg_createsubscriber -U postgres -D data_N2/ -P "port=5431 user=postgres" -p 5432 -s /home/vignesh/postgres/inst/bin/ -d db1 -d db2 -d db3 --subscription=testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttes1 --subscription=testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttes2 --subscription=testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttes3 Subscriptions will be created with the same name and later there will be a problem when setting replication progress as there will be multiple subscriptions with the same name. Regards, Vignesh