[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: [HACKERS] hot standby - further cleanup of recovery procs stuff
From:       Heikki Linnakangas <heikki.linnakangas () enterprisedb ! com>
Date:       2009-08-31 10:31:06
Message-ID: 4A9BA66A.7090506 () enterprisedb ! com
[Download RAW message or body]

Robert Haas wrote:
> I've made a few further cleanups to the hot standby patch:

Thanks!

> I am not sure why we have a single GUC to size both the number of
> PGPROC structures we allow and the size of UnobservedXids.  A
> read-only slave might only need to allow a few connections for
> reporting purposes, while the master needs to allow many.

Yeah, it is true that the two don't necessarily have much in common. We
could well make it a separate GUC. We'd still need to find a reasonable
default, though.

It should be noted that UnobservedXids array is allocated in shared
memory, but goes completely unused after the recovery, becoming a waste
of memory. It's only a few hundred kB at most, so I think that's
acceptable, but it would be nice to be able to release that memory
somehow. Perhaps it should be backed with a file, which would also have
the benefit that it could grow as needed, eliminating the need for the
GUC. Storing it in a new SLRU might be a good idea.

I started to look at the subtrans.c changes. The patch changes the role
of pg_subtrans substantially. It is no longer simply cleared at startup,
but we require it to contain valid data when we start recovery for
transactions that have overflowed the in-memory cache. That makes me a
bit uncomfortable, although I don't see anything obviously wrong with
it. The comment in CheckpointSUBTRANS() claiming that flushing
pg_subtrans is just a debugging aid is now wrong, however.

I think there's also a bug in ExtendSUBTRANS(): it will zap the first
page it touches in recovery, but right after we start recovery, and
replay the first RunningXacts WAL record, we need to have pg_subtrans
correctly set for the transactions in that RunningXacts record (that
have overflowed the in memory subxid cache). Zapping the pg_subtrans
page can destroy that information.

-- 
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[prev in list] [next in list] [prev in thread] [next in thread]