Re: [Gnumed-devel] address@hidden: Re: [GENERAL] XMIN semantic at peril ?]

[Syan Tan]

savepoints don't commit, they only allow partial rollback, so that
if an app crashed whilst holding a top level transaction , the rest
of the transaction would still be lost. that's why you need staged commits.
The top level transaction is to get rid of needing to check for xmin changes.
the read committed should update the xmin invisibly. the poll for changes would
mean being on the main gui event thread , using a specific timer event. 
user responses would be handled on the same event thread, a bit like the windows
main event loop thread ( used to be a giant switch statement inside a for loop).

 
On Fri Oct 12  0:13 , Karsten Hilbert  sent:

>On Fri, Oct 12, 2007 at 08:04:40AM +1000, Tim Churches wrote:
>
>> Syan Tan wrote:
>> > you wouldn't need xmin checking if more effort was made by the postgresql 
>> > people
>> > to cater
>> > for caching interactive clients , which would  be a significant group of pg
customers
>> > i would have thought. e.g something like using savepoints, atomic 
>> > commit/resume
>> > transaction , the ability to read committed in order to reload , and the 
>> > ability
>> > to poll for change notification, so that you don't need another thread to 
>> > listen
>> > for notified changes, and you can use read committed to refresh cached 
>> > values.
>> > Too much to ask for ? 
>> 
>> Have you actually asked the Postgres maintainers for these things?
>
>No need for that. PG already does
>
>- savepoints
>- thereby commit/resume of transactions
>- read-committed serialization level
>- libpq can be polled for NOTIFYs
>
>Karsten
>-- 
>GPG key ID E4071346 @ wwwkeys.pgp.net
>E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
>
>
>_______________________________________________
>Gnumed-devel mailing list
>address@hidden
>http://lists.gnu.org/mailman/listinfo/gnumed-devel