* Tom Lane ([EMAIL PROTECTED]) wrote: > Stephen Frost <[EMAIL PROTECTED]> writes: > > Subject pretty much says it all. I've put up with this error in the > > past when it has caused me trouble but it's now starting to hit our > > clients on occation which is just unacceptable. > > Have you tracked down the exact scenario making it happen?
I think I might have confused two different issues, sorry. :/ > > If this is correct then the solution seems to be either add versioning > > to the SysCache data, > > You have provided no evidence that that would fix anything at all. > To my mind a "concurrently updated" failure is more likely to mean > insufficient locking around update operations. I havn't built a reliable test case yet but I *think* the tuple concurrently updated problem is with an analyze being run inside of a function and also being run by autovacuum. The SysCache stuff I was thinking about previously was actually for another problem that I hadn't seen in a long time (because I hadn't been doing a particular set of operations, not because it's that difficult to have happen) but just ran into again today: ERROR: cache lookup failed for relation ... I first started seeing this happen, iirc, when I created a function which went against pg_class/pg_attribute/pg_type and used pg_table_is_visible(). This function (and another which uses pg_class, pg_constraint and pg_attribute) gets used over and over again from another pl/pgsql function. Basically we are walking through a list of tables pulling the column names and primary keys and then running some checks on the tables. Anyhow, while this is running (and it takes upwards of half an hour to run) other activity on the database (this time it was creating a view in a seperate completely unrelated schema) can cause the lookup failure which kills the long-running function (which gets to be very frustrating...). Thanks, Stephen
Description: Digital signature