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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
