Re: Patch: show xid and xmin in pg_stat_activity and pg_stat_replication - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Patch: show xid and xmin in pg_stat_activity and pg_stat_replication
Date
Msg-id 20140212101456.GB3162@alap3.anarazel.de
Whole thread Raw
In response to Re: Patch: show xid and xmin in pg_stat_activity and pg_stat_replication  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Patch: show xid and xmin in pg_stat_activity and pg_stat_replication  (Christian Kruse <christian@2ndquadrant.com>)
List pgsql-hackers
On 2014-02-11 09:15:45 -0500, Robert Haas wrote:
> If I understand correctly, modifying PgBackendStatus adds additional
> fields to the shared memory data structure that are never used and
> will be returned by functions like pgstat_fetch_stat_beentry()
> unitialized.  That seems both inefficient and a pitfall for the
> unwary.

I don't think the will be unitialized, pgstat_fetch_stat_beentry() will
do a pgstat_read_current_status() if neccessary which will initialize
them.

But they do take up shared memory without really needing to. I
personally don't find that too bad, it's not much memory. If we want to
avoid it we could have a LocalPgBackendStatus that includes the normal
PgBackendStatus. Since pgstat_read_current_status() copies all the data
locally, that'd be a sensible point to fill it. While that will cause a
bit of churn, I'd guess we can use the infrastructure in the not too far
away future for other parts.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Retain dynamic shared memory segments for postmaster lifetime
Next
From: Christoph Berg
Date:
Subject: Re: [BUG] Archive recovery failure on 9.3+.