| From: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
|---|---|
| To: | shveta malik <shveta(dot)malik(at)gmail(dot)com> |
| Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Proposal: Conflict log history table for Logical Replication |
| Date: | 2025-11-17 06:24:11 |
| Message-ID: | CAFiTN-uWq0jrcTaOiGVN4mxJa6iFi=2P98=oYUpgh+8gS2oziw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Nov 13, 2025 at 9:17 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> On Thu, Nov 13, 2025 at 2:39 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
> >
> > > Few observations related to publication.
> > > ------------------------------
>
> Thanks Shveta, for testing and sharing your thoughts. IMHO for
> conflict log tables it should be good enough if we restrict it when
> ALL TABLE options are used, I don't think we need to put extra effort
> to completely restrict it even if users want to explicitly list it
> into the publication.
>
> > >
> > > (In the below comments, clt/CLT implies Conflict Log Table)
> > >
> > > 1)
> > > 'select pg_relation_is_publishable(clt)' returns true for conflict-log table.
After putting more thought I have changed this to return false for
clt, as this is just an exposed function not called by pgoutput layer.
> > > 2)
> > > '\d+ clt' shows all-tables publication name. I feel we should not
> > > show that for clt.
>
Fixed
>
> > > 3)
> > > I am able to create a publication for clt table, should it be allowed?
>
> I believe we should not do any specific handling to restrict this but
> I am open for the opinions.
Restricting this as well, lets see what others think.
>
> > > 5) Also, I feel we can add some documentation now to help others to
> > > understand/review the patch better without going through the long
> > > thread.
>
> Make sense, I will do that in the next version.
Done that but not compiled the docs as I don't currently have the
setup so added as WIP patch.
> > > 2)
> > > Conflicts where row on sub is missing, local_ts incorrectly inserted.
> > > It is '2000-01-01 05:30:00+05:30'. Should it be Null or something
> > > indicating that it is not applicable for this conflict-type?
> > >
> > > Example: delete_missing, update_missing
> > > pub:
> > > insert into tab1 values(10,10);
> > > insert into tab1 values(20,10);
> > > sub: delete from tab1 where i=10;
> > > pub: delete from tab1 where i=10;
>
> Sure I will test this.
I have fixed this.
--
Regards,
Dilip Kumar
Google
| Attachment | Content-Type | Size |
|---|---|---|
| v4-0002-Don-t-add-conflict-history-tables-to-publishable-.patch | application/octet-stream | 4.6 KB |
| v4-0003-WIP-conflict-log-table-docs.patch | application/octet-stream | 10.7 KB |
| v4-0001-Add-configurable-conflict-log-history-table-for.patch | application/octet-stream | 31.4 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2025-11-17 06:40:03 | Re: POC: enable logical decoding when wal_level = 'replica' without a server restart |
| Previous Message | Peter Smith | 2025-11-17 06:12:24 | Re: Skipping schema changes in publication |