Re: a raft of parallelism-related bug fixes - Mailing list pgsql-hackers

On Mon, Oct 12, 2015 at 1:04 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> Attached are 14 patches.  Patches #1-#4 are
> essential for testing purposes but are not proposed for commit,
> although some of the code they contain may eventually become part of
> other patches which are proposed for commit.  Patches #5-#12 are
> largely boring patches fixing fairly uninteresting mistakes; I propose
> to commit these on an expedited basis.  Patches #13-14 are also
> proposed for commit but seem to me to be more in need of review.

Hearing no objections, I've now gone and committed #5-#12.

> 0013-Modify-tqueue-infrastructure-to-support-transient-re.patch
> attempts to address a deficiency in the tqueue.c/tqueue.h machinery I
> recently introduced: backends can have ephemeral record types for
> which they use backend-local typmods that may not be the same between
> the leader and the worker.  This patch has the worker send metadata
> about the tuple descriptor for each such type, and the leader
> registers the same tuple descriptor and then remaps the typmods from
> the worker's typmod space to its own.  This seems to work, but I'm a
> little concerned that there may be cases it doesn't cover.  Also,
> there's room to question the overall approach.  The only other
> alternative that springs readily to mind is to try to arrange things
> during the planning phase so that we never try to pass records between
> parallel backends in this way, but that seems like it would be hard to
> code (and thus likely to have bugs) and also pretty limiting.

I am still hoping someone will step up to review this.

> 0014-Fix-problems-with-ParamListInfo-serialization-mechan.patch, which
> I just posted on the Parallel Seq Scan thread as a standalone patch,
> fixes pretty much what the name of the file suggests.  This actually
> fixes two problems, one of which Noah spotted and commented on over on
> that thread.  By pure coincidence, the last 'make check' regression
> failure I was still troubleshooting needed a fix for that issue plus a
> fix to plpgsql_param_fetch.  However, as I mentioned on the other
> thread, I'm not quite sure which way to go with the change to
> plpgsql_param_fetch so scrutiny of that point, in particular, would be
> appreciated.  See also
> http://www.postgresql.org/message-id/CA+TgmobN=wADVaUTwsH-xqvCdovkeRasuXw2k3R6vmpWig7raw@mail.gmail.com

Noah's been helping with this issue on the other thread.  I'll revise
this patch along the lines discussed there and resubmit.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company