Re: [COMMITTERS] pgsql: Fix connection leak in DROP SUBSCRIPTION command.
От | Michael Paquier |
---|---|
Тема | Re: [COMMITTERS] pgsql: Fix connection leak in DROP SUBSCRIPTION command. |
Дата | |
Msg-id | CAB7nPqQwbsUKMjoaePbJ79NzcXeqv7q_NAdC0jJ+QvHroxXS5g@mail.gmail.com обсуждение исходный текст |
Ответ на | 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.
|
Список | pgsql-committers |
On Wed, Feb 22, 2017 at 4:12 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Fujii Masao <fujii@postgresql.org> 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, 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. -- Michael
В списке pgsql-committers по дате отправления: