From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stuart Bishop <stuart(at)stuartbishop(dot)net> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [GENERAL] pgstattuple triggered checkpoint failure and database outage? |
Date: | 2009-03-31 04:20:20 |
Message-ID: | 437.1238473220@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general 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
From | Date | Subject | |
---|---|---|---|
Next Message | David E. Wheeler | 2009-03-31 04:21:29 | Re: [HACKERS] string_to_array with empty input |
Previous Message | Tom Lane | 2009-03-31 04:10:55 | Re: pgstattuple triggered checkpoint failure and database outage? |
From | Date | Subject | |
---|---|---|---|
Next Message | David E. Wheeler | 2009-03-31 04:21:29 | Re: [HACKERS] string_to_array with empty input |
Previous Message | Alvaro Herrera | 2009-03-31 04:14:22 | Re: can't load plpython |