| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, kes-kes(at)yandex(dot)ru |
| Subject: | Re: mark/restore failures on unsorted merge joins |
| Date: | 2020-11-24 18:33:30 |
| Message-ID: | 293167.1606242810@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2020-11-24 18:35:28 | Re: libpq compression |
| Previous Message | Tomas Vondra | 2020-11-24 18:26:55 | Re: [PoC] Non-volatile WAL buffer |