On Fri, Aug 17, 2018 at 8:38 PM Tom Lane <t...@sss.pgh.pa.us> wrote:
> Alexander Korotkov <a.korot...@postgrespro.ru> writes:
> > On Fri, Aug 17, 2018 at 6:41 PM Andres Freund <and...@anarazel.de> wrote:
> >> There's another patch, which I thought Alexander was referring to, that
> >> does something a bit smarger. On a super short skim it seems to
> >> introduce a separate type of AEL lock that's not replicated, by my
> >> reading?
>
> > 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. So, on standby heap truncation record would be
replayed only after heap tuples deletion records are replayed.
Therefore, if query on standby should see some of those tuples, WAL
replay stop (or query cancel) should happened before corresponding
tuples being deleted by our recovery conflict with snapshot logic.
When we're going to replay heap truncation record, no query should see
records in the tail pages.
And in md.c we already have logic to return zeroed pages, when trying
to read past relation in recovery.
/*
* Short read: we are at or past EOF, or we read a partial block at
* EOF. Normally this is an error; upper levels should never try to
* read a nonexistent block. However, if zero_damaged_pages is ON or
* we are InRecovery, we should instead return zeroes without
* complaining. This allows, for example, the case of trying to
* update a block that was later truncated away.
*/
if (zero_damaged_pages || InRecovery)
MemSet(buffer, 0, BLCKSZ);
else
ereport(ERROR,
(errcode(ERRCODE_DATA_CORRUPTED),
errmsg("could not read block %u in file \"%s\":
read only %d of %d bytes",
blocknum, FilePathName(v->mdfd_vfd),
nbytes, BLCKSZ)));
But, I'm concerned if FileSeek() could return error. And also what
_mdfd_getseg() would do on truncated segment. It seems that in
recovery, it will automatically extend the relation. That
unacceptable for this purpose. So, sorry for bothering, this patch
definitely needs to be revised.
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
