| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Andreas Karlsson <andreas(at)proxel(dot)se>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Parallel safety tagging of extension functions |
| Date: | 2016-05-23 17:22:09 |
| Message-ID: | 619.1464024129@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> Tom Lane wrote:
>> You'd have to alter the index opfamily to disconnect the function from it,
>> drop/recreate the function, then re-add it to the opfamily. Kind of icky,
>> but probably better than the alternatives.
> What happens if the upgraded database contains indexes using those
> opfamilies? I suppose getting such indexes dropped because of ALTER
> EXTENSION UPDATE is not very nice.
Sure, that's why we mustn't drop and recreate the whole opfamily.
But we can do ALTER OPERATOR FAMILY ... DROP ... without causing
dependent indexes to be dropped. Semi-bad things would happen if
someone tried to access such an index partway through; but as long
as the extension upgrade script itself doesn't do that, it should
be okay. We run extension scripts as single transactions so the
change should appear atomic.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ryan Pedela | 2016-05-23 17:23:05 | Re: Calling json_* functions with JSONB data |
| Previous Message | David G. Johnston | 2016-05-23 17:14:55 | Re: Calling json_* functions with JSONB data |