|From:||Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>|
|To:||Pg Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||SERIALIZABLE with parallel query|
|Views:||Raw Message | Whole Thread | Download mbox|
Currently we don't generate parallel plans in SERIALIZABLE. What
problems need to be solved to be able to do that? I'm probably
steamrolling over a ton of subtleties and assumptions here, but it
occurred to me that a first step might be something like this:
1. Hand the leader's SERIALIZABLEXACT to workers.
2. Make sure that workers don't release predicate locks.
3. Make sure that the leader doesn't release predicate locks until
after the workers have finished accessing the leader's
SERIALIZABLEXACT. I think this is already the case.
See attached 5 minute hack. Need to audit predicate.c for cases where
MySerializableXact might be modified without suitable locking, and
probably sprinkle assertions all over the place that workers don't
reach certain places etc. I wonder what horrible things might happen
as a result of workers running with a SERIALIZABLEXACT that contains
the leader's vxid and other such things. I'd love to figure all this
out in time for one of the later CFs in this cycle. Any thoughts?
|Next Message||Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=||2016-11-08 21:56:43||Re: Re: [PATCH] Tab completion for ALTER TYPE … RENAME VALUE …|
|Previous Message||Robert Haas||2016-11-08 21:32:42||Re: Remove "Source Code" column from \df+ ?|