| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Pg Patches <pgsql-patches(at)postgresql(dot)org> |
| Subject: | Re: Snapshot management, final |
| Date: | 2008-05-12 01:16:33 |
| Message-ID: | 2940.1210554993@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Tom Lane wrote:
>> Hmm ... but that "close" can't unregister the snapshot immediately,
>> because you'd lose if the 2nd savepoint gets rolled back, no? Is the
>> handling of this case even correct at the moment?
> No, CLOSE is not rolled back:
> ...
> Maybe this is possible to fix, but again I think it's outside the scope
> of this patch.
I'd forgotten that ... seems a bit bogus, and it's certainly not
documented on the CLOSE reference page.
>> ISTM correct handling of this example would require that the "close"
>> not really discard the snap until commit. Then, given proper ordering
>> of the cleanup operations at commit, you might be able to still have the
>> cross-check about s_level in UnregisterSnapshot. (IOW, maybe having
>> snapshot cleanup be late in the commit sequence wasn't such a good
>> choice...)
> Right -- I'll move them earlier.
Well, without a clear idea of where to place them instead, you might as
well leave it alone for the moment. I'd like to see this revisited
sometime though.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Francisco Reyes | 2008-05-12 02:43:19 | Re: Making sure \timing is on |
| Previous Message | Alvaro Herrera | 2008-05-12 01:10:16 | Re: Snapshot management, final |