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
20 matches
Mail list logo
