Re: Proposal: Conflict log history table for Logical Replication
| От | Dilip Kumar |
|---|---|
| Тема | Re: Proposal: Conflict log history table for Logical Replication |
| Дата | |
| Msg-id | CAFiTN-uiWTKPQRcWBpbMk++DZvnb37EwP9Vt_BN2KdG+r_+73g@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Proposal: Conflict log history table for Logical Replication (shveta malik <shveta.malik@gmail.com>) |
| Ответы |
Re: Proposal: Conflict log history table for Logical Replication
|
| Список | pgsql-hackers |
On Wed, Jan 7, 2026 at 12:12 PM shveta malik <shveta.malik@gmail.com> wrote: > > Hi Dilip, > Please find a few comments on v19-001: > > 1) > We can replace IsConflictLogTable(relid) with > IsConflictClass(reltuple). Wherever we call IsConflictLogTable(), we > have already fetched reltuple from pg_class for that relid, we can > simply use that to see if it belongs to pg_conflict namespace. That > will avoid the need of > patch004 as well to 'Introduce a dedicated shared unique index on > pg_subscription.subconflictlogrelid'. > > 2) > + if (opts.logdest == CONFLICT_LOG_DEST_TABLE || > + opts.logdest == CONFLICT_LOG_DEST_ALL) > > We can replace with: > > IsSet(opts.logdest, CONFLICT_LOG_DEST_TABLE); > > 3) > +-- this should generate an internal table named pg_conflict_$subid$ > +CREATE SUBSCRIPTION regress_conflict_test1 CONNECTION > 'dbname=regress_doesnotexist' PUBLICATION testpub WITH (connect = > false, conflict_log_destination = 'table'); > + > > I think we shall verify 2 things here: > a) Table is created in pg_conflict namespace. > b) Table has name pg_conflict_<subid> > > 4) > We can add these 3 simple tests as well: > a) Trying to alter and truncate pg_conflict_subid table. > b) Trying to create a new table in pg_conflict namespace. > c) Moving a table into pg_conflict namespace. > > ~~ > > Overall, I’m concerned about how users will manage this table as it > grows. There is currently no way to purge old data, truncation is > disallowed, and the table must be sub-ID–tied, which also prevents > users from attaching a different table as a CLT (if needed). > Additionally, we do not offer any form of partitioning. > Do you think we should provide users with a basic purge mechanism? At > the very least, should we allow truncation so users can take a backup > and truncate a sub-ID–tied CLT to start afresh? Thoughts? Yeah that's a valid concern, there should be some way to purge data from this table, I think we can allow truncate/delete on this table, currently I haven't blocked the DML operations on that table and similarly we can allow truncate as well. -- Regards, Dilip Kumar Google
В списке pgsql-hackers по дате отправления: