Thread: Seems like bug in 9.1.3, need to confirm.
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.
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
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.
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.