Re: [HACKERS] md.c is feeling much better now, thank you
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] md.c is feeling much better now, thank you |
Дата | |
Msg-id | 8871.936278837@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | RE: [HACKERS] md.c is feeling much better now, thank you ("Hiroshi Inoue" <Inoue@tpf.co.jp>) |
Ответы |
Re: [HACKERS] md.c is feeling much better now, thank you
|
Список | pgsql-hackers |
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes: > StartTransaction() and CommandCounterIncrement() trigger > relation cache invalidation. Unfortunately those are insufficient > to prevent backends from inserting into invalid relations. > > If a backend is blocked by vacuum,it would insert into the target > relation without relation cache invalidation after vacuum. If that's true, then we have problems far worse than whether mdtruncate has tried to unlink the segment. What you are saying is that another backend can attempt to do an insert/update on a relation being vacuumed, and have gotten as far as deciding which block it's going to insert the tuple into before it gets blocked by vacuum's AccessExclusiveLock. If so, that is *broken* and it's not mdtruncate's fault. What happens if vacuum fills up the chosen block with moved tuples? I did indeed wonder whether relation cache inval will do the right thing when another backend is already waiting to access the relation being invalidated --- but if it does not, we have to fix the inval mechanism. mdtruncate is the least of our worries. Vadim, any comments here? regards, tom lane
В списке pgsql-hackers по дате отправления: