Avoid testing tuple visibility without buffer lock.
authorTom Lane
Sun, 23 Oct 2016 23:14:32 +0000 (19:14 -0400)
committerTom Lane
Sun, 23 Oct 2016 23:14:32 +0000 (19:14 -0400)
commitfdcee9f1fc12d6d2c20da8da632b2062d2ed6289
treeb04826d8944b6e967e3f472b49f069955df73f61
parentc4016fcb1fd2a20ef589a3a616b59381256a985a
Avoid testing tuple visibility without buffer lock.

INSERT ... ON CONFLICT (specifically ExecCheckHeapTupleVisible) contains
another example of this unsafe coding practice.  It is much harder to get
a failure out of it than the case fixed in commit 6292c2339, because in
most scenarios any hint bits that could be set would have already been set
earlier in the command.  However, Konstantin Knizhnik reported a failure
with a custom transaction manager, and it's clearly possible to get a
failure via a race condition in async-commit mode.

For lack of a reproducible example, no regression test case in this
commit.

I did some testing with Asserts added to tqual.c's functions, and can say
that running "make check-world" exposed these two bugs and no others.
The Asserts are messy enough that I've not added them to the code for now.

Report: <57EE93C8.8080504@postgrespro.ru>
Related-Discussion: 
src/backend/executor/nodeModifyTable.c