On Sun, Mar 24, 2019 at 1:47 PM Tom Lane wrote:
> This flips one expected result to another order from what it was.
> (I experimented with OID-descending sort, but that flips two
> other expected results.)
I think that that's fine, provided that the order is consistent going forward.
> If no
Peter Geoghegan writes:
> On Sun, Mar 24, 2019 at 11:02 AM Tom Lane wrote:
>> I think I can probably get that done today, but if you don't want to
>> wait, feel free to put in the detail-suppression for now.
> I'll monitor the situation, and proceed with a stopgap
> detail-suppression fix this
On Sun, Mar 24, 2019 at 11:02 AM Tom Lane wrote:
> > I would like to suppress the dependency.sql stability issue right
> > away. I can also suppress the rowsecurity.out output in the same
> > commit. I want to fix the problem on the buildfarm first, unless your
> > well-principled approach won't
Peter Geoghegan writes:
> On Sun, Mar 24, 2019 at 10:33 AM Tom Lane wrote:
>> At this point I no longer have any faith in the approach of "suppress
>> DETAIL only where we've actually been burnt". I think we should
>> either go ahead and suppress DETAIL in all four places, or bite the
>> bullet
On Sun, Mar 24, 2019 at 10:33 AM Tom Lane wrote:
> > I can fix this one the same way as I fixed the first two. That will
> > mean that three out of the four tests with DROP ROLE statements whose
> > output needed to be changed as part of commit dd299df81 will have had
> > their DETAIL output
Peter Geoghegan writes:
> On Sun, Mar 24, 2019 at 8:32 AM Tom Lane wrote:
>> So here's another failure of the same ilk:
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=urocryon=2019-03-24%2006%3A12%3A35
> I can fix this one the same way as I fixed the first two. That will
> mean that
On Sun, Mar 24, 2019 at 8:32 AM Tom Lane wrote:
> So here's another failure of the same ilk:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=urocryon=2019-03-24%2006%3A12%3A35
I can fix this one the same way as I fixed the first two. That will
mean that three out of the four tests
So here's another failure of the same ilk:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=urocryon=2019-03-24%2006%3A12%3A35
How come these results seem to be less stable than they used to be?
regards, tom lane
On Fri, Mar 22, 2019 at 10:38 AM Tom Lane wrote:
> So that means that the de-revert is probably the best option for
> now. Will you do the honors?
I'll take care of that shortly.
Thanks
--
Peter Geoghegan
Peter Geoghegan writes:
> On Fri, Mar 22, 2019 at 10:13 AM Tom Lane wrote:
>> 1a seems a bit ambitious but maybe it's worth doing, considering
>> that right now there's a non-negligible chance of OOM if you
>> try to drop a role that owns a huge number of objects, or just
>> plain failure due to
On Fri, Mar 22, 2019 at 10:13 AM Tom Lane wrote:
> Options:
Obviously if we were going to de-revert 7d3bf73ac then it wouldn't
quite be a straight de-revert. There would also be a few new comments
about the issue in relevant test files.
> 1a seems a bit ambitious but maybe it's worth doing,
On Fri, Mar 22, 2019 at 9:32 AM Tom Lane wrote:
> Apparently, that case is indeed unstable, cf
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=fulmar=2019-03-22%2016%3A15%3A14
I had a feeling that that would happen.
> I'm fairly baffled as to why the output order would be unstable
>
I wrote:
> I'm fairly baffled as to why the output order would be unstable
> given the sort, and even more as to why the instability didn't
> emerge before. Any thoughts?
Well, after actually looking at the code, the answer to the first
part of that is obvious: the printed dependency list comes
Peter Geoghegan writes:
> On Wed, Mar 20, 2019 at 8:17 PM Tom Lane wrote:
>>> Actually, I'm not sure why it would be fine to revert 7d3bf73ac now.
>>> Might the problem actually be the order in which OIDs are originally
>>> assigned, or something like that?
>> No, because then things would have
On Wed, Mar 20, 2019 at 8:17 PM Tom Lane wrote:
> > Actually, I'm not sure why it would be fine to revert 7d3bf73ac now.
> > Might the problem actually be the order in which OIDs are originally
> > assigned, or something like that?
>
> No, because then things would have been unstable before, no?
Peter Geoghegan writes:
> On Wed, Mar 20, 2019 at 3:11 PM Peter Geoghegan wrote:
>> On Wed, Mar 20, 2019 at 3:08 PM Tom Lane wrote:
>>> And done. Should be possible to revert 7d3bf73ac, if you wish.
> Actually, I'm not sure why it would be fine to revert 7d3bf73ac now.
> Might the problem
On Wed, Mar 20, 2019 at 3:11 PM Peter Geoghegan wrote:
> On Wed, Mar 20, 2019 at 3:08 PM Tom Lane wrote:
> > And done. Should be possible to revert 7d3bf73ac, if you wish.
>
> Will do.
Actually, I'm not sure why it would be fine to revert 7d3bf73ac now.
Might the problem actually be the order
On Wed, Mar 20, 2019 at 3:08 PM Tom Lane wrote:
> And done. Should be possible to revert 7d3bf73ac, if you wish.
Will do.
Thanks!
--
Peter Geoghegan
I wrote:
> Will push a fix in a few minutes.
And done. Should be possible to revert 7d3bf73ac, if you wish.
regards, tom lane
Peter Geoghegan writes:
> On Wed, Mar 20, 2019 at 2:44 PM Tom Lane wrote:
>> After trying it (against yesterday's sources) on my SELinux-capable
>> machine, I see no evidence that we need any output ordering changes
>> at all if we go this route. This is probably unsurprising considering
>>
On Wed, Mar 20, 2019 at 2:44 PM Tom Lane wrote:
> After trying it (against yesterday's sources) on my SELinux-capable
> machine, I see no evidence that we need any output ordering changes
> at all if we go this route. This is probably unsurprising considering
> that the old btree code used to
I wrote:
> A preliminary check-world run finds no places where the output changes,
> but I've not tried this with SELinux yet.
After trying it (against yesterday's sources) on my SELinux-capable
machine, I see no evidence that we need any output ordering changes
at all if we go this route. This
I wrote:
> Yeah. My opinion is that we should just qsort the list of targets
> during DROP OWNED and be done with this. I'll post a patch shortly.
Here's one way we could do this: add a flag to performMultipleDeletions
to invoke the sort. A small problem with it is that if we sort the
On Wed, Mar 20, 2019 at 1:46 PM Tom Lane wrote:
> Yeah. My opinion is that we should just qsort the list of targets
> during DROP OWNED and be done with this. I'll post a patch shortly.
Sounds good.
Barring any objections, I will get the buildfarm completely green
again shortly by adjusting
On Wed, Mar 20, 2019 at 1:46 PM Tom Lane wrote:
> In the meantime, would you mind cleaning this up:
>
> nbtxlog.c: In function 'btree_xlog_split':
> nbtxlog.c:269: warning: 'newitem' may be used uninitialized in this function
> nbtxlog.c:269: note: 'newitem' was declared here
> nbtxlog.c:271:
Peter Geoghegan writes:
> On Wed, Mar 20, 2019 at 11:30 AM Peter Geoghegan wrote:
>> Your work on test stability probably eliminated 98% of the problems.
>> It's still early, but the buildfarm is mostly fine.
> batfish just had a similar failure, this time in foreign_data -- two
> lines of
On Wed, Mar 20, 2019 at 11:30 AM Peter Geoghegan wrote:
> Your work on test stability probably eliminated 98% of the problems.
> It's still early, but the buildfarm is mostly fine.
batfish just had a similar failure, this time in foreign_data -- two
lines of "DETAIL" output appear in
On Wed, Mar 20, 2019 at 11:09 AM Andres Freund wrote:
> FWIW, I just fix up the tests using the regression output from
> rhinoceros when that happens. Sometimes takes more than a single round,
> but it builds frequently enough...
I'll give that a go, provided Tom is okay with it.
--
Peter
On Wed, Mar 20, 2019 at 11:08 AM Tom Lane wrote:
> The diffs all are related to the order of operations in a DROP OWNED BY
> command, so I think blaming SELinux is just blaming the messenger.
> This comes down to the point that we didn't do anything to ensure
> drop order stability in
Hi,
On 2019-03-20 11:00:06 -0700, Peter Geoghegan wrote:
> On Wed, Mar 20, 2019 at 10:05 AM Peter Geoghegan wrote:
> > Make heap TID a tiebreaker nbtree index column.
>
> I see that this has caused SELinux test failures on rhinoceros (the
> ddl test fails). It looks like the output order is
On Wed, Mar 20, 2019 at 10:05 AM Peter Geoghegan wrote:
> Make heap TID a tiebreaker nbtree index column.
I see that this has caused SELinux test failures on rhinoceros (the
ddl test fails). It looks like the output order is affected by the
implementation details of nbtree, likely for some
31 matches
Mail list logo
