From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
Cc: | Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: CatCache state reversing |
Date: | 2004-05-15 18:27:44 |
Message-ID: | 8074.1084645664@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> What I'm currently thinking is that for each entry in the cache, we'll
> save the current refcount at subtransaction start, and then restore it
> at subtransaction abort. At subtransaction commit, the parent's
> refcount will be updated with the subtransaction's refcount, which can
> be greater than zero.
No it can't. The reference counts should all be exactly the same at
subtrans start and subtrans commit, else there was a reference leak.
This corresponds to complaining if the count isn't zero at main trans
commit. I don't see that there should ever be a situation where a
subtrans releases a refcount acquired by an outer trans or vice versa.
While you're looking at that, what about the cache invalidation logic?
I think subtrans commit is probably not different from
CommandCounterIncrement, but I'm not sure how to clean up the caches and
the pending-inval lists on subtrans abort.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Hallgren | 2004-05-15 19:18:50 | Re: add server include files to default installation? |
Previous Message | Tom Lane | 2004-05-15 18:08:39 | Re: relcache refcount |