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 problems we can readily foresee. I grant
>> that
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 fixing a problem might in
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 in the standard regression tests.
> The pro
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 corner-squared or corner-cubed c
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 that who would have been mu
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
> enough, either in the f
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 session a couple of orphaned temporary
>> tables
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 failure. Attached is a proposal of
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
> enough, either in the
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 it in
>> HEAD. The lock acquisition and stat
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. I ended up simplifying
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
> should be sufficient.
I wrote:
> Buildfarm member skink failed a couple days ago:
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=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
be
13 matches
Mail list logo