On Jan 29, 2007, at 11:28 PM, Tom Lane wrote:
Jim Nasby <[EMAIL PROTECTED]> writes:
On Jan 26, 2007, at 4:48 PM, Tom Lane wrote:
I don't actually see that it buys you a darn thing ... you still
won't
be able to delete dead updated tuples because of the possibility of
the LRT deciding to chase
Jim Nasby <[EMAIL PROTECTED]> writes:
> On Jan 26, 2007, at 4:48 PM, Tom Lane wrote:
>> I don't actually see that it buys you a darn thing ... you still won't
>> be able to delete dead updated tuples because of the possibility of
>> the LRT deciding to chase ctid chains up from the tuples it can
On Jan 26, 2007, at 4:48 PM, Tom Lane wrote:
"Simon Riggs" <[EMAIL PROTECTED]> writes:
You got me. My description was too loose, but you also got the rough
picture. We'll save the detail for another day, but we all know its a
bridge we will have to cross one day, soon. I wasn't meaning to raise
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> You got me. My description was too loose, but you also got the rough
> picture. We'll save the detail for another day, but we all know its a
> bridge we will have to cross one day, soon. I wasn't meaning to raise
> this specific discussion now, just to sa
On Fri, 2007-01-26 at 12:43 -0500, Jan Wieck wrote:
> There is a flaw in that theory. If you have a single LTR, then each
> subsequent transactions xmin will be exactly that one, no?
You got me. My description was too loose, but you also got the rough
picture. We'll save the detail for another d
On 1/26/2007 11:58 AM, Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
On 1/26/2007 8:06 AM, Gregory Stark wrote:
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 y
On 1/26/2007 12:22 PM, Simon Riggs wrote:
On Fri, 2007-01-26 at 11:36 -0500, Tom Lane wrote:
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> No, that would break MVCC. But we may have done lots of updates/deletes
> that are *not* visible to any Snapshot, yet are not yet removable
> because they are
"Tom Lane" <[EMAIL PROTECTED]> writes:
>>> set_current_snapshot() would have to sanity check that the xmin of the new
>>> snapshot isn't older than the current globaloldestxmin.
>
>> That would solve the backend to backend IPC problem nicely.
>
> But it fails on the count of making sure that glob
On Fri, 2007-01-26 at 11:36 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > No, that would break MVCC. But we may have done lots of updates/deletes
> > that are *not* visible to any Snapshot, yet are not yet removable
> > because they are higher than OldestXmin but we don't k
Jan Wieck <[EMAIL PROTECTED]> writes:
> On 1/26/2007 8:06 AM, Gregory Stark wrote:
>> 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-ba
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Ãhel kenal päeval, N, 2007-01-25 kell 22:19, kirjutas Jan Wieck:
>> The cloning process needs to make sure that the clone_snapshot() call is
>> made from the same DB user in the same database as corresponding
>> publish_snapshot() call was done.
> W
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> No, that would break MVCC. But we may have done lots of updates/deletes
> that are *not* visible to any Snapshot, yet are not yet removable
> because they are higher than OldestXmin but we don't know that because
> previously the Snapshot details were not
[EMAIL PROTECTED] (Gregory Stark) writes:
> "Jan Wieck" <[EMAIL PROTECTED]> writes:
>
>> backend1: select publish_snapshot(); -- will block
>>
>> backend2: start transaction;
>> backend2: set transaction isolation level serializable;
>> backend2: select clone_snapshot(); -- will unb
On Fri, 2007-01-26 at 16:09 +0200, Hannu Krosing wrote:
> Ühel kenal päeval, R, 2007-01-26 kell 12:25, kirjutas Simon Riggs:
> > Great idea. It can also be used by pg_dump to publish its snapshot so
> > that we can make VACUUM continue to process effectively while it pg_dump
> > is running.
>
> D
On Fri, 2007-01-26 at 16:09 +0200, Hannu Krosing wrote:
> Ühel kenal päeval, R, 2007-01-26 kell 12:25, kirjutas Simon Riggs:
> > Two questions:
> > - why does it have to block? I don't see any reason - the first process
> > can begin doing useful work. The second process might fail or itself be
>
Ühel kenal päeval, R, 2007-01-26 kell 12:25, kirjutas Simon Riggs:
> On Thu, 2007-01-25 at 22:19 -0500, Jan Wieck wrote:
>
> > The idea is to clone an existing serializable transactions snapshot
> > visibility information from one backend to another. The semantics would
> > be like this:
> >
>
On 1/26/2007 8:06 AM, Gregory Stark wrote:
"Jan Wieck" <[EMAIL PROTECTED]> writes:
backend1: select publish_snapshot(); -- will block
backend2: start transaction;
backend2: set transaction isolation level serializable;
backend2: select clone_snapshot(); -- will unblock backend1
"Jan Wieck" <[EMAIL PROTECTED]> writes:
> backend1: select publish_snapshot(); -- will block
>
> backend2: start transaction;
> backend2: set transaction isolation level serializable;
> backend2: select clone_snapshot(); -- will unblock backend1
It seems simpler to have a current_
On Thu, 2007-01-25 at 22:19 -0500, Jan Wieck wrote:
> The idea is to clone an existing serializable transactions snapshot
> visibility information from one backend to another. The semantics would
> be like this:
>
> backend1: start transaction;
> backend1: set transaction isolation le
Ühel kenal päeval, N, 2007-01-25 kell 22:19, kirjutas Jan Wieck:
> Granted this one has a few open ends so far and I'd like to receive some
> constructive input on how to actually implement it.
>
> The idea is to clone an existing serializable transactions snapshot
> visibility information from
Granted this one has a few open ends so far and I'd like to receive some
constructive input on how to actually implement it.
The idea is to clone an existing serializable transactions snapshot
visibility information from one backend to another. The semantics would
be like this:
backend1:
21 matches
Mail list logo
