Re: proposal: add 'waiting for replication' to pg_stat_activity.state
От | Craig Ringer |
---|---|
Тема | Re: proposal: add 'waiting for replication' to pg_stat_activity.state |
Дата | |
Msg-id | CAMsr+YHcd3ucC8GA7i25p_LC=QFKRywpNWDoE3BE+3EsGLNCxQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: proposal: add 'waiting for replication' to pg_stat_activity.state (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: proposal: add 'waiting for replication' to pg_stat_activity.state
|
Список | pgsql-hackers |
On 3 December 2015 at 22:58, Amit Kapila <amit.kapila16@gmail.com> wrote:
On Thu, Dec 3, 2015 at 9:02 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
>
> On 3 December 2015 at 09:32, Peter Eisentraut <peter_e@gmx.net> wrote:
>>
>> On 12/2/15 7:00 PM, Craig Ringer wrote:
>> > I notice that you don't set the 'waiting' flag. 'waiting' is presently
>> > documented as:
>> >
>> > <entry>True if this backend is currently waiting on a lock</entry>
>> >
>> > ... but I'm inclined to just widen its definition and set it here, since
>> > we most certainly are waiting, and the column isn't named
>> > 'waiting_on_a_lock'. It shouldn't upset various canned lock monitoring
>> > queries people have since they generally do an inner join on pg_locks
>> > anyway.
>>
>> I'm not so sure about that assumption.
>
>
> Even if it's an outer join, the worst that'll happen is that they'll get entries with nulls in pg_locks. I don't think it's worth worrying about too much.
>
That can be one way of dealing with it and another is that wekeep the current column as it is and add another view relatedwait stats, anyway we need something like that for other purposeslike lwlock waits etc. Basically something on lines what weis being discussed in thread [1]
В списке pgsql-hackers по дате отправления: