Peter Geoghegan wrote: > On Sat, Oct 7, 2017 at 1:31 AM, Alvaro Herrera <alvhe...@alvh.no-ip.org> > wrote: > >> As you must have seen, Alvaro said he has a variant of Dan's original > >> script that demonstrates that a problem remains, at least on 9.6+, > >> even with today's fix. I think it's the stress-test that plays with > >> fillfactor, many clients, etc [1]. > > > > I just execute setup.sql once and then run this shell command, > > > > while :; do > > psql -e -P pager=off -f ./repro.sql > > for i in `seq 1 5`; do > > psql -P pager=off -e --no-psqlrc -f ./lock.sql & > > done > > wait && psql -P pager=off -e --no-psqlrc -f ./reindex.sql > > psql -P pager=off -e --no-psqlrc -f ./report.sql > > echo "done" > > done > > I cannot reproduce the problem on my personal machine using this > script/stress-test. I tried to do so on the master branch git tip. > This reinforces the theory that there is some timing sensitivity, > because the remaining race condition is very narrow.
Hmm, I think I added a random sleep (max. 100ms) right after the HeapTupleSatisfiesVacuum call in vacuumlazy.c (lazy_scan_heap), and that makes the race easier to hit. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers