Re: How feasible is this?

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: Chris Smith <cdsmith(at)gmail(dot)com>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: How feasible is this?
Date: 2010-05-21 08:08:29
Message-ID: 4BF63F7D.2080608@postnewspapers.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 21/05/2010 9:22 AM, Chris Smith wrote:
> I'm writing in desperate hope that something like this exists... because
> if so, it would make my life a lot easier. I want to be able to:
>
> a) Roll back a transaction
>
> b) Receive a notification when retrying the exact same transaction might
> cause different data to be returned from something that was done up to
> the point of the rollback; i.e., some result set, update count, etc.
> might be different.

I don't see any way to do that without polling. You need to be able to
discover every record that the query results are generated from and
watch for one of them to change.

My non-expert feeling is that you could possibly extend a predicate
locking scheme to do this. It's something that'd maybe be possible by
hooking into the predicate locking schemes being being designed to
support true serializability in Pg (see periodic discussion on -hackers)
but those locking schemes aren't in the main PG code yet. Even if they
were, using them for this would be a significant amount of C-coding work
to extend the server.

It might be a good idea to take a few steps back and look at what you
are trying to achieve with this. Why do you want it? What for? What
problem will it solve for you?

--
Craig Ringer

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Glyn Astill 2010-05-21 09:58:56 Re: pg_restore: [custom archiver] dumping a specific TOC data block out of order is not supported without ID on this input stream (fseek required)
Previous Message Scott Marlowe 2010-05-21 06:24:19 Re: copy data from one db into another via copy & psql