Re: [HACKERS] Autovacuum breakage from a734fd5d1

2016-11-28 Thread Robert Haas
On Mon, Nov 28, 2016 at 12:18 PM, Tom Lane wrote: > Robert Haas writes: >> I don't believe we should be so scared of the possibility of a serious >> bug that can't be found through any of the ways we normally test that >> we aren't willing to fix

Re: [HACKERS] Autovacuum breakage from a734fd5d1

2016-11-28 Thread Tom Lane
Robert Haas writes: > I don't believe we should be so scared of the possibility of a serious > bug that can't be found through any of the ways we normally test that > we aren't willing to fix problems we can readily foresee. I grant > that there are some situations where

Re: [HACKERS] Autovacuum breakage from a734fd5d1

2016-11-27 Thread Robert Haas
On Sun, Nov 27, 2016 at 10:30 PM, Tom Lane wrote: > Robert Haas writes: >> I think you made this considerably more fragile with those changes. > > This code will only ever run at all in corner cases --- cases that > almost by definition will go untested

Re: [HACKERS] Autovacuum breakage from a734fd5d1

2016-11-27 Thread Tom Lane
Robert Haas writes: > I think you made this considerably more fragile with those changes. This code will only ever run at all in corner cases --- cases that almost by definition will go untested in the standard regression tests. The problems you suggest it has are

Re: [HACKERS] Autovacuum breakage from a734fd5d1

2016-11-27 Thread Michael Paquier
On Mon, Nov 28, 2016 at 12:14 PM, Robert Haas wrote: > I think you made this considerably more fragile with those changes. > Now, if we fail to drop a temporary table, we won't do any actual > vacuuming, either. I'd be willing to bet someone will get hosed > because of

Re: [HACKERS] Autovacuum breakage from a734fd5d1

2016-11-27 Thread Robert Haas
On Sun, Nov 27, 2016 at 9:33 PM, Tom Lane wrote: > I pushed a patch to deal with this. I ended up simplifying the previous > commit considerably by getting rid of the commit-multiple-deletions-per- > transaction business. I do not think that this code will get exercised >

Re: [HACKERS] Autovacuum breakage from a734fd5d1

2016-11-27 Thread Michael Paquier
On Mon, Nov 28, 2016 at 11:46 AM, Tom Lane wrote: > Michael Paquier writes: >> In order to reproduce the failure I have just inserted a manual >> pg_usleep before looping through the list of orphan_oids, and after >> dropping manually from another

Re: [HACKERS] Autovacuum breakage from a734fd5d1

2016-11-27 Thread Tom Lane
Michael Paquier writes: > In order to reproduce the failure I have just inserted a manual > pg_usleep before looping through the list of orphan_oids, and after > dropping manually from another session a couple of orphaned temporary > tables I was able to see the

Re: [HACKERS] Autovacuum breakage from a734fd5d1

2016-11-27 Thread Michael Paquier
On Mon, Nov 28, 2016 at 11:33 AM, Tom Lane wrote: > I pushed a patch to deal with this. I ended up simplifying the previous > commit considerably by getting rid of the commit-multiple-deletions-per- > transaction business. I do not think that this code will get exercised >

Re: [HACKERS] Autovacuum breakage from a734fd5d1

2016-11-27 Thread Michael Paquier
On Mon, Nov 28, 2016 at 10:02 AM, Robert Haas wrote: > On Sun, Nov 27, 2016 at 5:45 PM, Tom Lane wrote: >> So the problem seems to be confirmed to exist, but be of low probability >> and low consequences, in back branches. I think we only need to fix

Re: [HACKERS] Autovacuum breakage from a734fd5d1

2016-11-27 Thread Tom Lane
Robert Haas writes: > Thanks for digging into this. I failed to notice while reviewing that > the way we were printing the message had changed a bit in the new > code, and I just totally overlooked the existing locking hazards. > Oops. I pushed a patch to deal with this.

Re: [HACKERS] Autovacuum breakage from a734fd5d1

2016-11-27 Thread Robert Haas
On Sun, Nov 27, 2016 at 5:45 PM, Tom Lane wrote: > So the problem seems to be confirmed to exist, but be of low probability > and low consequences, in back branches. I think we only need to fix it in > HEAD. The lock acquisition and status recheck that I proposed before >

Re: [HACKERS] Autovacuum breakage from a734fd5d1

2016-11-27 Thread Tom Lane
I wrote: > Buildfarm member skink failed a couple days ago: > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink=2016-11-25%2017%3A50%3A01 Ah ... I can reproduce this with moderate reliability (one failure every 10 or so iterations of the regression tests) by inserting a delay just

[HACKERS] Autovacuum breakage from a734fd5d1

2016-11-27 Thread Tom Lane
Buildfarm member skink failed a couple days ago: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink=2016-11-25%2017%3A50%3A01 I believe the interesting parts of the log are 2016-11-25 18:29:03.285 UTC [583882e7.2a45:1] LOG: autovacuum: dropping orphan temp table "(null)"."(null)" in