| From: | shveta malik <shveta(dot)malik(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Dilip Kumar <dilipbalaut(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, shveta malik <shveta(dot)malik(at)gmail(dot)com> |
| Subject: | Re: Replace is_publishable_class() with relispublishable column in pg_class |
| Date: | 2025-12-17 03:44:11 |
| Message-ID: | CAJpy0uAXHv-YQNSqWRuzWsTa===QCUQUnQawFWUeUAP4vkY=yA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Dec 16, 2025 at 9:58 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> Hi,
>
> On 2025-12-16 21:19:21 +0530, Dilip Kumar wrote:
> > Motivation
> > ========
> > 1) The check is performed frequently in the logical decoding path
> > (e.g., in pgoutput_change and pgoutput_truncate). Moving this to a
> > cached catalog attribute in pg_class allows for a simple check.
>
> You could solve this more resource-efficiently by putting the information in
> the relcache entry.
>
I feel the proposed solution (marking in pg_class) is required not
only to improve performance by avoiding OID checks in frequently
executed paths, but also to ensure consistent behavior when publishing
tables.
The existing approach does not provide a foolproof solution. As an
example, tables in information_schema are currently not eligible for
publication; but if information_schema is dropped and recreated, those
tables become eligible because their relid no longer falls under
FirstNormalObjectId (see steps in [1]). There may be other
existing/future scenarios with similar behavior. In my opinion, the
proposed solution is a good approach to ensure consistency in such
cases.
[1]:
****Pub****:
create publication pub1;
ALTER PUBLICATION pub1 ADD TABLE information_schema.sql_sizing;
select * from information_schema.sql_sizing where sizing_id=97;
****Sub****:
create subscription sub1 connection '...' publication pub1 with
(copy_data=false);
select * from information_schema.sql_sizing where sizing_id=97;
****Pub****:
alter table information_schema.sql_sizing replica identity full;
--this is not replicated.
UPDATE information_schema.sql_sizing set supported_value=12 where sizing_id=97;
****Sub****:
postgres=# select supported_value from information_schema.sql_sizing
where sizing_id=97;
supported_value
-----------------
0
~~
Then drop and recreate and try to perform the above update again, it
gets replicated:
drop schema information_schema cascade;
./psql -d postgres -f ./../../src/backend/catalog/information_schema.sql -p 5433
****Pub****:
ALTER PUBLICATION pub1 ADD TABLE information_schema.sql_sizing;
select * from information_schema.sql_sizing where sizing_id=97;
alter table information_schema.sql_sizing replica identity full;
--This is replicated
UPDATE information_schema.sql_sizing set supported_value=14 where sizing_id=97;
****Sub****:
--This shows supported_value as 14
postgres=# select supported_value from information_schema.sql_sizing
where sizing_id=97;
supported_value
-----------------
14
thanks
Shveta
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2025-12-17 03:49:32 | Re: Change checkpoint‑record‑missing PANIC to FATAL |
| Previous Message | Michael Paquier | 2025-12-17 03:35:21 | Re: A small problem when rehashing catalog cache |