stark@enterprisedb.com (Gregory Stark) writes:
> "Jan Wieck" <JanWieck@Yahoo.com> writes:
>
>> backend1: select publish_snapshot(); -- will block
>>
>> backend2: start transaction;
>> backend2: set transaction isolation level serializable;
>> backend2: select clone_snapshot(<pid>); -- will unblock backend1
>
> It seems simpler to have a current_snapshot() function that returns an bytea
> or a new snapshot data type which set_current_snapshot(bytea) took to change
> your snapshot. Then you could use tables or out-of-band communication to pass
> around your snapshots however you please.
>
> set_current_snapshot() would have to sanity check that the xmin of the new
> snapshot isn't older than the current globaloldestxmin.
>
> That could be handy for debugging purposes too.
Here's a wild thought...
Would there be any sense in setting up the ability to declare
expressly a transaction's visibility parameters?
Consider that the Slony-I sl_event table records: ev_minxid, ev_maxxid, ev_xip
Grabbing a sample from an instance...[ ev_minxid| ev_maxxid| ev_xip ] = [1377591608 | 1377591612 |
'1377591608','1377591610']
Would it be plausible to, in effect, assert these things?
To say:
start transaction;
set transaction isolation level serializable;
select set_transaction_visibility(1377591608, 1377591612, [1377591608, 1377591610]);
And thus assert the visibility that was recorded at that point in
time?
I may very well have the parameters characterized in a wrong way;
please assume an appropriate way instead as needed :-).
This would permit, if I am seeing this right, a way that you could, in
effect, get a form of "time travel" via this where you'd be able to
arbitrarily point at different forms of data visibility. The wild
part being that you could assert data visibility declarations that a
normal connection couldn't naturally obtain...
--
let name="cbbrowne" and tld="linuxdatabases.info" in name ^ "@" ^ tld;;
http://linuxfinances.info/info/multiplexor.html
Sturgeon's Law: 90% of *EVERYTHING* is crud.
