| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
| Cc: | shihao zhong <zhong950419(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Guofenglinux <guofenglinux(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Subject: | Re: [PG19] eager aggregation gives wrong results because of bpchar_ops |
| Date: | 2026-10-06 23:41:33 |
| Message-ID: | 1714677.1791330093@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> On Tue, Oct 6, 2026 at 7:35 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> However, even once that updates, we're going to have some problems.
>> Trying it locally, I see my animal complaining about updates from
>> REL_13_STABLE failing, which is unsurprising ... but how do we get
>> v13-or-before data into a shape that the patched code will accept?
> By backpatching to REL_13_STABLE? I see no other reasonable way, given
> the constraints.
That was my first reaction too, but then what are we testing?
Nothing corresponding to real-world upgrades.
Maybe we need to hot-wire the BF script to not run amcheck in these
upgrades from ancient versions.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2026-10-06 23:49:16 | Re: [PG19] eager aggregation gives wrong results because of bpchar_ops |
| Previous Message | Peter Geoghegan | 2026-10-06 23:37:57 | Re: [PG19] eager aggregation gives wrong results because of bpchar_ops |