On Thu, Feb 17, 2011 at 4:29 PM, Simon Riggs <simon@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