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 по дате отправления: