Re: snapshot too old, configured by time
От | Bruce Momjian |
---|---|
Тема | Re: snapshot too old, configured by time |
Дата | |
Msg-id | 20160503052838.GB27541@momjian.us обсуждение исходный текст |
Ответ на | Re: snapshot too old, configured by time (Kevin Grittner <kgrittn@gmail.com>) |
Список | pgsql-hackers |
On Mon, May 2, 2016 at 03:50:36PM -0500, Kevin Grittner wrote: > >> Also, it seems we have similar behavior already in applying WAL on the > >> standby --- we delay WAL replay when there is a long-running > >> transaction. Once the time expires, we apply the WAL. Do we cancel the > >> long-running transaction at that time, or wait for the long-running > >> transaction to touch some WAL we just applied? If the former, does > >> Kevin's new code allow us to do the later? > > > > Is this a TODO item? > > I'm not aware of any TODO items existing or needed here. The > feature operates by adjusting the xmin used by vacuum and pruning, > and leaving all the other mechanisms functioning as they were. > That looked to me like it should interact with replication streams > correctly. If someone sees something that needs adjustment please > speak up Real Soon Now. My question is whether this method could also be used to avoid read-only query cancel when we force replay of a conflicting wal record. Could we wait for the read-only query to try to _access_ some old data before cancelling it? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
В списке pgsql-hackers по дате отправления: