Re: tuple concurrently updated
От | Tom Lane |
---|---|
Тема | Re: tuple concurrently updated |
Дата | |
Msg-id | 11307.1027873956@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: tuple concurrently updated (Curt Sampson <cjs@cynic.net>) |
Ответы |
Re: tuple concurrently updated
|
Список | pgsql-hackers |
Curt Sampson <cjs@cynic.net> writes: > On Thu, 25 Jul 2002, Tom Lane wrote: >> "Kangmo, Kim" <ilvsusie@hanafos.com> writes: > If the index on the same class, > two concurrent CREATE INDEX command can update pg_class.relpages > at the same time. >> >> Or try to, anyway. The problem here is that the code that updates >> system catalogs is not prepared to cope with concurrent updates >> to the same tuple. > I see. So the error is basically harmless, and can be rectified anyway > with an ANALYZE, right? Other than the fact that the second CREATE INDEX fails and rolls back, there's no problem ;-) I was thinking that it might help to have UpdateStats not try to update the pg_class tuple if the correct value is already present. This will just narrow the window for failure, not eliminate it; but it'd be a simple change and would probably help some. Another thing to look at is merging that routine with setRelhasindex so that a CREATE INDEX involves only one update to the table's pg_class row, not two. regards, tom lane
В списке pgsql-hackers по дате отправления: