Re: Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby
От | Robert Haas |
---|---|
Тема | Re: Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby |
Дата | |
Msg-id | CA+TgmoZm1ecn8Qv1Hv0wTmJJJE0QobrWVE4bpBdpca_BJkW4Ww@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby (Jeff Janes <jeff.janes@gmail.com>) |
Ответы |
Re: Re: BUG #13685: Archiving while idle every
archive_timeout with wal_level hot_standby
|
Список | pgsql-hackers |
On Mon, Nov 2, 2015 at 12:58 AM, Jeff Janes <jeff.janes@gmail.com> wrote: > If a transaction holding locks aborts on an otherwise idle server, perhaps it will take a very long time for a log-shippingstandby to realize this. But I have hard time believing that anyone who cares about that would be using log-shipping(rather than streaming) anyway. I'm sure other people here understand this better than me, but I wonder if it wouldn't make more sense to somehow log this data only if something material has changed in the data being logged. This seems to be trying to log something only if something else has been written to WAL, which I'm not sure is the right test. Also, this check here: + if (last_snapshot_lsn != insert_lsn && + checkpoint_lsn != insert_lsn && + checkpoint_lsn != previous_lsn) ...seems like it will fire if there have been 0 or 1 WAL records since the last checkpoint, regardless of what they are. I'm not sure that's the right test, and it'll break again the minute we have a third thing we want to log only if the system is non-idle. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: