Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
>> Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> The critical issue is whether the tuples get frozen while
>>> they're still invisible to some transactions on the standby
>>> server. That's when you get query cancellations.
>
>> Oh, OK; I get that. That seems easy enough to at least mitigate
>> to a large degree by some threshold GUC. But of course, the
>> longer you wait to freeze so that you don't cancel queries on the
>> standby, the more you pay to recalculate visibility, so it'd be a
>> fussy thing to tune.
>
> Yeah. Also, most of the argument for early freezing hinges on the
> hope that it could happen before the tuples go to disk the first
> time, which makes the window even narrower.
Is there any merit to the idea that the hot standbys could be
enhanced (in some post-9.1 version) to stash a list of tuples to
freeze in a persistent SLRU, applying them when GLobalXmin passes
the associated xid? It seems as though this would eliminate the
need to roll back transactions based on freezing without slowing
down the master or compromising the usability of the standby
(assuming that any pending ones get applied as part of promotion,
although I suppose if that time could be non-negligible, that might
be the fatal flaw).
This is more of a brainstorming thought than a well-researched
proposal, so I won't be too surprised if there's a hole in the idea
big enough to drive a truck through....
-Kevin