Re: pg_replication_origin_drop API potential race condition

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: pg_replication_origin_drop API potential race condition
Дата
Msg-id CAA4eK1Jr=S-1zENHQmMGYOKCsHPdKrfyu2KNPbHdJkjJQXK-VA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_replication_origin_drop API potential race condition  (Peter Smith <smithpb2250@gmail.com>)
Ответы Re: pg_replication_origin_drop API potential race condition  (Peter Smith <smithpb2250@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Ibrar Ahmed
Дата:
Сообщение: Re: Next Commitfest Manager.
Следующее
От: Etsuro Fujita
Дата:
Сообщение: Re: Asynchronous Append on postgres_fdw nodes.