Skip site navigation (1) Skip section navigation (2)

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: Phil Sorber <phil(at)omniti(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Cc: OmniTI DBA <dba(at)omniti(dot)com>
Subject: 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: 2011-12-17 20:52:29
Message-ID: CADAkt-h9YgxeckZi9TmaU_BOOhunP9QodkR0yTPwA7A=npSO+A@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Attached is a patch that addresses the todo item "Improve relation
size functions such as pg_relation_size() to avoid producing an error
when called against a no longer visible relation."

http://archives.postgresql.org/pgsql-general/2010-10/msg00332.php

Instead of returning an error, they now return NULL if the OID is
found in pg_class when using SnapshotAny. I only applied it to 4
functions: select pg_relation_size, pg_total_relation_size,
pg_table_size and pg_indexes_size. These are the ones that were using
relation_open(). I changed them to using try_relation_open(). For
three of them I had to move the try_relation_open() call up one level
in the call stack and change the parameter types for some support
functions from Oid to Relation. They now also call a new function
relation_recently_dead() which is what checks for relation in
SnapshotAny. All regression tests passed.

Is SnapshotAny the snapshot I should be using? It seems to get the
correct results. I can drop a table and I get NULL. Then after a
vacuumdb it returns an error.

Attachment: improve_relation_size_functions.patch
Description: text/x-patch (6.7 KB)

Responses

pgsql-hackers by date

Next:From: Pavel StehuleDate: 2011-12-17 21:00:56
Subject: Re: review: CHECK FUNCTION statement
Previous:From: Pavel StehuleDate: 2011-12-17 20:37:36
Subject: Re: review: CHECK FUNCTION statement

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group