On Fri, Aug 17, 2018 at 9:55 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Alexander Korotkov <a.korot...@postgrespro.ru> writes: > > On Fri, Aug 17, 2018 at 8:38 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > >> Alexander Korotkov <a.korot...@postgrespro.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.
Thank you for the explanation. I see that injecting past OEF pages into shared buffers doesn't look good. I start thinking about letting caller of ReadBuffer() (or its variation) handle past OEF situation. ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company