From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Gierth <andrew@tao11.riddles.org.uk>
cc: pgsql-hackers@lists.postgresql.org, kes-kes@yandex.ru
Subject: Re: mark/restore failures on unsorted merge joins
In-reply-to: <87k0ua4p4u.fsf@news-spur.riddles.org.uk>
References: <87o8jn50be.fsf@news-spur.riddles.org.uk>
 <125707.1606161260@sss.pgh.pa.us> <87k0ua4p4u.fsf@news-spur.riddles.org.uk>
Comments: In-reply-to Andrew Gierth <andrew@tao11.riddles.org.uk>
	message dated "Tue, 24 Nov 2020 18:07:59 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <293166.1606242810.1@sss.pgh.pa.us>
Date: Tue, 24 Nov 2020 13:33:30 -0500
Message-ID: <293167.1606242810@sss.pgh.pa.us>
Precedence: bulk

Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>  Tom> Uh, why would you not just look to see if the ammarkpos/amrestrpos
>  Tom> fields are non-null?

> We don't (in the back branches) seem to have a pointer to the
> IndexAmRoutine handy, only the oid?

Oh, sorry, I misread your comment to be that you wanted to add a field
to IndexAmRoutine.  You're right, the real issue here is that
ExecSupportsMarkRestore lacks any convenient access to the needed info,
and we need to add a bool to IndexOptInfo to fix that.

I don't see any compelling reason why you couldn't add the field at
the end in the back branches; that's what we usually do to avoid
ABI breaks.  Although actually (counts fields...) it looks like
there's at least one pad byte after amcanparallel, so you could
add a bool there without any ABI consequence, resulting in a
reasonably natural field order in all branches.

			regards, tom lane