Re: Parallel safety of binary_upgrade_create_empty_extension

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parallel safety of binary_upgrade_create_empty_extension
Date: 2018-03-30 21:26:21
Message-ID: 12685.1522445181@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> Anyway, that looks like 11 functions that there's no question we
> need to relabel. I'll go do that.

Oh, while I'm looking at this, I notice that cursor_to_xml[schema]
is not merely mismarked as to its parallel safety, but its volatility:
it's marked stable, which is frickin' insane considering it has side
effects on the state of the cursor.

query_to_xml* are likewise marked stable, which seems also foolish
since we have no idea whether the source query has side-effects.

All of this breakage is pretty old. I guess the best we can do is
fix it without a catversion bump in the back branches.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeremy Finzel 2018-03-30 21:36:59 Passing current_database to BackgroundWorkerInitializeConnection
Previous Message Tom Lane 2018-03-30 21:09:15 Re: Parallel safety of binary_upgrade_create_empty_extension