Re: Race conditions in 019_replslot_limit.pl
От | Tom Lane |
---|---|
Тема | Re: Race conditions in 019_replslot_limit.pl |
Дата | |
Msg-id | 1986228.1645819621@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Race conditions in 019_replslot_limit.pl (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Race conditions in 019_replslot_limit.pl
|
Список | pgsql-hackers |
Andres Freund <andres@anarazel.de> writes: > Seems to suggest something is holding a problematic lock in a way that I do not understand yet: > https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=crake&dt=2022-02-23%2013%3A47%3A20&stg=recovery-check > 2022-02-23 09:09:52.299 EST [2022-02-23 09:09:52 EST 1997084:6] 019_replslot_limit.pl LOG: received replication command:CREATE_REPLICATION_SLOT "pg_basebackup_1997084" TEMPORARY PHYSICAL ( RESERVE_WAL) > ... > 2022-02-23 09:09:52.518 EST [2022-02-23 09:09:52 EST 1997084:14] 019_replslot_limit.pl DEBUG: shmem_exit(0): 4 before_shmem_exitcallbacks to make > 2022-02-23 09:09:52.518 EST [2022-02-23 09:09:52 EST 1997084:15] 019_replslot_limit.pl DEBUG: replication slot exit hook,without active slot > 2022-02-23 09:09:52.518 EST [2022-02-23 09:09:52 EST 1997084:16] 019_replslot_limit.pl DEBUG: temporary replication slotcleanup: begin > last message from 1997084 until the immediate shutdown. Hmm. Maybe put a couple more debug messages into ReplicationSlotCleanup and/or ReplicationSlotDropPtr? It doesn't seem very clear where in that sequence it's hanging up. > We could be more certain if we shut down the cluster in fast rather than > immediate mode. So I'm thinking of doing something like Does that risk an indefinite hangup of the buildfarm run? regards, tom lane
В списке pgsql-hackers по дате отправления: