Joseph Shraibman <jks@selectacast.net> writes:
> On 12/08/2011 12:54 AM, Tom Lane wrote:
>> Joseph Shraibman<jks@selectacast.net> writes:
>>> All was fine until:
>>> LOG: statement: select "_devel".cleanupEvent('10 minutes'::interval,
>>> 'false'::boolean);
>>> ERROR: could not open file "base/16406/2072097_fsm": Permission denied
>> That's pretty weird. What were the permissions on that file? Was it
>> properly owned by the postgres user?
> It had no permissions at all
> ---------- 1 postgres postgres 0 Feb 14 2005 2072097_fsm
> I actually didn't notice the old date until now. This was an 8.4.x
> database that I upgraded to 9.1.1 a while ago using pg_upgrade (using
> the hardlink option). I still have a backup of the 8.4 database from
> when I did the upgrade, and that file doesn't appear in it.
It turns out that the crash at commit + failure to restart was a bug
introduced in 8.4; it should have just unlinked the file without
complaint. I've now applied a patch for that misbehavior.
It's still mighty weird that the file was there with that mod date in
the first place, since PG certainly wasn't using FSM forks in 2005, even
if this database is that old. I'm guessing that the mod date and lack
of permissions are both artifacts of some non-PG operation, perhaps a
failed rsync or some such? I would suspect pg_upgrade except I'm pretty
sure it does not mess with either permissions or mod date.
Anyway, future releases should handle such a thing a bit more
gracefully.
regards, tom lane