Re: RFC: replace pg_stat_activity.waiting with something more descriptive
От | Robert Haas |
---|---|
Тема | Re: RFC: replace pg_stat_activity.waiting with something more descriptive |
Дата | |
Msg-id | CA+TgmoaMUrmthu_pQyFOam63Av-=kHpqT8MqdBV1YD45L=Oq9A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: RFC: replace pg_stat_activity.waiting with something more descriptive (Josh Berkus <josh@agliodbs.com>) |
Список | pgsql-hackers |
On Tue, Aug 4, 2015 at 8:46 PM, Josh Berkus <josh@agliodbs.com> wrote: > On 06/25/2015 07:50 AM, Tom Lane wrote: >> To do that, we'd have to change the semantics of the 'waiting' column so >> that it becomes true for non-heavyweight-lock waits. I'm not sure whether >> that's a good idea or not; I'm afraid there may be client-side code that >> expects 'waiting' to indicate that there's a corresponding row in >> pg_locks. If we're willing to do that, then I'd be okay with >> allowing wait_status to be defined as "last thing waited for"; but the >> two points aren't separable. > > Speaking as someone who writes a lot of monitoring and alerting code, > changing the meaning of the waiting column is OK as long as there's > still a boolean column named "waiting" and it means "query blocked" in > some way. > > Users are used to pg_stat_activity.waiting failing to join against > pg_locks ... for one thing, there's timing issues there. So pretty much > everything I've seen uses outer joins anyway. All of that is exactly how I feel about it, too. It's not totally painless to redefine waiting, but we're not proposing a *big* change in semantics. The way I see it, if we change this now, some people will need to adjust, but it won't really be a big deal. If we insist that "waiting" is graven in stone, then in 5 years people will still be wondering why the "waiting" column is inconsistent with the "wait_state" column. That's not going to be a win. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: