RE: [PG19] Sequence sync stops when the subscription owner can't SET ROLE to a sequence owner

From: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
To: 'Zhijie Hou' <houzhijie22(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, vignesh C <vignesh21(at)gmail(dot)com>
Subject: RE: [PG19] Sequence sync stops when the subscription owner can't SET ROLE to a sequence owner
Date: 2026-10-20 06:21:42
Message-ID: OS7PR01MB183179A17EFCC72CC02F3E2F0F5672@OS7PR01MB18317.jpnprd01.prod.outlook.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Hou,

> I agree that we cannot catch all possible errors. After thinking about this
> more, there are other errors—such as deadlock timeout or lock timeout—that
> cannot easily be pre-checked, so adding an error context looks like a good
> approach to me. Attached is a patch that adds the error context as
> suggested.

Thanks for the patch. I initially felt that setting/reseting the error context
can be in the copy_sequence(), but yours seem to slightly better.
get_and_validate_seq_info() may report another error.

One comment for the test: below lines may not be needed, because REFRESH SEQUENCES
does not require apply workers, and the launcher eventually starts workers with
the appropriate owner. Doesn't upcoming wait_for_log() enough?

```
# Wait until the apply worker has started under the new subscription owner.
$node_subscriber->poll_query_until('postgres',
"SELECT count(1) = 1 FROM pg_stat_subscription s JOIN pg_stat_activity a USING (pid) WHERE s.subname = 'regress_seq_sub' AND s.worker_type = 'apply' AND a.usename = 'regress_seq_sub_owner'"
) or die "Timed out while waiting for apply worker to start as new owner";
```

Best regards,
Hayato Kuroda
FUJITSU LIMITED

In response to

Browse pgsql-hackers by date

  From Date Subject
Previous Message John Naylor 2026-10-20 05:23:15 Re: Improving scalability of Parallel Bitmap Heap/Index Scan