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 <br...@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 + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
