On 08/11/2018 04:08 PM, Andres Freund wrote: > Hi, > > On 2018-08-11 15:40:19 +0200, Tomas Vondra wrote: >> For the record, I can actually reproduce this on 9.6 (haven't tried >> older releases, but I suspect it's there too). Instead of using the >> failing subscription, I've used another pgbench script doing this: > >> SET statement_timeout = 5; >> COPY t TO '/dev/null'; >> >> and doing something like: >> >> pgbench -n -c 20 -T 300 -f copy.sql test > > Just to confirm: That's with the vacuum full and insert running > concurrently? And then just restarting the above copy.sql (as pgbench > errors out after the timeouts) until you get the error? >
Yes, pretty much. > I'm a bit confused what the copy + timeout is doing here? It shouldn't > trigger any invalidations itself, and the backtrace appears to be from > the insert.sql you posted earlier? Unclear why a copy to /dev/null > should trigger anything like this? > My goal was to simulate the failing subscription sync, which does COPY and fails because of duplicate data. The statement_timeout seemed like a good approximation of that. It may be unnecessary, I don't know. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
