Re: Parallel safety of binary_upgrade_create_empty_extension - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Parallel safety of binary_upgrade_create_empty_extension
Date
Msg-id 12685.1522445181@sss.pgh.pa.us
Whole thread Raw
In response to Re: Parallel safety of binary_upgrade_create_empty_extension  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Parallel safety of binary_upgrade_create_empty_extension
Next
From: Jeremy Finzel
Date:
Subject: Passing current_database to BackgroundWorkerInitializeConnection