Re: BUG #15888: Bogus "idle in transaction" state for logicaldecoding client after creating a slot

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: BUG #15888: Bogus "idle in transaction" state for logicaldecoding client after creating a slot
Дата
Msg-id 20190704043512.GK3084@paquier.xyz
обсуждение исходный текст
Ответ на BUG #15888: Bogus "idle in transaction" state for logical decoding client after creating a slot  (PG Bug reporting form <noreply@postgresql.org>)
Ответы Re: BUG #15888: Bogus "idle in transaction" state for logicaldecoding client after creating a slot  (Andres Freund <andres@anarazel.de>)
Список pgsql-bugs
On Wed, Jul 03, 2019 at 08:03:24AM +0000, PG Bug reporting form wrote:
> Run:
>
>   pg_recvlogical -S foo -f /dev/null -d dbname --create-slot --start
>
> and pg_stat_activity will show something like this until that session
> disconnects:
>
> which is quite obviously bogus.

I think that's the transaction which is started when exporting the
snapshot at logical slot creation.  Or in short:
#2  0x000055b5f8e5720f in StartTransactionCommand () at xact.c:2699
#3  0x000055b5f90fab4e in SnapBuildExportSnapshot
(builder=0x55b5fa3427b0) at snapbuild.c:575
#4  0x000055b5f90fe5df in CreateReplicationSlot (cmd=0x55b5fa2914e8)
at walsender.c:843

SnapBuildExportSnapshot() needs to keep a transaction context opened
to keep the wanted xmin around.  In PG >= 10, this problem gets
"solved" by using NOEXPORT_SNAPSHOT in the CREATE_REPLICATION_SLOT
command.  One idea would be to enforce a commit in this case from
CreateReplicationSlot/streamutil.c?  We know that pg_recvlogical is
not going to use this snapshot anyway...
--
Michael

Вложения

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Manuel Rigger
Дата:
Сообщение: Re: GROUP BY and inheritance issue
Следующее
От: PG Bug reporting form
Дата:
Сообщение: BUG #15893: pg_dump is not working like as postgres version 10