Re: relcache refcount
От | Tom Lane |
---|---|
Тема | Re: relcache refcount |
Дата | |
Msg-id | 2739.1084591302@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: relcache refcount (Alvaro Herrera <alvherre@dcc.uchile.cl>) |
Ответы |
Re: relcache refcount
|
Список | pgsql-hackers |
Alvaro Herrera <alvherre@dcc.uchile.cl> writes: > Ok, I created a function to copy a hash table (from dynahash). So now > at subtransaction start the RelationIdCache and RelationSysNameCache > hash tables are copied, and if the subtransaction aborts the previous > hash tables are restored. I don't think that will do; what about updates absorbed during the subtrans from other backends' changes? In any case, copying the whole cache state during every subtrans start is not the kind of overhead I wish to pay ... > Regarding the lock mechanism, I simply added some code to LockReleaseAll > so it gets the array of committed child Xids; on subtransaction abort, > the whole lock struct is scanned just like it's done on main transaction > abort; only those locks affiliated with one of the given Xids are > released. This is naive, so if it's incorrect please comment. Not sure; it's been a long day and I'm tired ... will think about it tomorrow ... > PS: Either the list server is getting very slow or it has started to > lose mail. I asked yesterday whether it was OK to copy the hash but > apparently the mail didn't make it to the list. Is there something > happening? I haven't seen that one. Check your subscription settings to see whether you'd be notified if the list bot delayed your post for some reason. regards, tom lane
В списке pgsql-hackers по дате отправления: