| From: | vignesh C <vignesh21(at)gmail(dot)com> |
|---|---|
| To: | Zhijie Hou <houzhijie22(at)gmail(dot)com> |
| Cc: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Test publication.sql racing with subscription.sql might fail due to cache lookup error |
| Date: | 2026-10-14 06:41:37 |
| Message-ID: | CALDaNm0upoZJsc_JCFx9K0oU7TGu3bZ6tGp7jjYC0hpU5B1X+A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, 13 Oct 2026 at 13:11, vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> I think the same issue can occur in other callers of
> InvalidatePublicationRels() apart from the reported adding tables in a
> schema, such as altering publication options, dropping a table from a
> publication, and dropping a schema from a publication. We can safely
> ignore relations that have been dropped concurrently in these cases.
> The other caller, which adds a table directly to a publication, is not
> affected because it locks the table and prevents it from being dropped
> concurrently. So, we can continue to throw an error if the table no
> longer exists in that case.
The attached v2 version patch has the changes for the same. This also
addresses hou-san comment of not requiring a new function from [1].
Regards,
Vignesh
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-Avoid-cache-lookup-failure-for-concurrently-dropp.patch | application/octet-stream | 5.4 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2026-10-14 07:02:42 | Re: Parallel autovacuum: DROP DATABASE WITH (FORCE) fails on the parallel workers |
| Previous Message | Antonin Houska | 2026-10-14 06:31:22 | Incorrect argument passed to buffer_readv_encode_error() |