Re: Latest version of Hot Standby patch - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Latest version of Hot Standby patch
Date
Msg-id 1231875582.28919.65.camel@ebony.2ndQuadrant
Whole thread Raw
In response to Re: Latest version of Hot Standby patch  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Latest version of Hot Standby patch  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
On Wed, 2009-01-07 at 13:18 +0200, Heikki Linnakangas wrote:
> There's still something wrong with the way subtransactions are handled. 
> I got:
> 
> postgres=# SELECT * FROM foo;
> ERROR:  could not access status of transaction 118649
> DETAIL:  Could not open file "pg_subtrans/0001": No such file or directory.
> 
> in the standby after some testing.
> 
> I created a lot of subtransactions in the master, each inserting a row 
> to table 'foo', and left the transaction open. In another session, I did 
> a lot of dummy activity (truncate bar; insert into bar ...) to generate 
> WAL, and also checkpoints and pg_xlog_switch() calls. I then restarted 
> the standby, and got the above error.

I fixed this by ignoring I/O errors on pg_subtrans, but I think that's
the wrong approach and could mask errors.

ExtendSubtrans() doesn't generate WAL records, but it could. I don't
want to do that either for performance reasons.

Best way seems to be to do (almost) the same thing as ExtendSubtrans()
during recovery, so we zero out pages at the point that recovering
transactions get written to pg_subtrans.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Hot standby, slot ids and stuff
Next
From: Markus Wanner
Date:
Subject: Postgres-R (8) Architecture published