ERROR: tuple concurrently updated
От | Stephen Frost |
---|---|
Тема | ERROR: tuple concurrently updated |
Дата | |
Msg-id | 20061219165932.GD24675@kenobi.snowman.net обсуждение исходный текст |
Ответы |
Re: ERROR: tuple concurrently updated
|
Список | pgsql-hackers |
Greetings, 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 startingto hit our clients on occation which is just unacceptable. The way I've seen it happen, and this is just empirically so I'm not sure that it's exactly right, is something like this: Running with pg_autovacuum on the system Run a long-running PL/PgSQL function which creates tables Wait for some sort ofoverlap, and the PL/PgSQL function dies with the above error. I've also seen it happen when I've got a long-running PL/PgSQL function going and I'm creating tables in another back-end. From a prior discussion I *think* the issue is the lack of versioning/visibility information in the SysCache which meansthat if the long-running function attempts to look-up data about a table which was created *after* the long-runningfunction started but was put into the common SysCache by another backend, the long-running function gets screwedby the 'tuple concurrently updated' query and ends up failing and being rolled back. If this is correct then the solution seems to be either add versioning to the SysCache data, or have an overall 'this SysCacheis only good for data past transaction X' so that a backend which is prior to that version could just accept thatit can't use the SysCache and fall back to accessing the data directly (if that's possible). I'm not very familiar withthe way the SysCache system is envisioned but I'm not a terrible programmer (imv anyway) and given some direction onthe correct approach to solving this problem I'd be happy to spend some time working on it. I'd *really* like to see thiserror just go away completely for all non-broken use-cases. Thanks, Stephen
В списке pgsql-hackers по дате отправления: