Re: pgsql: Optimize btree insertions for common case of increasing values

On Tue, Apr 10, 2018 at 3:37 PM, Andrew Dunstan wrote: >> The comments still say "Check if the page...no split is in progress". >> Despite the fact that that's just an assertion now. >> > > Fixed. Thanks. -- Peter Geoghegan

Re: pgsql: Optimize btree insertions for common case of increasing values

On 04/10/2018 06:33 PM, Peter Geoghegan wrote: > On Tue, Apr 10, 2018 at 3:27 PM, Andrew Dunstan wrote: >> Committed with light editing. I didn't put the #define in the .h file - >> it's only used here and that seemed like unnecessary clutter. I moved it >> to the top of

pgsql: minor comment fixes in nbtinsert.c

minor comment fixes in nbtinsert.c Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8716b264ed845370e33943da93caf424dc3723b7 Modified Files -- src/backend/access/nbtree/nbtinsert.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-)

pgsql: Fix incorrect close() call in dsm_impl_mmap().

Fix incorrect close() call in dsm_impl_mmap(). One improbable error-exit path in this function used close() where it should have used CloseTransientFile(). This is unlikely to be hit in the field, and I think the consequences wouldn't be awful (just an elog(LOG) bleat later). But a bug is a

pgsql: Fix incorrect close() call in dsm_impl_mmap().

Fix incorrect close() call in dsm_impl_mmap(). One improbable error-exit path in this function used close() where it should have used CloseTransientFile(). This is unlikely to be hit in the field, and I think the consequences wouldn't be awful (just an elog(LOG) bleat later). But a bug is a

pgsql: Fix incorrect close() call in dsm_impl_mmap().

Fix incorrect close() call in dsm_impl_mmap(). One improbable error-exit path in this function used close() where it should have used CloseTransientFile(). This is unlikely to be hit in the field, and I think the consequences wouldn't be awful (just an elog(LOG) bleat later). But a bug is a

pgsql: Fix incorrect close() call in dsm_impl_mmap().

Fix incorrect close() call in dsm_impl_mmap(). One improbable error-exit path in this function used close() where it should have used CloseTransientFile(). This is unlikely to be hit in the field, and I think the consequences wouldn't be awful (just an elog(LOG) bleat later). But a bug is a

pgsql: Fix incorrect close() call in dsm_impl_mmap().

Fix incorrect close() call in dsm_impl_mmap(). One improbable error-exit path in this function used close() where it should have used CloseTransientFile(). This is unlikely to be hit in the field, and I think the consequences wouldn't be awful (just an elog(LOG) bleat later). But a bug is a

Re: pgsql: Optimize btree insertions for common case of increasing values

On Tue, Apr 10, 2018 at 3:27 PM, Andrew Dunstan wrote: > Committed with light editing. I didn't put the #define in the .h file - > it's only used here and that seemed like unnecessary clutter. I moved it > to the top of the file. I also standardized the spelling of

Re: pgsql: Optimize btree insertions for common case of increasing values

On 04/10/2018 03:30 PM, Peter Geoghegan wrote: > On Tue, Apr 10, 2018 at 12:07 PM, Pavan Deolasee > wrote: >> Hmm. I am a bit confused why we want to mention anything about something >> we're not even considering seriously, let alone any patch or work in that >>

pgsql: Adjustments to the btree fastpath optimization.

Adjustments to the btree fastpath optimization. This optimization was introduced in commit 2b272734. The changes include some additional comments and documentation, and also these more substantive changes: . ensure the optimization is only applied on the leaf node of a tree whose root is on level

pgsql: Put back parallel-safety guards in plpython and src/test/regress

Put back parallel-safety guards in plpython and src/test/regress/. I'd hoped that commit 3b8f6e75f was sufficient to ensure parallel safety even when a build started in a subdirectory requires rebuilding of generated headers. This isn't so, because making submake-generated-headers a prerequisite

Re: pgsql: Optimize btree insertions for common case of increasing values

On Tue, Apr 10, 2018 at 12:30 PM, Peter Geoghegan wrote: >> Apart from that, other changes requested are included in the patch. This >> also takes care of Heikki's observation regarding UNLOGGED tables on the >> other thread. > > Cool. BTW, Heikki's commit didn't remove the "no

Re: pgsql: Optimize btree insertions for common case of increasing values

On Tue, Apr 10, 2018 at 12:07 PM, Pavan Deolasee wrote: > Hmm. I am a bit confused why we want to mention anything about something > we're not even considering seriously, let alone any patch or work in that > direction. If we at all change everything to use extent based

Re: pgsql: Optimize btree insertions for common case of increasing values

On Tue, Apr 10, 2018 at 1:18 AM, Peter Geoghegan wrote: > On Thu, Apr 5, 2018 at 10:16 AM, Peter Geoghegan wrote: > > I think you can take that wording almost verbatim. Obviously it should > > refer to the optimization by name, and blend into the surrounding text > >

pgsql: Fix IndexOnlyScan counter for heap fetches in parallel mode

Fix IndexOnlyScan counter for heap fetches in parallel mode The HeapFetches counter was using a simple value in IndexOnlyScanState, which fails to propagate values from parallel workers; so the counts are wrong when IndexOnlyScan runs in parallel. Move it to Instrumentation, like all the other

pgsql: Fix pgxs.mk to not try to build generated headers in external bu

Fix pgxs.mk to not try to build generated headers in external builds. Per Julien Rouhaud and the buildfarm. This is not quite Julien's patch: there's no need to lobotomize this build rule when building contrib modules in-tree, so set NO_GENERATED_HEADERS only if PGXS. In passing, also set

Re: pgsql: Fix comment on B-tree insertion fastpath condition.

On Tue, Apr 10, 2018 at 7:28 PM, Heikki Linnakangas < heikki.linnakan...@iki.fi> wrote: > Fix comment on B-tree insertion fastpath condition. > > The comment earlier in the function correctly states "and the insertion > key is strictly greater than the first key in this page". That is what > we

pgsql: Fix comment on B-tree insertion fastpath condition.

Fix comment on B-tree insertion fastpath condition. The comment earlier in the function correctly states "and the insertion key is strictly greater than the first key in this page". That is what we check here, not "greater than or equal". Branch -- master Details ---

Re: pgsql: Fix behavior of ~> (cube, int) operator

Pushed, thank you Alexander Korotkov wrote: On Sun, Jan 21, 2018 at 11:20 PM, Tom Lane > wrote: Teodor Sigaev > writes: > Fix behavior of ~> (cube, int) operator This patch has caused

pgsql: Remove wrongly backpatched piece of code in cube.c

Remove wrongly backpatched piece of code in cube.c Due to sloppy division of changes between f50c80dbb (which was not back-patched) and 563a053bd, this piece of code was wrongly backpatched to REL_10_STABLE and REL9_6_STABLE. This code never causes real error because its condition is never

pgsql: Remove wrongly backpatched piece of code in cube.c

Remove wrongly backpatched piece of code in cube.c Due to sloppy division of changes between f50c80dbb (which was not back-patched) and 563a053bd, this piece of code was wrongly backpatched to REL_10_STABLE and REL9_6_STABLE. This code never causes real error because its condition is never

Re: pgsql: Fix behavior of ~> (cube, int) operator

inverse variable becomes unused, will remove Alexander Korotkov wrote: Seems to be due to sloppy division of changes between f50c80dbb (which was not back-patched) and 563a053bd.  Please fix. Thank you for catching this.  You diagnosis is right. I propose to commit the attached patch

Re: pgsql: Fix behavior of ~> (cube, int) operator

On Sun, Jan 21, 2018 at 11:20 PM, Tom Lane wrote: > Teodor Sigaev writes: > > Fix behavior of ~> (cube, int) operator > > This patch has caused Coverity to complain, correctly AFAICS, about > dead code in cube_coord_llur in the back branches: > > 1628