Re: mark/restore failures on unsorted merge joins
Tom Lane <tgl@sss.pgh.pa.us>
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
Date: 2020-11-24T18:33:30Z
Lists: pgsql-hackers
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
Commits
-
Properly check index mark/restore in ExecSupportsMarkRestore.
- 660b89928d18 14.0 landed
- 59ed45e278b7 9.5.25 landed
- 6402afd9865e 9.6.21 landed
- 321c87e5ca1a 10.16 landed
- 018e7d98dc15 11.11 landed
- ae5aa26dc39d 12.6 landed
- 6dda057043df 13.2 landed