From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: parallel mode and parallel contexts |
Date: | 2015-01-07 20:54:06 |
Message-ID: | 54AD9CEE.9000601@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 1/7/15, 9:39 AM, Robert Haas wrote:
>> sequence.c: Is it safe to read a sequence value in a parallel worker if the
>> >cache_value is > 1?
> No, because the sequence cache isn't synchronized between the workers.
> Maybe it would be safe if cache_value == 1, but there's not much
> use-case: how often are you going to have a read-only query that uses
> a sequence value. At some point we can look at making sequences
> parallel-safe, but worrying about it right now doesn't seem like a
> good use of time.
Agreed, I was more concerned with calls to nextval(), which don't seem to be prevented in parallel mode?
>> >This may be a dumb question, but for functions do we know that all pl's
>> >besides C and SQL use SPI? If not I think they could end up writing in a
>> >worker.
> Well, the lower-level checks would catch that. But it is generally
> true that there's no way to prevent arbitrary C code from doing things
> that are unsafe in parallel mode and that we can't tell are unsafe.
> As I've said before, I think that we'll need to have a method of
> labeling functions as parallel-safe or not, but this patch isn't
> trying to solve that part of the problem.
I was more thinking about all the add-on pl's like pl/ruby. But yeah, I don't see that there's much we can do if they're not using SPI.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
From | Date | Subject | |
---|---|---|---|
Next Message | Arthur Silva | 2015-01-07 21:26:10 | Re: VODKA? |
Previous Message | Stephen Frost | 2015-01-07 20:26:22 | Re: INSERT ... ON CONFLICT UPDATE and RLS |