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 co
I wrote:
> Thomas Munro writes:
>> Presumably also cursor_to_xmlschema. I also found some more
>> suspicious brin and gin modifying functions. So I think the list of
>> functions that needs to be marked 'u' so far is:
>> * binary_upgrade_create_empty_extension
>> * pg_import_system_collations
>
Thomas Munro writes:
> Presumably also cursor_to_xmlschema. I also found some more
> suspicious brin and gin modifying functions. So I think the list of
> functions that needs to be marked 'u' so far is:
> * binary_upgrade_create_empty_extension
> * pg_import_system_collations
> * brin_summariz
On Wed, Mar 28, 2018 at 6:18 AM, Robert Haas wrote:
> On Tue, Mar 27, 2018 at 11:17 AM, Tom Lane wrote:
>> regression=# create sequence s1;
>> CREATE SEQUENCE
>> regression=# begin;
>> BEGIN
>> regression=# set force_parallel_mode to 1;
>> SET
>> regression=# declare c cursor for select nextval('
On Tue, Mar 27, 2018 at 11:17 AM, Tom Lane wrote:
> So, your proposal is to do nothing and just hope we don't make the same
> mistake again in future?
That wasn't really my proposal, but if it were, it would be at least
as good as your proposal of making changing things in an unprincipled
fashion
Robert Haas writes:
> On Mon, Mar 26, 2018 at 7:23 PM, Tom Lane wrote:
>> While the minimal patch would be fine for now, what I'm worried about
>> is preventing future mistakes. It seems highly likely that the reason
>> binary_upgrade_create_empty_extension is marked 'r' is that somebody
>> copi
On Mon, Mar 26, 2018 at 7:23 PM, Tom Lane wrote:
> While the minimal patch would be fine for now, what I'm worried about
> is preventing future mistakes. It seems highly likely that the reason
> binary_upgrade_create_empty_extension is marked 'r' is that somebody
> copied-and-pasted that from ano
On Tue, Mar 27, 2018 at 3:30 PM, Thomas Munro
wrote:
> I hacked something up in Python
# otool -tvV | \
In case anyone is interested in trying that, it should be "otool -tvV
[path to postgres executable compiled with -O0]" (meaning disassemble
it). I was removing my home directory from the pa
On Tue, Mar 27, 2018 at 12:23 PM, Tom Lane wrote:
> Querying for other functions marked 'r' leaves me with some other related
> doubts:
>
> 1. Why are the various flavors of pg_get_viewdef() marked 'r'? Surely
> reading the catalogs is a thing parallel children are allowed to do.
> If there is a
Thomas Munro writes:
> On Tue, Mar 27, 2018 at 11:58 AM, Tom Lane wrote:
>> I wonder whether we shouldn't mark *all* of these parallel-unsafe.
>> I'm not exactly convinced that 'restricted' is sufficient for the
>> others, and even if it is, there's certainly little if any upside
>> for letting t
On Tue, Mar 27, 2018 at 11:58 AM, Tom Lane wrote:
> # select proname, proparallel from pg_proc where proname like 'binary_upg%';
> proname | proparallel
> +-
> binary_upgrade_create_empty_extension |
... BTW:
# select proname, proparallel from pg_proc where proname like 'binary_upg%';
proname | proparallel
+-
binary_upgrade_create_empty_extension | r
binary_upgrade_set_next_array_pg_type_oid |
Thomas Munro writes:
> Here's a single character patch to mark
> that function PARALLEL UNSAFE.
Ugh. Clearly a bug.
> Obviously that'll affect only newly
> initdb'd clusters after this patch, but that's what people have in a
> pg_upgrade scenario.
We're a bit fortunate on that. I wonder if th
Hi,
My colleague Richard Yen came across this situation:
pg_restore: [archiver (db)] could not execute query: ERROR: cannot
assign XIDs during a parallel operation
Command was: -- For binary upgrade, create an empty extension and
insert objects into it
DROP EXTENSION IF EXISTS "btree_gin";
S
14 matches
Mail list logo
