Seems like bug in 9.1.3, need to confirm.

AI Rumman <rummandba@gmail.com> writes:

I executed the following query and got an error:
select relname, pg_size_pretty(pg_table_size(relname::text)) as s from
pg_stat_user_tables order by pg_table_size(relname::text) desc limit 10;
ERROR: relation "tab_20130206" does not exist

Use the OID, not the relname, else you'll have issues with any table
that's not in your search_path.

regards, tom lane

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

rummandba wrote

HI,

I am working on Postgresql 9.1.3.
I executed the following query and got an error:
select relname, pg_size_pretty(pg_table_size(relname::text)) as s from
pg_stat_user_tables order by pg_table_size(relname::text) desc limit 10;
ERROR: relation "tab_20130206" does not exist

That table does not exist in the db, that's correct. But is it right I am
getting the error or it is a bug?

Thanks.

The documentation for 9.1 (of which you are using an ancient point release)
does not define the behavior that occurs in this situation.

Beginning in 9.2 the documentation explicitly states:

"If an OID that does not represent an existing object is passed as argument
to one of the above functions, NULL is returned."

My educated guess is that the behavior was changed in 9.2 to make these
functions more user-friendly. That kind of change is never back-ported to
previous releases so the 9.1 behavior is as-designed and will not be
corrected to conform with the newer behavior.

In the off-chance the behavior in 9.1.3 was a regression updating to the
newest point release (9.1.11) will fix the issue. You should do this anyway
- though there have been a spate of point-release bugs cropping up recently
so...

Or feel free to peruse the release notes for 9.2, this behavior change
should be documented if intentional.

http://www.postgresql.org/docs/9.2/interactive/functions-admin.html [9.26.6]

David J.

--
View this message in context: http://postgresql.1045698.n5.nabble.com/Seems-like-bug-in-9-1-3-need-to-confirm-tp5784296p5784302.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

David Johnston wrote

Or feel free to peruse the release notes for 9.2, this behavior change
should be documented if intentional.

Reading said notes it appears that the "returns NULL" behavior compensates
for a concurrent DROP of an existing/known OID. Since your issue is that
the object was never physically present, and thus did not have an OID, so
the attempt to obtain an OID failed and resulted in an error.

David J.

--
View this message in context: http://postgresql.1045698.n5.nabble.com/Seems-like-bug-in-9-1-3-need-to-confirm-tp5784296p5784304.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general