Re: pgsql: Handle lack of DSM slots in parallel btree build.

2020-02-04 Thread Thomas Munro
On Tue, Feb 4, 2020 at 10:03 AM Thomas Munro wrote: > On Tue, Feb 4, 2020 at 9:13 AM Peter Geoghegan wrote: > > Uh, this seems to have completely disabled parallel index builds on > > the master branch. > > Oops. The check needs to move down below InitializeParallelDSM(), and > release any extra

Re: pgsql: Handle lack of DSM slots in parallel btree build.

2020-02-04 Thread Peter Geoghegan
On Tue, Feb 4, 2020 at 2:18 AM Thomas Munro wrote: > Here is take 2. I tested CI and CIC, and verified that workers are > started or not depending on dsm_create() failure, using the attached > fault injector patch. (Fuzzing the regression tests repeatedly with > that applied also revealed simila

Re: pgsql: Handle lack of DSM slots in parallel btree build.

2020-02-04 Thread Peter Geoghegan
On Tue, Feb 4, 2020 at 9:42 AM Peter Geoghegan wrote: > Can we reuse _bt_end_parallel() this time around? It would be easy to > add a "bool wait" argument to _bt_end_parallel(). All existing callers > would pass true, but when not using parallelism due to the new DSM > segment check we'd pass fals

pgsql: Fix handling of "Subplans Removed" field in EXPLAIN output.

2020-02-04 Thread Tom Lane
Fix handling of "Subplans Removed" field in EXPLAIN output. Commit 499be013d added this field in a rather poorly-thought-through manner, with the result being that rather than being a field of the Append or MergeAppend plan node as intended (and as it seems to be, in text format), it was actually

pgsql: Fix handling of "Subplans Removed" field in EXPLAIN output.

2020-02-04 Thread Tom Lane
Fix handling of "Subplans Removed" field in EXPLAIN output. Commit 499be013d added this field in a rather poorly-thought-through manner, with the result being that rather than being a field of the Append or MergeAppend plan node as intended (and as it seems to be, in text format), it was actually

pgsql: Fix handling of "Subplans Removed" field in EXPLAIN output.

2020-02-04 Thread Tom Lane
Fix handling of "Subplans Removed" field in EXPLAIN output. Commit 499be013d added this field in a rather poorly-thought-through manner, with the result being that rather than being a field of the Append or MergeAppend plan node as intended (and as it seems to be, in text format), it was actually

pgsql: Handle lack of DSM slots in parallel btree build, take 2.

2020-02-04 Thread Thomas Munro
Handle lack of DSM slots in parallel btree build, take 2. Commit 74618e77 added a new check intended to fix a bug, but put it in the wrong place so that parallel btree build was always disabled. Do the check after we've actually tried to create a DSM segment. Back-patch to 11, like the earlier c

pgsql: Handle lack of DSM slots in parallel btree build, take 2.

2020-02-04 Thread Thomas Munro
Handle lack of DSM slots in parallel btree build, take 2. Commit 74618e77 added a new check intended to fix a bug, but put it in the wrong place so that parallel btree build was always disabled. Do the check after we've actually tried to create a DSM segment. Back-patch to 11, like the earlier c

pgsql: Handle lack of DSM slots in parallel btree build, take 2.

2020-02-04 Thread Thomas Munro
Handle lack of DSM slots in parallel btree build, take 2. Commit 74618e77 added a new check intended to fix a bug, but put it in the wrong place so that parallel btree build was always disabled. Do the check after we've actually tried to create a DSM segment. Back-patch to 11, like the earlier c

Re: pgsql: Handle lack of DSM slots in parallel btree build.

2020-02-04 Thread Thomas Munro
On Wed, Feb 5, 2020 at 6:47 AM Peter Geoghegan wrote: > On Tue, Feb 4, 2020 at 9:42 AM Peter Geoghegan wrote: > > Can we reuse _bt_end_parallel() this time around? It would be easy to > > add a "bool wait" argument to _bt_end_parallel(). All existing callers > > would pass true, but when not usin

Re: pgsql: Handle lack of DSM slots in parallel btree build.

2020-02-04 Thread Peter Geoghegan
On Tue, Feb 4, 2020 at 3:38 PM Thomas Munro wrote: > Thanks. Pushed. Thanks. -- Peter Geoghegan

pgsql: Add kqueue(2) support to the WaitEventSet API.

2020-02-04 Thread Thomas Munro
Add kqueue(2) support to the WaitEventSet API. Use kevent(2) to wait for events on the BSD family of operating systems and macOS. This is similar to the epoll(2) support added for Linux by commit 98a64d0bd. Author: Thomas Munro Reviewed-by: Andres Freund, Marko Tiikkaja, Tom Lane Tested-by: Mate

pgsql: Add note about how each partition's default value is treated, in

2020-02-04 Thread Fujii Masao
Add note about how each partition's default value is treated, into the doc. Column defaults may be specified separately for each partition. But INSERT via a partitioned table ignores those partition's default values. The former is documented, but the latter restriction not. This commit adds the no

pgsql: Add note about how each partition's default value is treated, in

2020-02-04 Thread Fujii Masao
Add note about how each partition's default value is treated, into the doc. Column defaults may be specified separately for each partition. But INSERT via a partitioned table ignores those partition's default values. The former is documented, but the latter restriction not. This commit adds the no

pgsql: Add note about how each partition's default value is treated, in

2020-02-04 Thread Fujii Masao
Add note about how each partition's default value is treated, into the doc. Column defaults may be specified separately for each partition. But INSERT via a partitioned table ignores those partition's default values. The former is documented, but the latter restriction not. This commit adds the no