On Fri, 2008-03-28 at 11:33 -0400, Chris Browne wrote:
> [EMAIL PROTECTED] (Bruce Momjian) writes:
> > Added to TODO:
> >
> > * Allow one transaction to see tuples using the snapshot of another
> > transaction
> >
> > This would assist multiple backends in working together.
> > http://archive
[EMAIL PROTECTED] (Bruce Momjian) writes:
> Added to TODO:
>
> * Allow one transaction to see tuples using the snapshot of another
> transaction
>
> This would assist multiple backends in working together.
> http://archives.postgresql.org/pgsql-hackers/2008-01/msg00400.php
FYI, code for this
Added to TODO:
* Allow one transaction to see tuples using the snapshot of another
transaction
This would assist multiple backends in working together.
http://archives.postgresql.org/pgsql-hackers/2008-01/msg00400.php
--
On Sun, 2008-01-20 at 15:11 +, Gregory Stark wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>
> > On Sat, 2008-01-12 at 18:46 +, Gregory Stark wrote:
> >
> >> To do something like that the user would have to create a prepared
> >> transaction
> >> to save the snapshot. I think that ma
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Sat, 2008-01-12 at 18:46 +, Gregory Stark wrote:
>
>> To do something like that the user would have to create a prepared
>> transaction
>> to save the snapshot. I think that makes sense though since effectively it's
>> just requiring that the use
On Sun, 2008-01-20 at 12:37 +, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Sat, 2008-01-12 at 18:46 +, Gregory Stark wrote:
> >
> >> To do something like that the user would have to create a prepared
> >> transaction
> >> to save the snapshot. I think that makes sense though sin
Simon Riggs wrote:
On Sat, 2008-01-12 at 18:46 +, Gregory Stark wrote:
To do something like that the user would have to create a prepared transaction
to save the snapshot. I think that makes sense though since effectively it's
just requiring that the user explicitly do what would otherwise
On Thu, 2008-01-17 at 11:56 +0100, Florian G. Pflug wrote:
> Tom Lane wrote:
> > I'm not sure what the most convenient user API would be for an on-demand
> > hard-read-only mode, but we can't use SET TRANSACTION READ ONLY for it.
> > It'd have to be some other syntax. Maybe just use a GUC variable
On Sat, 2008-01-12 at 18:46 +, Gregory Stark wrote:
> To do something like that the user would have to create a prepared transaction
> to save the snapshot. I think that makes sense though since effectively it's
> just requiring that the user explicitly do what would otherwise be a hidden
> im
Tom Lane wrote:
I'm not sure what the most convenient user API would be for an on-demand
hard-read-only mode, but we can't use SET TRANSACTION READ ONLY for it.
It'd have to be some other syntax. Maybe just use a GUC variable
instead of bespoke syntax? SET TRANSACTION is really just syntactic
s
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> I seem to remember there being some pushback to the idea of changing the
> semantics of "set transaction isolation read only" from "soft" to "hard"
> semantics though - on the basis that it might break existing
> applications. If that has changed
Tom Lane wrote:
Chris Browne <[EMAIL PROTECTED]> writes:
Note that we required that the "provider transaction" have the
attributes IsXactIsoLevelSerializable and XactReadOnly both being
true, so we have the mandates that the resultant backend process:
a) Is in read only mode, and
b) Is in ser
On Sat, 2008-01-12 at 16:22 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > ... So if we did this via an installable module approach then we
> > would be able to use it much sooner for upgrading to 8.3, rather than
> > waiting for 8.4
>
> I think it borders on ludicrous to ima
Simon Riggs <[EMAIL PROTECTED]> writes:
> ... So if we did this via an installable module approach then we
> would be able to use it much sooner for upgrading to 8.3, rather than
> waiting for 8.4
I think it borders on ludicrous to imagine making this work with just an
installable module and no co
On Sat, 2008-01-12 at 15:42 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Sat, 2008-01-12 at 11:57 -0500, Tom Lane wrote:
> >> It would be far *more* useful if it didn't have to be superuser-only.
> >> And since the actual details of the snapshot content are really of
> >>
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Sat, 2008-01-12 at 11:57 -0500, Tom Lane wrote:
>> It would be far *more* useful if it didn't have to be superuser-only.
>> And since the actual details of the snapshot content are really of
>> zero interest to the user, I think making it pass through hi
On Sat, 2008-01-12 at 11:57 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Fri, 2008-01-11 at 19:23 -0500, Tom Lane wrote:
> >> [ blanches... ] Can you say "security hole"?
>
> > Static on the line, sorry.
> > I'm hearing "useful superuser-only capability". ;-)
>
> It w
On 1/12/08, Gregory Stark <[EMAIL PROTECTED]> wrote:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> >> On Fri, 2008-01-11 at 19:23 -0500, Tom Lane wrote:
> >>> [ blanches... ] Can you say "security hole"?
> >
> >> Static on the line, sorry.
> >> I'm hearing
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Simon Riggs <[EMAIL PROTECTED]> writes:
>> On Fri, 2008-01-11 at 19:23 -0500, Tom Lane wrote:
>>> [ blanches... ] Can you say "security hole"?
>
>> Static on the line, sorry.
>> I'm hearing "useful superuser-only capability". ;-)
>
> It would be far *more
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Fri, 2008-01-11 at 19:23 -0500, Tom Lane wrote:
>> [ blanches... ] Can you say "security hole"?
> Static on the line, sorry.
> I'm hearing "useful superuser-only capability". ;-)
It would be far *more* useful if it didn't have to be superuser-only.
A
On Fri, 2008-01-11 at 19:23 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > For (2) there's a very simple way of transferring the data between
> > sessions:
> > a) we connect on session 1 as a serializable transaction
> > b) we ask session 1 for its snapshot
> > c) we then con
Chris Browne <[EMAIL PROTECTED]> writes:
> Note that we required that the "provider transaction" have the
> attributes IsXactIsoLevelSerializable and XactReadOnly both being
> true, so we have the mandates that the resultant backend process:
> a) Is in read only mode, and
> b) Is in serializable m
Simon Riggs <[EMAIL PROTECTED]> writes:
> For (2) there's a very simple way of transferring the data between
> sessions:
> a) we connect on session 1 as a serializable transaction
> b) we ask session 1 for its snapshot
> c) we then connect on session 2 as a serializable transaction
> d) we then ex
[EMAIL PROTECTED] (Simon Riggs) writes:
> On Fri, 2008-01-11 at 20:39 +, Simon Riggs wrote:
>> On Fri, 2008-01-11 at 15:05 -0500, Tom Lane wrote:
>> Simon Riggs <[EMAIL PROTECTED]> writes:
>> > > If we had a function
>> > > replace_serializable_snapshot(master_xid, txid_snapshot)
>> > > this
On Fri, 2008-01-11 at 20:39 +, Simon Riggs wrote:
> On Fri, 2008-01-11 at 15:05 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > > If we had a function
> > > replace_serializable_snapshot(master_xid, txid_snapshot)
> > > this would allow us to use the txid_snapshot values
On Fri, 2008-01-11 at 15:05 -0500, Tom Lane wrote:
> the whole thing gives me the willies.
Me too :-)
> > What I'm thinking about is how we might use this to have multiple
> > sessions working simultaneously on tasks like unloading data,
>
> Then what you want is a function that says "clone the
>
> The user isn't going to have any legal way to transfer the data between
> backends anyway, since no transaction can see results of an uncommitted
> other transaction. There *has* to be some backdoor channel involved
> there, and you might as well make it carry the data without the user
> touch
Simon Riggs <[EMAIL PROTECTED]> writes:
> If we had a function
> replace_serializable_snapshot(master_xid, txid_snapshot)
> this would allow us to use the txid_snapshot values to replace our
> transaction's serializable snapshot.
... whereupon we'd get wrong answers. Certainly you could no
28 matches
Mail list logo
