Re: [GENERAL] pgstattuple triggered checkpoint failure and database outage? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [GENERAL] pgstattuple triggered checkpoint failure and database outage?
Date
Msg-id 437.1238473220@sss.pgh.pa.us
Whole thread Raw
Responses Re: [GENERAL] pgstattuple triggered checkpoint failure and database outage?  (Stuart Bishop <stuart@stuartbishop.net>)
Re: [GENERAL] pgstattuple triggered checkpoint failure and database outage?  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
I wrote:
> ... what this sounds like is a
> problem with somebody fetching temporary-table blocks into shared memory
> (where they should never be), and then things going wrong after the
> owning backend drops the temp table (without having cleared out shared
> buffers, which it won't do because it doesn't think it needs to).  Can
> you say what was the exact command(s) you were using with pgstattuple?

A quick look at contrib/pgstattuple shows that it makes no effort
whatsoever to avoid reading temp tables belonging to other sessions.
So even if that wasn't Stuart's problem (and I'll bet it was), this
is quite broken.

There is no way that pgstattuple can compute valid stats for temp
tables of other sessions; it doesn't have access to pages in the other
sessions' temp buffers.  It seems that the alternatives we have are
to make it throw error, or to silently return zeroes (or perhaps
nulls?).  Neither one is tremendously appetizing.  The former would
be especially unhelpful if someone tried to write a query to apply
pgstattuple across all pg_class entries, which I kinda suspect is
what Stuart did.

Opinions?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: can't load plpython
Next
From: "David E. Wheeler"
Date:
Subject: Re: [GENERAL] string_to_array with empty input