Re: Transaction Snapshots and Hot Standby - Mailing list pgsql-hackers

From Zeugswetter Andreas OSB sIT
Subject Re: Transaction Snapshots and Hot Standby
Date
Msg-id 6DAFE8F5425AB84DB3FCA4537D829A561CE05C720C@M0164.s-mxs.net
Whole thread Raw
In response to Re: Transaction Snapshots and Hot Standby  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Transaction Snapshots and Hot Standby  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
> Simon Riggs wrote:
> > 2. Master ignores Standby's OldestXmin
> > Effects:
> > * Long running queries on standby...
> >    Have no effect on primary
> >    Can delay apply of WAL records on standby
> > * Queries on standby give consistent answers in all cases.
>
> Just for clarification, if you set a max_slave_delay it means it is the
> maximum amount of time WAL replay can be delayed on the slave, _and_ it
> is the maximum amount of time a query/snapshot can be guaranteed to run
> without the possibility of being canceled.  My point is that these two
> concepts are linked to the same setting.

I wonder whether the cancel can be delayed until a tuple/page is actually accessed
that shows a too new xid.

The procedure would be like this:
Instead of cancel, the backend gets a message with a lsn_horizon.
From there on, whenever the backend reads a page/tuple with a LSN > lsn_horizon it cancels.
I think that should allow some more queries to complete.
Especially such that target static tables, or static parts of large tables
using appropriate index btree ranges that are also static.

Andreas


pgsql-hackers by date:

Previous
From: Zdenek Kotala
Date:
Subject: Re: PostgreSQL future ideas
Next
From: "Gevik Babakhani"
Date:
Subject: Re: PostgreSQL future ideas