Magnus Hagander <mag...@hagander.net> writes: > I guess with the changes that showed different thing like fastpath, > that makes sense. But if we just mapped the states that are there > today straight off, is there any case where waiting can be true, when > we're either idle or idle in transaction? I think not..
I'm not totally sure about that. I know that it's possible to see "idle waiting" in the ps display, but that comes from getting blocked in parse analysis before the command type has been determined. The pg_stat_activity string is set a bit earlier, so *maybe* it's impossible there. Still, why wire such an assumption into the structure of the view? Robert's point about sinval catchup is another good one, though I don't remember what that does to the pg_stat_activity display. BTW, a quick grep shows that there are four not two special values of the activity string today: src/backend/tcop/postgres.c: 3792: pgstat_report_activity("<IDLE> in transaction (aborted)"); src/backend/tcop/postgres.c: 3797: pgstat_report_activity("<IDLE> in transaction"); src/backend/tcop/postgres.c: 3805: pgstat_report_activity("<IDLE>"); src/backend/tcop/postgres.c: 3925: pgstat_report_activity("<FASTPATH> function call"); It's also worth considering whether the "autovacuum:" that's prepended by autovac_report_activity() ought to be folded into the state instead of continuing to put something that's not valid SQL into the query string. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers