Gregory Stark wrote:
Simon Riggs <[EMAIL PROTECTED]> writes:
So passing xl_xmin from master to standby seems not necessary to me. The
standby's OldestXmin needs to be passed through to the master, not the
other way around so that WAL records for tuple removal are not
generated.
I think most people were pretty leery of doing it that way because it means
activity on the standby database can cause the master to bloat. The consensus
seemed to be headed towards having WAL replay on the standby stall if it meets
a tuple removal record for a tuple that's visible to a query running on it.
Probably with a mechanism to configure a maximum amount of time it can be
stalled before shooting those queries.
Yes, but we can quite easily provide an option on top of that to
advertise the slave xmin back to the master, for those who prefer some
bloat on master over stalling replay or killing queries in the slave. In
fact, I think a lot of people will choose some compromise, where the
slave xmin is advertised back to the master, but the master will obey it
only up to some limit, after which the slave will need to stall or kill
queries again.
It's not something that needs to be done in the first phase, but should
be straightforward to add after the basics are working. In any case,
we'll need the capability in the slave to notice when it's about to
remove a tuple that's still visible to a snapshot in the slave.
--
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
