On 2015-03-12 17:42:33 -0700, Peter Geoghegan wrote: > On Thu, Mar 12, 2015 at 5:21 PM, Andres Freund <and...@2ndquadrant.com> wrote: > > On 2015-03-12 16:42:24 -0700, Peter Geoghegan wrote: > >> We want to create a new role when this happens, for various reasons. > >> This occurs after recovery ends, but before the database has been > >> "unfenced". The template code that generates various ALTER ROLE > >> statements in our internal provisioning system - which has apparently > >> worked just fine for a long time - is: > > > > Is this all the code that's exececuted after recovery? How are these > > forks brought up? Promoted how? Is it a common 'source' database? > > We do PITR up to a recovery target.
So, no hot standby enabled? > I'm not sure what other code might have already been run at this > point, but it won't have been much. > > Have you looked at these files? Are they indeed zero bytes when this > > error occurs? > I think that they are indeed zero. I looked at that last week, when I > didn't consider that this might be a more widespread issue. I'll check > again later. > > 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. > I am unfamiliar with this provisioning code, so, as I > mentioned, offhand I cannot be entirely sure that there isn't some > other code run when the problem originally arises (that I should have > included in my report). It's probably worthwhile to dig out what's happening. > What I can tell you is that I saw the same error messages when I > manually ran the statements generated by the above code within a > transaction...until I ran "VACUUM FULL pg_auth_members;". You can reproduce that problem? How easily? If you can, please produce a backtrace. It'll certainly be interesting to see whether that access is through an index or whatnot. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers