Re: Re: [GENERAL] pgstattuple triggered checkpoint failure and database outage?

Stuart Bishop wrote:
> 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.

+1 for throwing an error. That's what we do for views, composite types,
and GIN indexes as well. If you want to write a query to call
pgstattuple for all tables in pg_class, you'll need to exclude all those
cases anyway. To exclude temp tables of other sessions, you'll need to
add "AND pg_is_other_temp_schema(relnamespace)".

I'm ok with returning NULLs as well, but returning zeroes doesn't feel
right.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com