From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Peter Smith <smithpb2250(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pg_replication_origin_drop API potential race condition |
Date: | 2021-02-04 10:19:57 |
Message-ID: | CAA4eK1Jr=S-1zENHQmMGYOKCsHPdKrfyu2KNPbHdJkjJQXK-VA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
--
With Regards,
Amit Kapila.
From | Date | Subject | |
---|---|---|---|
Next Message | Etsuro Fujita | 2021-02-04 10:21:16 | Re: Asynchronous Append on postgres_fdw nodes. |
Previous Message | Ibrar Ahmed | 2021-02-04 10:07:22 | Re: Next Commitfest Manager. |