Magnus Hagander <magnus@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
