From: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Fast default stuff versus pg_upgrade |
Date: | 2018-06-20 16:51:07 |
Message-ID: | 80b23436-385c-70b4-3e61-6412f6011f09@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 06/19/2018 10:46 PM, Andres Freund wrote:
> On 2018-06-19 22:41:26 -0400, Andrew Dunstan wrote:
>> This unfortunately crashes and burns if we use DirectFunctionCall3 to call
>> array_in, because it uses fn_extra. There is the CallerFInfoFunctionCall
>> stuff, but it only has 1 and 2 arg variants, and array_in takes 3. In
>> retrospect we should probably have added a 3 arg form - quite a few input
>> functions take 3 args. Anything else is likely to be rather uglier.
>>
>> Attaching the failing patch. I'll attack this again in the morning.
> Why don't you just use OidFunctionCall3? Or simply an explicit
> fmgr_info(), InitFunctionCallInfoData(), FunctionCallInvoke() combo?
>
Thanks for that. I should not code late at night.
Here's a version that works in my testing with Tom's patch making sure
there's a missing value to migrate applied. Thanks to Alvaro for some
useful criticism - any errors are of course my responsibility.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment | Content-Type | Size |
---|---|---|
fix-default-3.patch | text/x-patch | 10.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Khandekar | 2018-06-20 16:52:29 | Re: AtEOXact_ApplyLauncher() and subtransactions |
Previous Message | Andres Freund | 2018-06-20 16:42:59 | Re: Avoiding Tablespace path collision for primary and standby |