Re: Minimal logical decoding on standbys
От | Alvaro Herrera |
---|---|
Тема | Re: Minimal logical decoding on standbys |
Дата | |
Msg-id | 20230330095449.47yz2q4mn27t6xgl@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: Minimal logical decoding on standbys ("Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com>) |
Ответы |
Re: Minimal logical decoding on standbys
|
Список | pgsql-hackers |
> From 56a9559555918a99c202a0924f7b2ede9de4e75d Mon Sep 17 00:00:00 2001 > From: bdrouvotAWS <bdrouvot@amazon.com> > Date: Tue, 7 Feb 2023 08:59:47 +0000 > Subject: [PATCH v52 3/6] Allow logical decoding on standby. > > Allow a logical slot to be created on standby. Restrict its usage > or its creation if wal_level on primary is less than logical. > During slot creation, it's restart_lsn is set to the last replayed > LSN. Effectively, a logical slot creation on standby waits for an > xl_running_xact record to arrive from primary. Hmm, not sure if it really applies here, but this sounds similar to issues with track_commit_timestamps: namely, if the primary has it enabled and you start a standby with it enabled, that's fine; but if the primary is later shut down (but the standby isn't) and then the primary restarted with a lesser value, then the standby would misbehave without any obvious errors. If that is a real problem, then perhaps you can solve it by copying some of the logic from track_commit_timestamps, which took a large number of iterations to get right. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "No hay ausente sin culpa ni presente sin disculpa" (Prov. francés)
В списке pgsql-hackers по дате отправления: