Re: pg_replication_origin_drop API potential race condition

On Thu, Feb 4, 2021 at 9:20 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Thu, Feb 4, 2021 at 1:31 PM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
> >
> > PSA a patch which I think implements what we are talking about.
> >
>
> This doesn't seem correct to me. Have you tested that the patch
> resolves the problem reported originally? Because the lockmode
> (RowExclusiveLock) you have used in the patch will allow multiple
> callers to acquire at the same time. The other thing I don't like
> about this is that first, it acquires lock in the function
> replorigin_drop_by_name and then again we acquire the same lock in a
> different mode in replorigin_drop.
>
> What I was imagining was to have a code same as replorigin_drop with
> the first parameter as the name instead of id and additionally, it
> will check the existence of origin by replorigin_by_name after
> acquiring the lock. So you can move all the common code from
> replorigin_drop (starting from restart till end leaving table_close)
> to a separate function say replorigin_drop_guts and then call it from
> both replorigin_drop and replorigin_drop_by_name.
>
> Now, I have also thought to directly change replorigin_drop but this
> is an exposed API so let's keep it as it is because some extensions
> might be using it. We can anyway later drop it if required.
>

PSA patch updated per above suggestions.

----
Kind Regards,
Peter Smith.
Fujitsu Australia