Re: [COMMITTERS] pgsql: Fix connection leak in DROP SUBSCRIPTION command.
От
Fujii Masao
Тема
Re: [COMMITTERS] pgsql: Fix connection leak in DROP SUBSCRIPTION command.
Дата
Msg-id
CAHGQGwGcq1B1NaTTGAT8=TJkjvnOmhR6JjScVVr-7y8K6R8ypw@mail.gmail.com
Ответ на
Список
Дерево обсуждения
[COMMITTERS] pgsql: Fix connection leak in DROP SUBSCRIPTION command. Fujii Masao <fujii@postgresql.org>
Re: [COMMITTERS] pgsql: Fix connection leak in DROP SUBSCRIPTION command. Tom Lane <tgl@sss.pgh.pa.us>
Re: [COMMITTERS] pgsql: Fix connection leak in DROP SUBSCRIPTION command. Michael Paquier <michael.paquier@gmail.com>
Re: [COMMITTERS] pgsql: Fix connection leak in DROP SUBSCRIPTION command. Fujii Masao <masao.fujii@gmail.com>
Re: [COMMITTERS] pgsql: Fix connection leak in DROP SUBSCRIPTIONcommand. Petr Jelinek <petr.jelinek@2ndquadrant.com>
Re: [COMMITTERS] pgsql: Fix connection leak in DROP SUBSCRIPTION command. Michael Paquier <michael.paquier@gmail.com>
Re: [COMMITTERS] pgsql: Fix connection leak in DROP SUBSCRIPTION command. Fujii Masao <masao.fujii@gmail.com>
On Wed, Feb 22, 2017 at 6:57 AM, Michael Paquier wrote: > On Wed, Feb 22, 2017 at 4:12 AM, Tom Lane wrote: >> Fujii Masao writes: >>> Fix connection leak in DROP SUBSCRIPTION command. >>> Previously the command forgot to close the connection to the publisher >>> when it failed to drop the replication slot. >> >> If there's a bug here, this seems like an extremely unreliable way of >> fixing it. What if an error gets thrown before you reach that ereport? >> >> In other words, this coding is assuming that the walrcv_command() >> subroutine cannot throw an error, Yes, but I agree that walrcv_command() may be changed in the future so that an error is thrown and current coding is not reliable in that case. >> which I would consider dangerous >> even if it were a fixed subroutine. If it's a hook that's doing >> unknown stuff, that seems a completely untenable assumption. You >> really need either to hook the cleanup action into normal error >> recovery, or to use a PG_TRY block. > > To be honest, I have thought about using PG_ENSURE_ERROR_CLEANUP() > when seeing the thread. If other ERROR messages are generated in the > future that the current fix would be unreliable. What about the attached patch? Regards, -- Fujii Masao
В списке pgsql-committers по дате отправления
От: Fujii Masao
Дата:
От: Petr Jelinek
Дата: