From: | Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, vignesh C <vignesh21(at)gmail(dot)com>, Sergey Tatarintsev <s(dot)tatarintsev(at)postgrespro(dot)ru>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Restrict publishing of partitioned table with a foreign table as partition |
Date: | 2025-05-19 16:32:41 |
Message-ID: | CANhcyEVUf5PEmahQvcc8GgCzxaAnJ8kTrir0Am_7O4SkZnpkQA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 15 May 2025 at 18:19, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Sun, May 11, 2025 at 6:53 AM Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> >
> > But the non-idiomatic locking of pg_partitioned_table appears to
> > continue to be the pain point of this patch. My impression is that
> > using a lock is the wrong approach to solve the concurrency problem.
> > Maybe we can use a ConditionVariable instead somehow. (The real trick
> > here is to figure out exactly _how_ to use the CV, I mean what exactly
> > is the condition that the CV sleeps on?)
> >
>
> Can we fix this problem by having a check at the time of
> CREATESUBSCRIPTION such that, if copy-data is true, then we ensure
> that the specified publishers don't have a foreign table? We have a
> somewhat similar check for publications in the function
> check_publications_origin(), though for a different purpose. Along
> with it, we can still have a check during foreign table
> creation/attach that it doesn't become part of some publication, as
> the patch may have it now.
>
This approach seems better to me. I have created a patch with the
above approach.
Thanks and Regards,
Shlok Kyal
Attachment | Content-Type | Size |
---|---|---|
v15-0001-Restrict-publishing-of-partitioned-table-with-fo.patch | application/octet-stream | 29.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2025-05-19 16:38:39 | Re: Remove Instruction Synchronization Barrier in spin_delay() for ARM64 architecture |
Previous Message | Tomas Vondra | 2025-05-19 16:13:02 | Re: strange perf regression with data checksums |