> Clearly it's trying to use an OID it calculated for one of these > tables after the table has been dropped, and I suspect that the lock > is released between gathering the data and sorting it. I don't have > any 8.2 databases around to try this on, but perhaps you would avoid > it with a slight rearrangement of your monitoring query:
Thanks for both making this clear and providing an rearranged/modified version of my original query. I'll try out this option also. > If that doesn't do it I might try adding zero to numbers and > concatenating empty strings to try to prevent late use of the OID. > (Essentially as a form of optimization barrier.) I couldn't understand this approach clearly. Can you help explain me with some example? -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
