Re: pg_replication_origin_drop API potential race condition - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: pg_replication_origin_drop API potential race condition
Date
Msg-id CAA4eK1Jr=S-1zENHQmMGYOKCsHPdKrfyu2KNPbHdJkjJQXK-VA@mail.gmail.com
Whole thread Raw
In response to Re: pg_replication_origin_drop API potential race condition  (Peter Smith <smithpb2250@gmail.com>)
Responses Re: pg_replication_origin_drop API potential race condition
List pgsql-hackers
On Thu, Feb 4, 2021 at 1:31 PM Peter Smith <smithpb2250@gmail.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.

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Ibrar Ahmed
Date:
Subject: Re: Next Commitfest Manager.
Next
From: Etsuro Fujita
Date:
Subject: Re: Asynchronous Append on postgres_fdw nodes.