Re: pgsql: ltree: Zero padding bytes when allocating memory for externally - Mailing list pgsql-committers

From Tom Lane
Subject Re: pgsql: ltree: Zero padding bytes when allocating memory for externally
Date
Msg-id 15774.1457631765@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgsql: ltree: Zero padding bytes when allocating memory for externally  (Andres Freund <andres@anarazel.de>)
List pgsql-committers
Andres Freund <andres@anarazel.de> writes:
> On 2016-03-10 10:57:59 -0500, Tom Lane wrote:
>>  sysname  |      snapshot       | count
>> ----------+---------------------+-------
>> okapi     | 2012-05-10 06:15:02 |   138
>> okapi     | 2012-05-20 00:15:02 |   174
>> dromedary | 2014-03-28 00:13:52 |     4
>> dromedary | 2014-05-07 06:23:09 |     2
>> dromedary | 2016-03-08 23:27:02 |     2
>>
>> So yeah, we've seen it before, but it sure looks like a system-specific
>> glitch.  dromedary is a pretty old machine (2006 Mac mini), so I would not
>> be surprised if it dropped a bit now and then.

> dromedary's indeed look rare enough. But okapi had a lot of those.

But note those were a lot of the same failures in a single buildfarm run.

BTW, this search would have found both the client-side report in
regression.diffs and the postmaster-log report of the same error, so
all of the counts above should be divided by two to identify how many
glitches actually occurred in a given run.

okapi clearly saw some time-extended condition that caused the failure to
occur for most regression-test sessions within a run.  But it hasn't
reappeared since 2012, so my money is on some short-lived kernel bug.
(okapi is running gentoo ... nuf said.)

I don't know what's happening on dromedary, but it's clearly pretty
darn rare.  Given the lack of comparable failures on other Mac buildfarm
members, I'm willing to write it off as a flaky memory bit or some such.

            regards, tom lane


pgsql-committers by date:

Previous
From: Andres Freund
Date:
Subject: Re: pgsql: ltree: Zero padding bytes when allocating memory for externally
Next
From: Robert Haas
Date:
Subject: pgsql: Provide much better wait information in pg_stat_activity.