Re: [HACKERS] WIP: long transactions on hot standby feedback replica / proof of concept

Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> writes:
> On Fri, Aug 17, 2018 at 8:38 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> writes:
>>> Yes, that's correct. On standby read-only queries can tolerate
>>> concurrent heap truncation.

>> Uh, what???

> VACUUM truncates heap relation only after deletion of all the tuples
> from tail pages.

Right; the problem I'm worried about is possible accesses to
already-removed pages by concurrent scans.

> And in md.c we already have logic to return zeroed pages, when trying
> to read past relation in recovery.

But then you are injecting bad pages into the shared buffer arena.
In any case, depending on that behavior seems like a bad idea, because
it's a pretty questionable kluge in itself.

Another point is that the truncation code attempts to remove all
to-be-truncated-away pages from the shared buffer arena, but that only
works if nobody else is loading such pages into shared buffers
concurrently. In the presence of concurrent scans, we might be left
with valid-looking buffers for pages that have been truncated away
on-disk. That could cause all sorts of fun later. Yeah, the buffers
should contain only dead tuples ... but, for example, they might not
be hinted dead. If somebody sets one of those hint bits and then
writes the buffer back out to disk, you've got real problems.

Perhaps there's some gold to be mined by treating truncation locks
differently from other AELs, but I don't think you can just ignore
them on the standby, any more than they can be ignored on the master.

regards, tom lane