On Tue, 2008-12-30 at 14:40 +0200, Heikki Linnakangas wrote: > Simon Riggs wrote: > > > > That for me is beginning to sound fairly ugly: difficult to understand > > and difficult to use. But I see some people might want that in certain > > circumstances. So I guess we should build it. Any good ideas for the > > control mechanism? > > Using functions seems overly complicated.
We agree on that. > Since xids are system-wide, I > don't see much value in specifying them at any finer level, or in > allowing them for non-superusers. GUC seems like the natural choice. Well, GUCs have security implications that I'm not happy about. I will relent if you will vouch for that decision. "standby_xmin_on_primary" (boolean) - a USERSET GUC that only has meaning during standby query execution. <name> specifies whether the current standby session's xmin is included in the calculation of OldestXmin on the *primary* node. If this parameter is true then the standby query will never be cancelled because of conflicts between the activity of the primary and standby (see discussion in chapter XXXX). The downside of using this parameter is that standby queries can cause table bloat on the primary (see chapter Data Maintenance for more detail). "standby_xmin_on_primary" - new name sought. I think it should begin with "standby_" to remind us that it only effects standby query processing. Implementation: WALReceiver will send message back to WALSender. WALSender will update a single 4 byte value, RemoteXmin that is read during GetSnapshotData(). Updating value will not hold a lock, just as xid is not locked when setting new value. We add a boolean to each proc: SendRemoteXmin. When we run GetSnapshotData() if our own proc has SendRemoteXmin set then we calculate RemoteXmin from the minimum of any proc with SendRemoteXmin set. When we release our snapshot we re-calculate RemoteXmin so that the primary node suffers as little delay as possible in receiving updates to xmin. I'll begin work on this once sync rep is committed. It's about 3-5 days work, but no point in writing it yet because the sand will shift underneath it too much in the next few weeks. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
