Hello Tom, Martijn and List,
Thank you for yours answers !
This point is now closed for me and I can go further in the mecanisms of
VACUUM.
Regards,
Alexandra
Tom Lane wrote:
DANTE Alexandra <[EMAIL PROTECTED]> writes:
- during a SELECT query on a tuple just updated and commited, doe
DANTE Alexandra <[EMAIL PROTECTED]> writes:
> - during a SELECT query on a tuple just updated and commited, does
> the executor first detect the old tuple and then via the c_tid link go
> to the new version of the tuple ? or go directly to the new version ?
Neither. SELECT doesn't care abou
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> I don't get it. EPQ would need to reevaluate the plan of the _select_
> belonging to the _cursor_, not the plan of the _update_, to prevent
> the effect outlined above. Are you suggesting to use EPQ for that?
Yes, I don't think you have much choice
Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
I can see how the EPQ machinery can be used to chain forward to the
correct row to be updated, even if I originally found an older version
(e.g. by searching for a specific ctid). But for non-"for
update"-cursors, the newest version
Hello Martijn, hello List,
Last question on this subject, what's happened during a SELECT query on
a tuple just updated and commited ?
I followed in the source code the links between these methods :
CreateQueryDesc, ExecutorStart, ExecutorRun, ExecutePlan, ExecSelect but
I still have a questio
Martijn van Oosterhout writes:
> On Mon, Jul 31, 2006 at 11:04:58AM +0200, DANTE Alexandra wrote:
>> I've just seen that I've done a mistake in my example. My question was :
>> is it correct to think that the ctid of the old version of the tuple is
>> a link to newer version ?
> Well, in your cas
Martijn van Oosterhout writes:
> Looks like a good plan, but I think you've overlooked something: if
> you've locked the tuple FOR UPDATE then by definition there cannot be a
> newer version, right?
Nope --- think self-update.
regards, tom lane
--
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> I can see how the EPQ machinery can be used to chain forward to the
> correct row to be updated, even if I originally found an older version
> (e.g. by searching for a specific ctid). But for non-"for
> update"-cursors, the newest version of the ro
Martijn van Oosterhout wrote:
On Mon, Jul 31, 2006 at 01:47:41AM +0200, Florian G. Pflug wrote:
I agree, at least for "for-update"-cursors. If the cursor was not
declared "for update", then it is not even cleaer to me what the
correct behaviour would be. Imagine that you declared a cursor, and f
On Mon, Jul 31, 2006 at 11:04:58AM +0200, DANTE Alexandra wrote:
> I've just seen that I've done a mistake in my example. My question was :
> is it correct to think that the ctid of the old version of the tuple is
> a link to newer version ? In my example, is it correct to think that the
> tuple
Hello Martijn, hello List,
Thank you very much.
I still have some questions, further to your answers :
Martijn van Oosterhout wrote:
On Fri, Jul 28, 2006 at 12:00:19PM +0200, DANTE Alexandra wrote:
Hello List,
I try to understand perfectly the mecanisms used to update / delete a
tuple (a
On Mon, Jul 31, 2006 at 01:47:41AM +0200, Florian G. Pflug wrote:
> I agree, at least for "for-update"-cursors. If the cursor was not
> declared "for update", then it is not even cleaer to me what the
> correct behaviour would be. Imagine that you declared a cursor, and fetched
> a row. After fetch
Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
Martijn van Oosterhout wrote:
It's the t_ctid field of the tuple header. But I don't see what that
has to do with "WHERE CURRENT OF". That expression should return the
tuple visible to your transaction, not some updated version whic
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> Martijn van Oosterhout wrote:
>> It's the t_ctid field of the tuple header. But I don't see what that
>> has to do with "WHERE CURRENT OF". That expression should return the
>> tuple visible to your transaction, not some updated version which you
>>
Martijn van Oosterhout wrote:
On Sun, Jul 30, 2006 at 04:37:26PM +0200, Florian G. Pflug wrote:
Martijn van Oosterhout wrote:
The word "become" is not really right. The old version has become
invisible to you and the new version is visible. Some other
transactions will see the old one, some the
On Sun, Jul 30, 2006 at 04:37:26PM +0200, Florian G. Pflug wrote:
> Martijn van Oosterhout wrote:
> >The word "become" is not really right. The old version has become
> >invisible to you and the new version is visible. Some other
> >transactions will see the old one, some the new one. However, ther
Martijn van Oosterhout wrote:
On Fri, Jul 28, 2006 at 12:00:19PM +0200, DANTE Alexandra wrote:
- is it correct to think that the ctid of the old version of the tuple
is a link to newer version ? In my example, is it correct to think that
the tuple :
140049|0 | (0,12) | 11 | IR
On Fri, Jul 28, 2006 at 12:00:19PM +0200, DANTE Alexandra wrote:
> Hello List,
>
> I try to understand perfectly the mecanisms used to update / delete a
> tuple (and consequently those used in VACUUM) and I've got some questions.
> I hope someone could answer these questions :
> - what are the
18 matches
Mail list logo
