| From: | Stuart Bishop <stuart(at)stuartbishop(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [GENERAL] pgstattuple triggered checkpoint failure and database outage? |
| Date: | 2009-03-31 04:29:21 |
| Message-ID: | 6bc73d4c0903302129h77774d49o5db204bd785bf335@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers |
On Tue, Mar 31, 2009 at 11:20 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.
This is exactly what happened, and temporary tables belonging to other
sessions where fed to pgstattuple.
--
Stuart Bishop <stuart(at)stuartbishop(dot)net>
http://www.stuartbishop.net/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Stark | 2009-03-31 06:16:05 | Re: string_to_array with empty input |
| Previous Message | Stuart Bishop | 2009-03-31 04:26:24 | Re: pgstattuple triggered checkpoint failure and database outage? |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Treat | 2009-03-31 05:14:16 | Re: psql \d* and system objects |
| Previous Message | Stuart Bishop | 2009-03-31 04:26:24 | Re: pgstattuple triggered checkpoint failure and database outage? |