Re: postgresql and process titles - Mailing list pgsql-hackers

From Tom Lane
Subject Re: postgresql and process titles
Date
Msg-id 632.1150305717@sss.pgh.pa.us
Whole thread Raw
In response to Re: postgresql and process titles  (Greg Stark <gsstark@mit.edu>)
Responses Re: postgresql and process titles  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
Greg Stark <gsstark@mit.edu> writes:
> If backends store their current status in shared memory then a separate
> process entirely can receive the interrupts, scan through the shared memory
> process states and do the accounting.

This sounds good until you think about locking.  It'd be quite
impractical to implement anything as fine-grained as EXPLAIN ANALYZE
this way, because of the overhead involved in taking and releasing
spinlocks.

It could be practical as a replacement for stats_command_string
messages, though.

I'm not sure about replacing ps_status with this.  I don't think there
is a way for one process to set another's status (on most platforms
anyway).  You might argue that we could abandon ps_status reporting
altogether if we had something better, but I'm unconvinced ...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Question about Ctrl-C and less
Next
From: Bruce Momjian
Date:
Subject: Re: Multi-byte and client side character encoding tests for