Re: [HACKERS] Lots of FSM-related fragility in transaction commit

2011-12-19 Thread Tom Lane
Heikki Linnakangas writes: > On 08.12.2011 08:20, Tom Lane wrote: >> I thought that removing the unreadable file would let me restart, >> but after "rm 52860_fsm" and trying again to start the server, >> there's a different problem: >> LOG: consistent recovery state reached at 0/5D71BA8 >> LOG:

Re: [HACKERS] Lots of FSM-related fragility in transaction commit

2011-12-08 Thread Tom Lane
Heikki Linnakangas writes: > On 08.12.2011 08:20, Tom Lane wrote: >> So this is really a whole lot worse than our behavior was in pre-FSM >> days, and it needs to get fixed. > This bug was actually introduced only recently. Notice how the log says > "consistent recovery state reached at 0/5D71BA

Re: [HACKERS] Lots of FSM-related fragility in transaction commit

2011-12-08 Thread Heikki Linnakangas
On 08.12.2011 08:20, Tom Lane wrote: I thought that removing the unreadable file would let me restart, but after "rm 52860_fsm" and trying again to start the server, there's a different problem: LOG: database system was interrupted while in recovery at 2011-12-08 00:56:11 EST HINT: This proba

[HACKERS] Lots of FSM-related fragility in transaction commit

2011-12-07 Thread Tom Lane
Joseph Shraibman reported some rather unpleasant behavior that seems to be due to trying to drop a table whose FSM file has got no permissions: http://archives.postgresql.org/pgsql-general/2011-12/msg00246.php One question is how the file got that way, and whether Postgres did anything wrong to ca