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 +