On Thu, Feb 17, 2011 at 4:29 PM, Simon Riggs <si...@2ndquadrant.com> wrote: >> Something like the following description should be in the doc. >> >> hot_standby_feedback has no effect if either hot_standby is off or >> wal_receiver_status_interval is zero. > > The docs are going to need some work after 3-4 related major changes hit > them. I'm not picking up on individual sentences right now.
OK. >> + if (MyProc->xmin != newxmin) >> + { >> + LWLockAcquire(ProcArrayLock, LW_SHARED); >> + MyProc->xmin = newxmin; >> + LWLockRelease(ProcArrayLock); >> >> ProcArrayLock should be taken with LW_EXCLUSIVE since the shared >> variable is changed. No? > > No, shared is sufficient for setting xmin, as we do in > GetSnapshotData(). Hmm.. it's because setting uint32 variable (i.e., xmin) is an atomic operation? I'd like to know why LW_SHARED is sufficient in that case, just for future reference. >> What about exposing the feedback xid and epoch in pg_stat_replication? >> It's useful when we investigate which standby unexpectedly prevents >> VACUUM on the primary. > > This begs the questions "what is the xmin of all the normal backends?" > and "Whats is the xmin of prepared transactions?" as well. I wasn't sure > that we should expose that information for walsenders when we don't do > it for everybody else. If we do it would require major sections in the > docs explaining it all, etc.. We can *presume* which backend (or prepared transaction) unexpectedly prevents VACUUM by seeing pg_stat_activity (or pg_prepared_xacts) and checking whether there is long-running transaction. But there is no way to presume which standby does that, I'm concerned. >> It seems too aggressive to calculate the oldest xmin and return it for >> each WAL write and flush on the standby. I think this because calculation >> of the oldest xmin is not light operation especially when there are many >> concurrent backends. How about feeding back the xmin only when the >> interval has passed? > > You may be correct. Some rearrangement following performance tuning is > likely, though I've tried not to pre-guess the tuning. Are you planning to do that in beta phase or another? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers