Continue Logical Replication After Master Became Slave and then Became Master Again
Hi All, Postgres 15.2 We have Patroni cluster with one master and two replicas. The master is publisher (logical replication) to some subscriptions running on other clusters. When we have a failover, the master becomes replica and one of the replicas assume the role of master. In such a case, we need to rebuild the subscriptions to point to the new master. However, to avoid that, can we just do fallback and move back to the old master assuming the following options - what if: 1. No data was written to the database from the time of the failover until the failback 2. No data was written to the replicated tables (but other tables were updated) from the time of the failover until the failback 3. The replicated tables were updated from the time of the failover until the failback Thanks IMPORTANT - This email and any attachments is intended for the above named addressee(s), and may contain information which is confidential or privileged. If you are not the intended recipient, please inform the sender immediately and delete this email: you should not copy or use this e-mail for any purpose nor disclose its contents to any person.
Request for new column in pg_namespace
https://www.postgresql.org/docs/current/catalog-pg-namespace.html Currently, when I want to query all "userland" tables, I write something like: select ... from pg_class cl, pg_namespace nsp where cl.relnamespace = nsp.oid and nsp.nspname not like 'pg_% and nsp.nspname != 'information_schema'; A new boolean column named "indissystem" that's true only for system relations would make *many* maintenance queries cleaner, since they'd look like: select ... from pg_class cl, pg_namespace nsp where cl.relnamespace = nsp.oid and nsp.indissystem = false; -- Death to , and butter sauce. Don't boil me, I'm still alive. lobster!
Re: Request for new column in pg_namespace
Isaac Morland writes: > On Sun, 15 Dec 2024 at 12:29, Tom Lane wrote: >> What I'd suggest as an improvement that could be implemented >> immediately is to wrap the checks in a user-defined function >> like "is_system_schema(nspname name)". > Would it make sense to make the parameter be of type regnamespace? Meh ... you could, but what the function really needs is the name. Getting from regnamespace (which is an OID) to the name would incur an extra syscache lookup. Admittedly, if it removes the need for the calling query to join to pg_namespace at all, you'd probably come out about even --- the net effect would be about like a hashjoin to pg_namespace, I think, since the syscache would act like the inner hashtable of a hashjoin. regards, tom lane
Re: Request for new column in pg_namespace
On Sun, Dec 15, 2024 at 12:29 PM Tom Lane wrote: > Pavel Stehule writes: > > ne 15. 12. 2024 v 17:59 odesílatel Ron Johnson > > napsal: > >> A new boolean column named "indissystem" that's true only for system > >> relations would make *many* maintenance queries cleaner, since they'd > >> look like: > >> select ... > > > oid of all system objects is less then 0x4000 > > That wouldn't help for excluding temp schemas, and it's not totally > trustworthy for information_schema either. > > But I think the real problem with Ron's proposal is that it presumes > there is a one-size-fits-all notion of "system schema". As a > counterexample, for some maintenance activities (such as vacuuming) > you might wish to process pg_catalog. > In that case, one would explicitly mention pg_catalog, no? where cl.relnamespace = nsp.oid and (nsp.indissystem = false or nsp.nspname = 'pg_catalog'); > What I'd suggest as an improvement that could be implemented > immediately is to wrap the checks in a user-defined function > like "is_system_schema(nspname name)". > Good idea. -- Death to , and butter sauce. Don't boil me, I'm still alive. lobster!
Re: Request for new column in pg_namespace
On Sun, Dec 15, 2024 at 2:20 PM Tom Lane wrote: > Isaac Morland writes: > > On Sun, 15 Dec 2024 at 12:29, Tom Lane wrote: > >> What I'd suggest as an improvement that could be implemented > >> immediately is to wrap the checks in a user-defined function > >> like "is_system_schema(nspname name)". > > > Would it make sense to make the parameter be of type regnamespace? > > Meh ... you could, but what the function really needs is the name. > Getting from regnamespace (which is an OID) to the name would incur > an extra syscache lookup. Admittedly, if it removes the need for > the calling query to join to pg_namespace at all, you'd probably > come out about even --- the net effect would be about like a > hashjoin to pg_namespace, I think, since the syscache would act > like the inner hashtable of a hashjoin. > It'll simplify the SQL to pass it a pg_class.relnamespace value, since that's what's stored in pg_class. select ... from pg_class cl INNER JOIN ... where not is_system_schema(cl.relnamespace) and ...; Might it be slightly slower? Sure... but pg_class and pg_namespace aren't giant tables, and the queries won't run thousands of times per day. Thus, in this case, a little less efficiency for much cleaner code is an acceptable trade-off TO ME. Heck, given how often "pg_class cl INNER JOIN pg_namespace nsp ON cl.relnamespace = nsp.oid" appears in my (and so much other code around the Internet), I should probably create a view that joins the two tables, and adds an is_system_schema column. That would *really* simplify my code... -- Death to , and butter sauce. Don't boil me, I'm still alive. lobster!
Re: Request for new column in pg_namespace
On Sun, 15 Dec 2024 at 12:29, Tom Lane wrote: > What I'd suggest as an improvement that could be implemented > immediately is to wrap the checks in a user-defined function > like "is_system_schema(nspname name)". > Would it make sense to make the parameter be of type regnamespace?
Re: Request for new column in pg_namespace
Pavel Stehule writes: > ne 15. 12. 2024 v 17:59 odesílatel Ron Johnson > napsal: >> A new boolean column named "indissystem" that's true only for system >> relations would make *many* maintenance queries cleaner, since they'd >> look like: >> select ... > oid of all system objects is less then 0x4000 That wouldn't help for excluding temp schemas, and it's not totally trustworthy for information_schema either. But I think the real problem with Ron's proposal is that it presumes there is a one-size-fits-all notion of "system schema". As a counterexample, for some maintenance activities (such as vacuuming) you might wish to process pg_catalog. What I'd suggest as an improvement that could be implemented immediately is to wrap the checks in a user-defined function like "is_system_schema(nspname name)". regards, tom lane
Re: Request for new column in pg_namespace
Hi ne 15. 12. 2024 v 17:59 odesílatel Ron Johnson napsal: > https://www.postgresql.org/docs/current/catalog-pg-namespace.html > > Currently, when I want to query all "userland" tables, I write something > like: > select ... > from pg_class cl, pg_namespace nsp > where cl.relnamespace = nsp.oid > and nsp.nspname not like 'pg_% > and nsp.nspname != 'information_schema'; > > A new boolean column named "indissystem" that's true only for system > relations would make *many* maintenance queries cleaner, since they'd > look like: > select ... > from pg_class cl, pg_namespace nsp > where cl.relnamespace = nsp.oid > and nsp.indissystem = false; > > oid of all system objects is less then 0x4000 Regards Pavel > -- > Death to , and butter sauce. > Don't boil me, I'm still alive. > lobster! >
Re: Request for new column in pg_namespace
On Sun, 15 Dec 2024 at 14:20, Tom Lane wrote: > Isaac Morland writes: > > On Sun, 15 Dec 2024 at 12:29, Tom Lane wrote: > >> What I'd suggest as an improvement that could be implemented > >> immediately is to wrap the checks in a user-defined function > >> like "is_system_schema(nspname name)". > > > Would it make sense to make the parameter be of type regnamespace? > > Meh ... you could, but what the function really needs is the name. > Getting from regnamespace (which is an OID) to the name would incur > an extra syscache lookup. Admittedly, if it removes the need for > the calling query to join to pg_namespace at all, you'd probably > come out about even --- the net effect would be about like a > hashjoin to pg_namespace, I think, since the syscache would act > like the inner hashtable of a hashjoin. Thanks for the critique. It occurs to me that this function is perhaps just as much about “is this name a system-reserved name?” as “is this schema a system schema?”. So putting in a name that doesn’t actually exist in the database should be perfectly valid, which of course only works if it takes a string. Generally speaking I am a big fan of the reg* data types but in this specific case I think it’s not a clear win. I might still suggest providing both versions using function overloading.
