| From: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
|---|---|
| To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
| Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: crash with sql language partition support function |
| Date: | 2018-04-10 13:21:40 |
| Message-ID: | CAFjFpRdOGmj5XVBr3PrPVfQ2wU=A1WOiLwcgA3hZCnmEAz3d2Q@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Apr 10, 2018 at 1:44 PM, Amit Langote
<Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>
> Attached fixes it. It teaches RelationBuildPartitionKey() to use
> fmgr_info_cxt and pass rd_partkeycxt to it.
The patch is using partkeycxt and not rd_partkeycxt. Probably a typo
in the mail. But a wider question, why that context? I guess that
cache context will vanish when that cache entry is thrown away. That's
the reason we have to copy partition key information in
find_partition_scheme() instead of just pointing to it and also use
fmgr_info_copy() there. But if that's the case, buildfarm animal run
with -DCLOBBER_CACHE_ALWAYS should show failure. I am missing
something here.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Steele | 2018-04-10 13:23:45 | Re: [HACKERS] logical decoding of two-phase transactions |
| Previous Message | Alvaro Herrera | 2018-04-10 13:17:42 | Re: [PATCH][PROPOSAL] Refuse setting toast.* reloptions when TOAST table does not exist |