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@sss.pgh.pa.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