The tuple toaster currently fetches toast-table rows using SnapshotAny.
This is quite uncool, because it will in fact find *any* row.  Including
dead rows resulting from an aborted (or, in 7.2, still-in-progress)
VACUUM.

I believe this is the explanation for a problem report I'm currently
chasing from Joshua Drake:

digivision2=# select * from change_log;
ERROR:  chunk 1 for toast value 3388774 appears multiple times

(there are some thousands of rows with similar problems)

I suggest SnapshotSelf instead.  Comments anyone?

			regards, tom lane

Tue, 15 Jan 2002 18:46:48 -0500
Tom Lane <tgl@sss.pgh.pa.us>
tuptoaster.c must *not* use SnapshotAny
"Command Prompt, Inc." <pgsql-hackers@commandprompt.com> writes:
> Josh Drake here: Although I know that development has pretty much ceased
> on the 7.1 series. This bug, is potentially very serious for those who
> have the problem.

Well, based on our experiments last night, recovery is pretty simple:
vacuum the affected table.  So it doesn't qualify as a critical problem
in my eyes, although surely it's a "must fix" for 7.2.

> The last time this came up (that I can find) is in August of 2001, so the
> bug is not frequent that we are aware of. However, as it appears the fix
> is simple should we apply a 7.1.3.1 or 7.1.4 that fixes this issue?

I don't think anyone has the energy to put out a 7.1.4.  We seem to have
enough trouble getting 7.2 out the door.

			regards, tom lane

Wed, 16 Jan 2002 12:10:52 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: tuptoaster.c must *not* use SnapshotAny 

Josh Drake here: Although I know that development has pretty much ceased
on the 7.1 series. This bug, is potentially very serious for those who
have the problem.

The last time this came up (that I can find) is in August of 2001, so the
bug is not frequent that we are aware of. However, as it appears the fix
is simple should we apply a 7.1.3.1 or 7.1.4 that fixes this issue?


J


> On Tue, 15 Jan 2002, Tom Lane wrote:

> The tuple toaster currently fetches toast-table rows using SnapshotAny.
> This is quite uncool, because it will in fact find *any* row.  Including
> dead rows resulting from an aborted (or, in 7.2, still-in-progress)
> VACUUM.
>
> I believe this is the explanation for a problem report I'm currently
> chasing from Joshua Drake:
>
> digivision2=# select * from change_log;
> ERROR:  chunk 1 for toast value 3388774 appears multiple times
>
> (there are some thousands of rows with similar problems)
>
> I suggest SnapshotSelf instead.  Comments anyone?
>
> 			regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>

-- 
by way of pgsql-hackers@commandprompt.com


Wed, 16 Jan 2002 09:46:32 -0800 (PST)
"Command Prompt, Inc." <pgsql-hackers@commandprompt.com>
Re: tuptoaster.c must *not* use SnapshotAny
Tom Lane wrote:
> The tuple toaster currently fetches toast-table rows using SnapshotAny.
> This is quite uncool, because it will in fact find *any* row.  Including
> dead rows resulting from an aborted (or, in 7.2, still-in-progress)
> VACUUM.

    Really?  So  what  you're  saying  means that while vacuum is
    running there's a window where one tuple can  exist  multiple
    times  and  just  the  fact  that  other backends can see the
    vacuum transaction alive prevents them from showing up?  That
    doesn't sound really good to me.


Jan

>
> I believe this is the explanation for a problem report I'm currently
> chasing from Joshua Drake:
>
> digivision2=# select * from change_log;
> ERROR:  chunk 1 for toast value 3388774 appears multiple times
>
> (there are some thousands of rows with similar problems)
>
> I suggest SnapshotSelf instead.  Comments anyone?
>
>              regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>


--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


Wed, 16 Jan 2002 13:16:40 -0500 (EST)
Jan Wieck <janwieck@yahoo.com>
Re: tuptoaster.c must *not* use SnapshotAny
Jan Wieck <janwieck@yahoo.com> writes:
>     Really?  So  what  you're  saying  means that while vacuum is
>     running there's a window where one tuple can  exist  multiple
>     times

Moving a tuple in VACUUM isn't fundamentally different from an UPDATE.
You need a visibility rule to tell you which version of the tuple to
pay attention to.  Right now, TOAST hasn't got one.

Per later discussion, Andreas is right that SnapshotSelf won't do.
I think we need a new tqual.c routine just for TOAST.  (The alternative
would be for TOAST to know which snapshot was used to find the main-
table tuple, but that doesn't seem workable.)

			regards, tom lane

Wed, 16 Jan 2002 13:30:30 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: tuptoaster.c must *not* use SnapshotAny 