| From: | "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com> |
|---|---|
| To: | vignesh C <vignesh21(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, shveta malik <shveta(dot)malik(at)gmail(dot)com>, Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Euler Taveira <euler(at)eulerto(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org> |
| Subject: | RE: Logical Replication of sequences |
| Date: | 2025-10-27 02:53:09 |
| Message-ID: | TY4PR01MB169078D0BB792F1EE438A2EE294FCA@TY4PR01MB16907.jpnprd01.prod.outlook.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Friday, October 24, 2025 11:22 PM vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> On Thu, 23 Oct 2025 at 16:47, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > On Thu, Oct 23, 2025 at 11:45 AM vignesh C <vignesh21(at)gmail(dot)com> wrote:
> > >
> > > The attached patch has the changes for the same.
> > >
> >
> > I have pushed 0001 and the following are comments on 0002.
>
> The attached v20251024 version patch has the changes for the same.
> The comments from [1] have also been addressed in this version.
Thanks for updating the patch.
I was reviewing 0003 and have some thoughts for simplifying the codes related to
sequence state invalidations and hash tables:
1. I'm considering whether we could lock sequences at the start and maintain
these locks until the copy process finishes, allowing us to remove
invalidation codes.
I understand that the current process is:
1. start a transaction to fetch namespace/seqname for all the sequences in
the pg_subscription_rel
2. start multiple transation and handle a batch of in each transaction
So if there are sequence is altered between step 1 and 2, then we need to
skip the renamed or dropped sequences in step 2 and invalidates the hash
entry which looks inelegant.
To improve this, my proposal is to postpone the namespace/seqname fetch logic
until the second step. Initially, we would fetch just the sequence OIDs.
Then, in step 2, we would fetch the namespace/seqname after locking the
sequence. This approach ensures that any concurrent RENAME operations between
steps are irrelevant, as we will use the latest sequence names to query the
publisher, preventing any RENAME during step 2. This logic is also consistent
with tablesync process where we lock the table first and get nspname/relname
after that.
2. We currently use a hash table to map remote sequence information to local
sequence data. I'm exploring the possibility of using a List instead. By
passing the sequence's index in the List to the query:
The idea is to pass the index of the sequence in the List to the query like:
"FROM ( VALUES %s ) AS s (schname, seqname, seqidx)"
Upon receiving the results, we can directly map remote sequences to local
ones using:: "list_nth(seqinfos, seqidx);"
Here is a patch atop of 0003 that implements above ideas. Please take a
look at this and see if it makes the code look better.
Best Regards,
Hou zj
| Attachment | Content-Type | Size |
|---|---|---|
| vRefactoring-0001-Replace-Hash-table-with-a-List-and-elim.patch | application/octet-stream | 19.3 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2025-10-27 02:56:35 | Re: Use BumpContext contexts for TupleHashTables' tablecxt |
| Previous Message | Steven Niu | 2025-10-27 02:43:51 | remove obsolete comment in AtEOXact_Inval |