Brian Cox <brian.cox@xxxxxx> writes: > On 04/10/2010 12:29 AM, Tom Lane [tgl@xxxxxxxxxxxxx] wrote: >> but anyway: the main >> known cause for that is if one of the tables used in the query got >> dropped (by another session) just after the query started. Could >> that have happened to you? > interesting and possible; but why doesn't locking prevent this? Locking prevents you from getting some random internal failure that would happen if the table disappeared mid-query. It cannot eliminate the problem altogether, because the issue here is that the dropping transaction got there first; there is no reason not to allow it to proceed. So the reading transaction is going to fail. The most we could change is the spelling of the error message, but I'm not sure that masking the fact that something odd happened is a good idea. (From the reader's viewpoint, it did see a table by that name in the catalogs, but by the time it acquired lock on the table, the catalog entry was gone. Playing dumb and just saying "table does not exist" could be even more confusing than the current behavior.) regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
