Re: WIP patch: Improve relation size functions such as pg_relation_size() to avoid producing an error when called against a no longer visible relation

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Phil Sorber <phil(at)omniti(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org, OmniTI DBA <dba(at)omniti(dot)com>
Subject: Re: WIP patch: Improve relation size functions such as pg_relation_size() to avoid producing an error when called against a no longer visible relation
Date: 2012-01-19 11:19:11
Message-ID: 4F17FC2F.2000405@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 23.12.2011 02:01, Phil Sorber wrote:
> On Thu, Dec 22, 2011 at 3:19 PM, Robert Haas<robertmhaas(at)gmail(dot)com> wrote:
>> On Thu, Dec 22, 2011 at 2:02 PM, Phil Sorber<phil(at)omniti(dot)com> wrote:
>>> On Thu, Dec 22, 2011 at 1:33 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>> Robert Haas<robertmhaas(at)gmail(dot)com> writes:
>>>>> I'm wondering if we oughta just return NULL and be done with it.
>>>>
>>>> +1. There are multiple precedents for that sort of response, which we
>>>> introduced exactly so that "SELECT some_function(oid) FROM some_catalog"
>>>> wouldn't fail just because one of the rows had gotten deleted by the
>>>> time the scan got to it. I don't think it's necessary for the
>>>> relation-size functions to be any smarter. Indeed, I'd assumed that's
>>>> all that Phil's patch did, since I'd not looked closer till just now.
>>>
>>> Here it is without the checking for recently dead. If it can't open
>>> the relation it simply returns NULL.
>>
>> I think we probably ought to make pg_database_size() and
>> pg_tablespace_size() behave similarly.
>
> Changes added.

Looks good to me, committed. I added a sentence to the docs mentioning
the new behavior, and also a code comment to explain why returning NULL
is better than throwing an error.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2012-01-19 12:05:32 review:tracking temporary files in pg_stat_database
Previous Message Hitoshi Harada 2012-01-19 10:08:52 Re: Publish checkpoint timing and sync files summary data to pg_stat_bgwriter