Thread: pgsql: ltree: Zero padding bytes when allocating memory for externally
ltree: Zero padding bytes when allocating memory for externally visible data. ltree/ltree_gist/ltxtquery's headers stores data at MAXALIGN alignment, requiring some padding bytes. So far we left these uninitialized. Zero those by using palloc0. Author: Andres Freund Reported-By: Andres Freund / valgrind / buildarm animal skink Backpatch: 9.1- Branch ------ REL9_1_STABLE Details ------- http://git.postgresql.org/pg/commitdiff/814570418d5e6bccb766efbe86d27aef206e5511 Modified Files -------------- contrib/ltree/_ltree_gist.c | 14 +++++++------- contrib/ltree/_ltree_op.c | 8 ++++---- contrib/ltree/ltree_gist.c | 10 +++++----- contrib/ltree/ltree_op.c | 6 +++--- contrib/ltree/ltxtquery_io.c | 2 +- 5 files changed, 20 insertions(+), 20 deletions(-)
On 2016-03-08 23:13:51 +0000, Andres Freund wrote: > ltree: Zero padding bytes when allocating memory for externally visible data. This is marked as the originating commit for a failure on dromedary: http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=dromedary&dt=2016-03-08%2023%3A27%3A02 the origin of the failure is: FATAL: no PostgreSQL user name specified in startup packet while in the 'comments' tests, which looks fairly independent of this commit. Tom, did you happen to change config on that machine or anything? Andres
Andres Freund <andres@anarazel.de> writes: > On 2016-03-08 23:13:51 +0000, Andres Freund wrote: >> ltree: Zero padding bytes when allocating memory for externally visible data. > This is marked as the originating commit for a failure on dromedary: > http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=dromedary&dt=2016-03-08%2023%3A27%3A02 > the origin of the failure is: > FATAL: no PostgreSQL user name specified in startup packet > while in the 'comments' tests, which looks fairly independent of this commit. > Tom, did you happen to change config on that machine or anything? No, haven't touched it in awhile. Looks like just a glitch maybe? regards, tom lane
I wrote: > Andres Freund <andres@anarazel.de> writes: >> This is marked as the originating commit for a failure on dromedary: >> http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=dromedary&dt=2016-03-08%2023%3A27%3A02 >> the origin of the failure is: >> FATAL: no PostgreSQL user name specified in startup packet >> while in the 'comments' tests, which looks fairly independent of this commit. >> Tom, did you happen to change config on that machine or anything? > No, haven't touched it in awhile. Looks like just a glitch maybe? I had a vague feeling that this looked familiar, and it occurred to me to scan the buildfarm database for occurrences of that error message. Quite a few hours later, I have these results: 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. regards, tom lane
On 2016-03-10 10:57:59 -0500, Tom Lane wrote: > I wrote: > > Andres Freund <andres@anarazel.de> writes: > >> This is marked as the originating commit for a failure on dromedary: > >> http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=dromedary&dt=2016-03-08%2023%3A27%3A02 > >> the origin of the failure is: > >> FATAL: no PostgreSQL user name specified in startup packet > >> while in the 'comments' tests, which looks fairly independent of this commit. > > >> Tom, did you happen to change config on that machine or anything? > > > No, haven't touched it in awhile. Looks like just a glitch maybe? > > I had a vague feeling that this looked familiar, and it occurred to me > to scan the buildfarm database for occurrences of that error message. > Quite a few hours later, I have these results: Heh, I tried the same, but limited my search too much timewise; to limit the cost of the query... > 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 I'm also not going to care about failures from 2012... Thanks for checking! Andres
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