From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [COMMITTERS] pgsql: Hot Standby feedback for avoidance of cleanup conflicts on stand |
Date: | 2011-02-18 02:44:08 |
Message-ID: | AANLkTi=v7zbQBkjhrY7+6J1gRNio3B4mPz_ZX0xGvPzD@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Thu, Feb 17, 2011 at 4:29 PM, Simon Riggs <simon(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2011-02-18 02:48:18 | Re: pgsql: Use $INDENT rather than indent throughout the pgindent code |
Previous Message | Alvaro Herrera | 2011-02-18 01:23:03 | pgsql: Convert Postgres arrays to Perl arrays on PL/perl input argument |
From | Date | Subject | |
---|---|---|---|
Next Message | Gan Jiadong | 2011-02-18 02:58:57 | About the performance of startup after dropping many tables |
Previous Message | Tom Lane | 2011-02-18 02:13:29 | Re: contrib loose ends: 9.0 to 9.1 incompatibilities |