[HACKERS] !USE_WIDE_UPPER_LOWER compile errors in v10+

On Sat, Sep 16, 2017 at 03:33:53PM -0700, Peter Geoghegan wrote: > On a related note, am I the only one that finds it questionable that > str_tolower() has an "#ifdef USE_WIDE_UPPER_LOWER" block that itself > contains an "#ifdef USE_ICU" block? It seems like those two things > might get conflated

Re: [HACKERS] Assertion failure when the non-exclusive pg_stop_backup aborted.

On Thu, Sep 21, 2017 at 1:07 AM, Masahiko Sawada wrote: > The bug can happen in PostgreSQL 9.1 or higher that non-exclusive > backup has been introduced, so we should back-patch to the all > supported versions. There is a typo here right? Non-exclusive backups have been

Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization

On Wed, Sep 20, 2017 at 3:26 PM, Fabien COELHO wrote: > > Hello Masahiko-san, > > v14 applies, compiles and works. TAP tests provide good coverage. > > ISTM that you probably intended "\(.*\)" (actual parenthesis) instead of > "(.*)" (memorization) in the data generation

Re: [HACKERS] Page Scan Mode in Hash Index

On Thu, Sep 21, 2017 at 9:30 AM, Robert Haas wrote: > On Wed, Sep 20, 2017 at 11:43 AM, Ashutosh Sharma > wrote: >> Attached are the patches with above changes. Thanks. > > Thanks. I think that the comments and README changes in 0003 need >

Re: [HACKERS] Page Scan Mode in Hash Index

On Wed, Sep 20, 2017 at 11:43 AM, Ashutosh Sharma wrote: > Attached are the patches with above changes. Thanks. Thanks. I think that the comments and README changes in 0003 need significantly more work. In several places, they fail to note the unlogged vs. logged

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Tue, Sep 19, 2017 at 5:47 AM, Ashutosh Bapat wrote: > Done. Committed 0001 with extensive editorialization. I did not think it was a good idea to include a partition.h a file in src/include/nodes, so I worked around that. The include of pg_inherits_fn.h was

Re: [HACKERS] POC: Cache data in GetSnapshotData()

On Wed, Sep 20, 2017 at 10:32 PM, Andres Freund wrote: > Wonder how much of that is microarchitecture, how much number of sockets. I don't know. How would we tell? power2 is a 4-socket POWER box, and cthulhu is an 8-socket x64 box, so it's not like they are the same sort of

[HACKERS] Re: [BUGS] BUG #14821: idle_in_transaction_session_timeout sometimes gets ignored when statement timeout is pending

Hi, As per the bug report at https://www.postgresql.org/message-id/20170921010956.17345.61461%40wrigleys.postgresql.org it seems that the query cancellation holdoff logic in ProcessInterrupts is a bit overly aggressive in keeping other interrupts from running. In particular I've seen an issue in

Re: [HACKERS] POC: Cache data in GetSnapshotData()

On September 20, 2017 7:22:00 PM PDT, Robert Haas wrote: >On Wed, Sep 20, 2017 at 10:04 PM, Mithun Cy > wrote: >> My current tests show on scylla (2 socket machine with 28 CPU core) I >> do not see any improvement at all as similar to Jesper.

Re: [HACKERS] Windows warnings from VS 2017

On 09/20/2017 08:18 PM, Andrew Dunstan wrote: > > On 09/20/2017 07:54 PM, Tom Lane wrote: >> Andrew Dunstan writes: >>> It's also warning that it will copy 16 bytes to a 13 byte structure at >>> lines 518, 1293 and 1294 of src/backend/commands/dbcommands.c. I

Re: [HACKERS] POC: Cache data in GetSnapshotData()

On Wed, Sep 20, 2017 at 10:04 PM, Mithun Cy wrote: > My current tests show on scylla (2 socket machine with 28 CPU core) I > do not see any improvement at all as similar to Jesper. But same tests > on power2 (4 sockets) and Cthulhu(8 socket machine) we can see >

Re: [HACKERS] Error: dsa_area could not attach to a segment that has been freed

On 21 September 2017 at 05:50, Thomas Munro wrote: > On Thu, Sep 21, 2017 at 12:59 AM, Robert Haas > wrote: > > On Wed, Sep 20, 2017 at 5:54 AM, Craig Ringer > wrote: > >> By the way, dsa.c really needs a

Re: [HACKERS] POC: Cache data in GetSnapshotData()

On Thu, Sep 21, 2017 at 7:25 AM, Robert Haas wrote: > On Wed, Sep 20, 2017 at 9:46 PM, Mithun Cy wrote: >> I think there is some confusion above results is for pgbench simple update >> (-N) tests where cached snapshot gets invalidated, I have

Re: [HACKERS] POC: Cache data in GetSnapshotData()

On Wed, Sep 20, 2017 at 9:46 PM, Mithun Cy wrote: > I think there is some confusion above results is for pgbench simple update > (-N) tests where cached snapshot gets invalidated, I have run this to check > if there is any regression due to frequent cache invalidation

Re: [HACKERS] POC: Cache data in GetSnapshotData()

On Wed, Sep 20, 2017 at 11:45 PM, Robert Haas wrote: > On Tue, Aug 29, 2017 at 1:57 AM, Mithun Cy wrote: >> All TPS are median of 3 runs >> Clients TPS-With Patch 05 TPS-Base%Diff >> 1 752.461117

Re: [HACKERS] POC: Cache data in GetSnapshotData()

On Thu, Sep 21, 2017 at 3:15 AM, Robert Haas wrote: > On Tue, Aug 29, 2017 at 1:57 AM, Mithun Cy wrote: >> All TPS are median of 3 runs >> Clients TPS-With Patch 05 TPS-Base%Diff >> 1 752.461117

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

On Thu, Sep 21, 2017 at 9:51 AM, Tom Lane wrote: > Michael Paquier writes: >> On Thu, Sep 21, 2017 at 9:08 AM, Tom Lane wrote: >>> Um ... so? With Nathan's proposed behavior, there are two cases depending >>> on just when the

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

Michael Paquier writes: > On Thu, Sep 21, 2017 at 9:08 AM, Tom Lane wrote: >> Um ... so? With Nathan's proposed behavior, there are two cases depending >> on just when the unexpected schema change happens: >> 1. *None* of the work gets done. >> 2.

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

On Thu, Sep 21, 2017 at 9:08 AM, Tom Lane wrote: > Michael Paquier writes: >> On Thu, Sep 21, 2017 at 8:18 AM, Tom Lane wrote: >>> "Bossart, Nathan" writes: I agree that the patch might be simpler

Re: [HACKERS] Windows warnings from VS 2017

On 09/20/2017 07:54 PM, Tom Lane wrote: > Andrew Dunstan writes: >> It's also warning that it will copy 16 bytes to a 13 byte structure at >> lines 518, 1293 and 1294 of src/backend/commands/dbcommands.c. I haven't >> seen any ill effects of this so far, but it

Re: [HACKERS] Windows warnings from VS 2017

On 09/20/2017 07:32 PM, Tom Lane wrote: > Andrew Dunstan writes: >> On 09/20/2017 06:13 PM, Michael Paquier wrote: >>> Those are around for some time, see here: >>>

Re: [HACKERS] compress method for spgist - 2

Alexander Korotkov writes: > On Thu, Sep 21, 2017 at 2:06 AM, Darafei "Komяpa" Praliaskouski < > m...@komzpa.net> wrote: >> What is rationale behind this circle? > I would prefer to rather forbid any geometries with infs and nans. > However, then upgrade process will

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

Michael Paquier writes: > On Thu, Sep 21, 2017 at 8:18 AM, Tom Lane wrote: >> "Bossart, Nathan" writes: >>> I agree that the patch might be simpler without this, but the user-visible >>> behavior is the reason I had included

Re: [HACKERS] Windows warnings from VS 2017

Andrew Dunstan writes: > It's also warning that it will copy 16 bytes to a 13 byte structure at > lines 518, 1293 and 1294 of src/backend/commands/dbcommands.c. I haven't > seen any ill effects of this so far, but it seems to indicate that > something is possibly

Re: [HACKERS] CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?

On Wed, Sep 20, 2017 at 4:08 PM, Peter Geoghegan wrote: >> pg_import_system_collations() takes care to use the non-BCP-47 style for >> such versions, so I think this is working correctly. > > But CREATE COLLATION doesn't use pg_import_system_collations(). And perhaps more to the

Re: [HACKERS] Windows warnings from VS 2017

Andrew Dunstan writes: > On 09/20/2017 06:13 PM, Michael Paquier wrote: >> Those are around for some time, see here: >> https://www.postgresql.org/message-id/CAB7nPqTkW=b_1jvvywd_g0wrkot+4ufqjggrv8osqbuzzxg...@mail.gmail.com >> But there has been no actual

Re: [HACKERS] compress method for spgist - 2

On Thu, Sep 21, 2017 at 2:06 AM, Darafei "Komяpa" Praliaskouski < m...@komzpa.net> wrote: > It is possible for bbox->low.x to be NaN when circle->center.x is and >> circle->radius are both +Infinity. >> > > What is rationale behind this circle? > I would prefer to rather forbid any geometries

Re: [HACKERS] Windows warnings from VS 2017

On Thu, Sep 21, 2017 at 7:49 AM, Andrew Dunstan wrote: > On 09/20/2017 06:13 PM, Michael Paquier wrote: >> On Thu, Sep 21, 2017 at 7:08 AM, Andrew Dunstan >> wrote: >>> First, it warns about a couple of unused variables at lines

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

On Thu, Sep 21, 2017 at 8:18 AM, Tom Lane wrote: > "Bossart, Nathan" writes: >> On 9/20/17, 2:29 PM, "Tom Lane" wrote: >>> The idea of "fast failing" because some later VacuumRelation struct might >>> contain an error seems like

Re: [HACKERS] compress method for spgist - 2

=?UTF-8?Q?Darafei_=22Kom=D1=8Fpa=22_Praliaskouski?= writes: > If it happens because NaN > Infinity, then the check should be not for > isnan, but for if (low>high){swap(high, low)}. Yeah, the same idea had occurred to me. It'd still need a comment, but at least it's slightly

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

"Bossart, Nathan" writes: > On 9/20/17, 2:29 PM, "Tom Lane" wrote: >> I think that the way this ought to work is you process the VacuumRelation >> structs purely sequentially, each in its own transaction, so you don't >> need leaps of faith about what to

Re: [HACKERS] CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?

On Wed, Sep 20, 2017 at 4:04 PM, Peter Eisentraut wrote: > ICU <54 doesn't even support the BCP 47 style, so we need to keep > supporting the old/other style anyway. Yes it does -- just not as a native locale name. ucol_open() apparently became more liberal in

Re: [HACKERS] compress method for spgist - 2

> > It is possible for bbox->low.x to be NaN when circle->center.x is and > circle->radius are both +Infinity. > What is rationale behind this circle? It seems to me that any circle with radius of any Infinity should become a [-Infinity .. Infinity, -Infinity .. Infinity] box. Then you won't have

Re: [HACKERS] CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?

On 9/19/17 22:01, Peter Geoghegan wrote: > On Tue, Sep 19, 2017 at 5:52 PM, Peter Eisentraut > wrote: >> On 9/18/17 18:46, Peter Geoghegan wrote: >>> As I pointed out a couple of times already [1], we don't currently >>> sanitize ICU's BCP 47 language tags within

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

On 9/20/17, 2:29 PM, "Tom Lane" wrote: > I started to look at this... Thanks for taking a look. > I think that the way this ought to work is you process the VacuumRelation > structs purely sequentially, each in its own transaction, so you don't > need leaps of faith about

Re: [HACKERS] Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

On 9/8/17 00:13, Pavel Stehule wrote: > I am sending rebased patch > > rebased again + fix obsolete help Why are the variables called VERBOSE_SORT_* ? What is verbose about them? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA,

Re: [HACKERS] Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

On 9/19/17 12:54, Pavel Stehule wrote: > However, patch misses regression tests covering added functionality. > > I am not sure if there are any tests related to output of \dt+ commands > - there result is platform depend. How so? -- Peter Eisentraut

Re: [HACKERS] Windows warnings from VS 2017

On 09/20/2017 06:13 PM, Michael Paquier wrote: > On Thu, Sep 21, 2017 at 7:08 AM, Andrew Dunstan > wrote: >> First, it warns about a couple of unused variables at lines 4553 and >> 4673 of src/backend/optimizer/path/costsize.c. I think we can do a >> little

Re: [HACKERS] [COMMITTERS] pgsql: Add basic TAP test setup for pg_upgrade

On 9/20/17 12:18, Tom Lane wrote: > Peter Eisentraut writes: >> Add basic TAP test setup for pg_upgrade >> The plan is to convert the current pg_upgrade test to the TAP >> framework. This commit just puts a basic TAP test in place so that we >> can see how the build farm

Re: [HACKERS] PoC: full merge join on comparison clause

> On 19 Sep 2017, at 15:18, Ashutosh Bapat > wrote: > > On Fri, Aug 25, 2017 at 10:11 PM, Alexander Kuzmenkov > wrote: >> Here is a new version of the patch, rebased to 749c7c41 and with some >> cosmetic changes. >> > > I looked at

Re: [HACKERS] Varying results when using merge joins over postgres_fdw vs hash joins

Peter Eisentraut writes: > On 9/20/17 12:06, Tom Lane wrote: >> I'm tempted to propose that we invent some kind of "unknown" >> collation, which the planner would have to be taught to not equate to any >> other column collation (not even other instances of

Re: [HACKERS] compress method for spgist - 2

Nikita Glukhov writes: > On 20.09.2017 23:19, Alexander Korotkov wrote: >> On Wed, Sep 20, 2017 at 11:07 PM, Tom Lane > > wrote: >>> Maybe I'm missing something, but it appears to me that it's >>> impossible for bbox->low.x

Re: [HACKERS] Varying results when using merge joins over postgres_fdw vs hash joins

On 9/20/17 12:06, Tom Lane wrote: > I'm tempted to propose that we invent some kind of "unknown" > collation, which the planner would have to be taught to not equate to any > other column collation (not even other instances of "unknown"), and that > postgres_fdw's IMPORT ought to label remote

Re: [HACKERS] Windows warnings from VS 2017

On Thu, Sep 21, 2017 at 7:08 AM, Andrew Dunstan wrote: > First, it warns about a couple of unused variables at lines 4553 and > 4673 of src/backend/optimizer/path/costsize.c. I think we can do a > little rearrangement to keep it happy there. Those are around for

[HACKERS] Windows warnings from VS 2017

I'm working through testing the changes to allow building with Visual Studio 2017. I've noticed that there are some warnings that we don't see in earlier compilers. First, it warns about a couple of unused variables at lines 4553 and 4673 of src/backend/optimizer/path/costsize.c. I think we can

Re: [HACKERS] [Proposal] Make the optimiser aware of partitions ordering

On Thu, Aug 31, 2017 at 5:30 AM, Peter Eisentraut wrote: > On 3/20/17 11:03, Ronan Dunklau wrote: >>> Great idea. This is too late for v10 at this point, but please add it >>> to the next CommitFest so we don't forget about it. >> I know it is too late, and

Re: [HACKERS] compress method for spgist - 2

On 20.09.2017 23:19, Alexander Korotkov wrote: On Wed, Sep 20, 2017 at 11:07 PM, Tom Lane > wrote: Darafei Praliaskouski > writes: > I have some questions about the circles example though. > 

Re: [HACKERS] Error: dsa_area could not attach to a segment that has been freed

On Thu, Sep 21, 2017 at 12:59 AM, Robert Haas wrote: > On Wed, Sep 20, 2017 at 5:54 AM, Craig Ringer wrote: >> By the way, dsa.c really needs a cross-reference to shm_toc.c and vice >> versa. With a hint as to when each is appropriate. > > /me

[HACKERS] PSA: don't be in a hurry to update to XCode 9.0

It seems to install some libraries that depend on /usr/lib/system/libsystem_darwin.dylib, which doesn't exist. Googling suggests it will be there in macOS 10.13, but on Sierra or earlier, you're outta luck. It looks like the only directly-affected PG dependency is libxml; if you leave out

Re: [HACKERS] Boom filters for hash joins (was: A design for amcheck heapam verification)

On Tue, Sep 19, 2017 at 1:25 PM, Tomas Vondra wrote: > On 09/19/2017 06:03 PM, Peter Geoghegan wrote: >> I believe that parallelism makes the use of Bloom filter a lot more >> compelling, too. Obviously this is something that wasn't taken into >> consideration in

Re: [HACKERS] coverage analysis improvements

On 9/20/17 13:13, Dagfinn Ilmari Mannsåker wrote: > I have no opinion on the bulk of this patch set, but skimming it out of > curiosity I noticed that the plperl change seems to have lost the > dependency on plperl_helpers.h from the xsubpp targets: Those commands don't actually require

Re: [HACKERS] why not parallel seq scan for slow functions

On Tue, Sep 19, 2017 at 9:15 PM, Amit Kapila wrote: > On Wed, Sep 20, 2017 at 3:05 AM, Jeff Janes wrote: > > On Tue, Sep 19, 2017 at 1:17 PM, Thomas Munro > > wrote: > >> > >> On Thu, Sep 14, 2017 at 3:19 PM, Amit

[HACKERS] close_ps, NULLs, and DirectFunctionCall

(From IRC discussion with Andreas about some sqlsmith errors) Commit 278148907a9 changed close_ps in geo_ops.c to return SQL NULL in the event that a valid result point was not found (rather than crashing or failing an assert). But close_ps is called with DirectFunctionCall from other close_*

Re: [HACKERS] compress method for spgist - 2

On Wed, Sep 20, 2017 at 11:07 PM, Tom Lane wrote: > Darafei Praliaskouski writes: > > I have some questions about the circles example though. > > > * What is the reason for isnan check and swap of box ordinates for > circle? It wasn't in the code

Re: [HACKERS] compress method for spgist - 2

Darafei Praliaskouski writes: > I have some questions about the circles example though. > * What is the reason for isnan check and swap of box ordinates for circle? > It wasn't in the code previously. I hadn't paid any attention to this patch previously, but this comment

Re: [HACKERS] SCRAM in the PG 10 release notes

On Wed, Sep 20, 2017 at 6:42 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 9/19/17 21:44, Michael Paquier wrote: > >> The patch that Heikki posted seemed reasonable to me as a starting > >> point, but there probably needs to be more "how" information somewhere. > > > > I

Re: [HACKERS] compress method for spgist - 2

On Wed, Sep 20, 2017 at 10:00 PM, Darafei Praliaskouski wrote: > The following review has been posted through the commitfest application: > make installcheck-world: not tested > Implements feature: not tested > Spec compliant: not tested > Documentation:

Re: [HACKERS] Varying results when using merge joins over postgres_fdw vs hash joins

Yeah. Definitely went down a fun rabbit hole on that separate code paths issue. Perhaps, rather than trying to fix this automatically, we should > leave it to the user. We could invent another import option that > says what to translate "default" to, with the default being, > uh, "default". > >

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

"Bossart, Nathan" writes: > [ 0001-vacuum_multiple_tables_v18.patch ] I started to look at this, but soon became pretty desperately unhappy with the way that it makes a bunch of tests on the relations and then releases all locks on them. That either makes the tests

Re: [HACKERS] compress method for spgist - 2

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:tested, passed Hi, I like the SP-GiST part of the patch. Looking forward to it, so

Re: [HACKERS] CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?

On Tue, Sep 19, 2017 at 7:01 PM, Peter Geoghegan wrote: > I didn't post the patch that generates the errors in my opening e-mail > because I'm not confident it's correct just yet. And, I think that I > see a bigger problem: we pass a string that is almost certainly a BCP > 47 string

Re: [HACKERS] POC: Cache data in GetSnapshotData()

On Tue, Aug 29, 2017 at 1:57 AM, Mithun Cy wrote: > All TPS are median of 3 runs > Clients TPS-With Patch 05 TPS-Base%Diff > 1 752.461117755.186777 -0.3% > 64 32171.296537 31202.153576

Re: [HACKERS] JIT compiling expressions/deform + inlining prototype v2.0

On 2017-09-19 12:57:33 +0300, Konstantin Knizhnik wrote: > > > On 04.09.2017 23:52, Andres Freund wrote: > > > > Hi. That piece of code isn't particularly clear (and has a bug in the > > submitted version), I'm revising it. > > ... > > Yea, I've changed that already, although it's currently

Re: [HACKERS] Parallel Hash take II

On Mon, Sep 18, 2017 at 1:06 PM, Robert Haas wrote: > If we don't adopt some approach along these lines, then I think we've > got to articulate some alternative deadlock-avoidance rule and make > sure every parallel query facility follows it. I welcome ideas on > that

Re: [HACKERS] coverage analysis improvements

Hi Peter, Peter Eisentraut writes: > OK, I was not aware that people are using it that way. So updated patch > set there, which separates coverage and coverage-html into two > independent targets. I have no opinion on the bulk of this patch set, but skimming

Re: [HACKERS] coverage analysis improvements

On 8/24/17 04:12, Michael Paquier wrote: > Patch 0001 removes the .gcov files, which offer a text representation > of the coverage. Sometimes I use that with a terminal... Not sure for > the others, but that's my status on the matter. This also removes the > target coverage. Please note that on

Re: [HACKERS] Varying results when using merge joins over postgres_fdw vs hash joins

On Wed, Sep 20, 2017 at 9:35 AM, Tom Lane wrote: > TBH, the more I learn about ICU, the less faith I have in the proposition > that it's going to fix anything at all for us in this area. It seems to > be just about as squishy as glibc in terms of locale identification, > if

Re: [HACKERS] Varying results when using merge joins over postgres_fdw vs hash joins

Peter Geoghegan writes: > I would like postgres_fdw to be taught about collation versioning, so > that postgres_fdw's IMPORT could automatically do the right thing when > ICU is in use. Maybe it's too early to discuss that, because we don't > even support alternative collation

Re: [HACKERS] Varying results when using merge joins over postgres_fdw vs hash joins

Corey Huinker writes: > We had difficulty finding the place in the code were LC_COLLATE gets > recombobulated into a recognized collation. That's because it isn't. The DB's default collation boils down to "call strcoll(), having set LC_COLLATE to whatever pg_database

Re: [HACKERS] Varying results when using merge joins over postgres_fdw vs hash joins

On Wed, Sep 20, 2017 at 9:06 AM, Tom Lane wrote: > It is that. I'm tempted to propose that we invent some kind of "unknown" > collation, which the planner would have to be taught to not equate to any > other column collation (not even other instances of "unknown"), and that >

Re: [HACKERS] Varying results when using merge joins over postgres_fdw vs hash joins

> > I'm not sure whether there's a way to fix this that doesn't break other > cases. We could retrieve the pg_database.datcollate string from the > remote, but that doesn't necessarily match up with any collation name > we know about locally. One pretty common failure mode would be that > the

[HACKERS] Assertion failure when the non-exclusive pg_stop_backup aborted.

Hi, I got an assert failure when executing pg_terminate_backend to the process that waiting for WAL to be archived in non-exclusive backup mode. TRAP: FailedAssertion("!(XLogCtl->Insert.nonExclusiveBackups > 0)", File: "xlog.c", Line: 11123) The one reproducing procedure is, 1. Start postgres

Re: [HACKERS] Varying results when using merge joins over postgres_fdw vs hash joins

Peter Geoghegan writes: > I think that Corey describes a user hostile behavior. I feel that we > should try to do better here. It is that. I'm tempted to propose that we invent some kind of "unknown" collation, which the planner would have to be taught to not equate to any other

Re: [HACKERS] Varying results when using merge joins over postgres_fdw vs hash joins

Corey Huinker writes: >> The collation column is empty here, which means that collation for >> str* columns is default collation i.e. C. This isn't true, since the >> default ncollation on the foreign server is different from the default >> collation of local database.

Re: [HACKERS] UPDATE of partition key

On 20 September 2017 at 00:06, Robert Haas wrote: > On Fri, Sep 15, 2017 at 7:25 AM, Amit Khandekar > wrote: >> [ new patch ] > > This already fails to apply again. In general, I think it would be a > good idea to break this up into a patch series

Re: [HACKERS] Page Scan Mode in Hash Index

On Wed, Sep 20, 2017 at 8:05 PM, Robert Haas wrote: > On Wed, Sep 20, 2017 at 5:37 AM, Ashutosh Sharma > wrote: >> Thanks for all your review comments. Please find my comments in-line. > > +if

Re: [HACKERS] Varying results when using merge joins over postgres_fdw vs hash joins

On Wed, Sep 20, 2017 at 2:06 AM, Ashutosh Bapat wrote: > In this case, both tables use same collation while comparing the rows, > so result is different from the merge join result. Hash join executed > on local server and the same executed on foreign server (by

Re: [HACKERS] Varying results when using merge joins over postgres_fdw vs hash joins

> > > The collation column is empty here, which means that collation for > str* columns is default collation i.e. C. This isn't true, since the > default ncollation on the foreign server is different from the default > collation of local database. AFAIU, import foreign schema should have > set

Re: [HACKERS] src/test/subscription/t/005_encoding.pl is broken

Michael Paquier writes: > On Wed, Sep 20, 2017 at 12:33 AM, Tom Lane wrote: >> That would indicate that something isn't ever retrying the worker >> start; but if that's the case, how is it that we get through the >> other subscription tests with my

Re: [HACKERS] [PATCH] Generic type subscripting

On Wed, Sep 20, 2017 at 09:35:06AM -0400, Peter Eisentraut wrote: > > The difference is that those create associations between two separate > objects (cast: type1 <-> type2, transform: type <-> language). A > subscripting is just a property of a type. > > -- > Peter Eisentraut

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Wed, Sep 20, 2017 at 5:32 AM, Rushabh Lathia wrote: > First application for the tuplesort here is CREATE INDEX and that doesn't > need randomAccess. But as you said and in the thread its been discussed, > randomAccess is an important and we should sure put an efforts

Re: [HACKERS] Page Scan Mode in Hash Index

On Wed, Sep 20, 2017 at 5:37 AM, Ashutosh Sharma wrote: > Thanks for all your review comments. Please find my comments in-line. +if (!BlockNumberIsValid(opaque->hasho_nextblkno)) +{ +if (so->currPos.buf == so->hashso_bucket_buf || +

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Wed, Sep 20, 2017 at 3:13 PM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > On Wed, Sep 20, 2017 at 9:44 AM, Thomas Munro > wrote: > > 2. What queries in the 0008 patch are hitting lines that 0007 doesn't > hit? > > > > I thought about how to

Re: [HACKERS] Re: [COMMITTERS] pgsql: Expand partitioned table RTEs level by level, without flattening

On Mon, Sep 18, 2017 at 3:30 AM, Ashutosh Bapat wrote: >> testing with sqlsmith shows that the following assertion in this commit >> doesn't hold: >> >> TRAP: FailedAssertion("!(((brel)->reloptkind == RELOPT_BASEREL || >> (brel)->reloptkind ==

Re: [HACKERS] Allow GiST opcalsses without compress\decompres functions

On Wed, Sep 20, 2017 at 5:02 PM, Tom Lane wrote: > Alexander Korotkov writes: > > On Wed, Sep 20, 2017 at 4:25 PM, Tom Lane wrote: > >> Yes. We don't allow out-of-line values, but we do allow compressed and > >> short-header

Re: [HACKERS] SCRAM in the PG 10 release notes

On Wed, Sep 20, 2017 at 9:42 AM, Peter Eisentraut wrote: > I don't have any expectation that that list will be kept up to date. Ditto. I suggest removing this as an open item. There's no defect in the code alleged, and whether there is a defect in the

Re: [HACKERS] Allow GiST opcalsses without compress\decompres functions

Alexander Korotkov writes: > On Wed, Sep 20, 2017 at 4:25 PM, Tom Lane wrote: >> Yes. We don't allow out-of-line values, but we do allow compressed and >> short-header values. > BTW, this comment looks still invalid for me... >> #define SIGLENINT

Re: [HACKERS] SCRAM in the PG 10 release notes

On 9/19/17 21:44, Michael Paquier wrote: >> The patch that Heikki posted seemed reasonable to me as a starting >> point, but there probably needs to be more "how" information somewhere. > > I agree with that. > > + > +Installations using MD5 authentication are encouraged to switch to > +

Re: [HACKERS] Error: dsa_area could not attach to a segment that has been freed

Craig Ringer writes: > On 20 September 2017 at 16:55, Thomas Munro > wrote: >> There is a kind of garbage collection for palloc'd memory and >> also for other resources like file handles, but if you're using a big >> long lived DSA area you

Re: [HACKERS] Page Scan Mode in Hash Index

On Wed, Sep 20, 2017 at 6:44 PM, Robert Haas wrote: > On Wed, Sep 20, 2017 at 7:45 AM, Amit Kapila wrote: >> Right, I was thinking from the perspective of the index entry. Before >> marking index entry as dead, we do check for heaptid. So, as

Re: [HACKERS] [PATCH] Generic type subscripting

On 9/20/17 04:12, Arthur Zakirov wrote: > On Tue, Sep 19, 2017 at 09:01:57PM -0400, Peter Eisentraut wrote: >> Would you mind posting a summary of how you go here? > > There were several points here to me: > - it is necessary to solve the dependency problem (it can be solved also by > adding

Re: [HACKERS] Allow GiST opcalsses without compress\decompres functions

On Wed, Sep 20, 2017 at 4:25 PM, Tom Lane wrote: > Andrey Borodin writes: > > You mentioned that probably there cannot be TOASTed values in the index. > > I need to settle this question in more deterministic way. > > Can you point where to look at the

Re: [HACKERS] Allow GiST opcalsses without compress\decompres functions

Andrey Borodin writes: > You mentioned that probably there cannot be TOASTed values in the index. > I need to settle this question in more deterministic way. > Can you point where to look at the code or who to ask: > Can there be TOASTed values in index tuples? Yes. We

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Tue, Sep 19, 2017 at 3:17 PM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > On Tue, Sep 19, 2017 at 2:35 AM, Robert Haas > wrote: > > On Mon, Sep 18, 2017 at 8:02 AM, Ashutosh Bapat > > wrote: > >> partition pruning might

Re: [HACKERS] Page Scan Mode in Hash Index

On Wed, Sep 20, 2017 at 7:45 AM, Amit Kapila wrote: > Right, I was thinking from the perspective of the index entry. Before > marking index entry as dead, we do check for heaptid. So, as heaptid > can't be reused via Page-at-a-time index vacuum, scan won't mark index >

Re: [HACKERS] Error: dsa_area could not attach to a segment that has been freed

On Wed, Sep 20, 2017 at 5:54 AM, Craig Ringer wrote: > By the way, dsa.c really needs a cross-reference to shm_toc.c and vice > versa. With a hint as to when each is appropriate. /me blinks. Aren't those almost-entirely-unrelated facilities? -- Robert Haas EnterpriseDB:

Re: [HACKERS] sync process names between ps and pg_stat_activity

On 9/19/17 21:30, Tsunakawa, Takayuki wrote: > From: pgsql-hackers-ow...@postgresql.org >> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Peter Eisentraut >>> Personally, I prefer "wal writer", "wal sender" and "wal receiver" >>> that separate words as other process names. But I don't

Re: [HACKERS] psql - add ability to test whether a variable exists

Correct Fabien. I have already removed myself as a reviewer. Thanks. As you wish! Thanks for the feedback, which I understood as "works for me". -- Fabien. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Improve catcache/syscache performance.

Patch 0007: 1: 400 + /* 401 +* XXX: might be worthwhile to only handle oid sysattr, to reduce 402 +* overhead - it's the most common key. 403 +*/ IMHO, let fix that as well. I tested this by fixing (see the attach patch) but does not found much gain on my local

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Tue, Sep 19, 2017 at 3:17 PM, Ashutosh Bapat wrote: >> - I'm not entirely sure whether maintaining partexprs and nullable_partexprs is the right design. If I understand correctly, whether or not a partexpr is nullable is really a per-RTI

  1   2   >