Re: Bug in point releases 9.3.6 and 9.2.10? - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Bug in point releases 9.3.6 and 9.2.10?
Date
Msg-id CAM3SWZRiqvDSUzB_RLroyezYCut02hf_t-mGR8L7mhM82fByZA@mail.gmail.com
Whole thread Raw
In response to Re: Bug in point releases 9.3.6 and 9.2.10?  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On Thu, Mar 12, 2015 at 5:56 PM, Andres Freund <andres@2ndquadrant.com> wrote:
>> > Any chance that the new nodes also use a different kernel version or
>> > such?
>>
>> They may differ, but that doesn't seem likely to be relevant, at least
>> to me.
>
> There've been some issues with seek(END) sometimes returning the wrong
> length in the past. And I've seen a report that might indicate a similar
> bug has been reintroduced. That could certainly cause such anerror.

It seems that I failed to take account of the fact that these cases
all involved Ubuntu 14.04 LTS (that wasn't clear to me before, but
I've verified that that's the case now), which is a small minority of
the kernels our instances use. I've verified that the issue arises
independently of point release, including on earlier point releases
from about a year ago, so I was hasty in suggesting that there was a
regression in the latest point releases.

I'm still going to get a back trace here, because it seems reasonable
to suppose that there is a Postgres bug even still - it may be that
whatever differences are in the 14.04 kernel are enough to make a
previously latent bug trip this code up. Plenty of people are using
Ubuntu 14.04 LTS with Postgres without seeing this issue, or any other
issue, and there is no other issue with the kernel that I know of. The
issue continues to occur as new instances with this configuration are
deployed.

I should also add that my temporary remediation ("VACUUM FULL
pg_auth_members;") works consistently, as new cases start to crop up.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Rethinking the parameter access hooks for plpgsql's benefit
Next
From: Robert Haas
Date:
Subject: Re: Rethinking the parameter access hooks for plpgsql's benefit