Re: [HACKERS] Hang in pldebugger after git commit : 98a64d0

On Fri, Dec 9, 2016 at 4:11 PM, Michael Paquier wrote: > On Fri, Dec 9, 2016 at 3:23 PM, Michael Paquier > wrote: >> This basically means that if the latch is set, we don't wait at all >> and drop the ball. I am wondering: isn't that a

Re: [HACKERS] jacana hung after failing to acquire random number

On Mon, Dec 12, 2016 at 4:32 PM, Heikki Linnakangas wrote: > That test is broken. It looks like the x"$VAR" = x"constant" idiom, but the > left side of the comparison doesn't have the 'x'. Oops. Good catch. > This makes me wonder if we should work a bit harder to get a good

Re: [HACKERS] jacana hung after failing to acquire random number

On 12/12/2016 05:58 AM, Michael Paquier wrote: On Sun, Dec 11, 2016 at 9:06 AM, Andrew Dunstan wrote: jascana (mingw, 64 bit compiler, no openssl) is currently hung on "make check". After starting the autovacuum launcher there are 120 messages on its log about "Could not

[HACKERS] Parallel Index-only scan

Hello all, This is to propose a patch for enabling parallel index-only scans. With the patch of parallel index scan around [1], adding the mechanism for parallelising index-only scans makes sense. Without this mechanism for the queries preferring index-only scans, it is likely that at higher scale

Re: [HACKERS] Declarative partitioning - another take

Hi Tomas, On 2016/12/12 10:02, Tomas Vondra wrote: > On 12/07/2016 07:20 PM, Robert Haas wrote: >> I've committed 0001 - 0006 with that correction and a few other >> adjustments. There's plenty of room for improvement here, and almost >> certainly some straight-up bugs too, but I think we're at

Re: [HACKERS] Broken SSL tests in master

On 12/01/2016 09:45 PM, Andres Freund wrote: And nobody has added a buildfarm module to run it manually on their servers either :( I just added a module to run "make -C src/test/ssl check" in chipmunk. So at least that's covered now.

Re: [HACKERS] proposal: psql statements \gstore \gstore_binary (instead COPY RAW)

2016-12-11 18:23 GMT+01:00 Pavel Stehule : > Hi > > 2016-12-09 18:39 GMT+01:00 Pavel Stehule : > >> Hi >> >> Long time I am pushing a COPY RAW - without success. >> >> Now I propose functionally similar solution - reduced to only to psql >>

Re: [HACKERS] pgcrypto compilation error due to stack-allocated EVP_CIPHER_CTX

On Fri, Dec 9, 2016 at 10:22 AM, Michael Paquier wrote: > Thanks for looking at the patch. Looking forward to hearing more! Here is an updated patch based on which reviews should be done. I have fixed the issue you have reported, and upon additional lookup I have

Re: [HACKERS] [COMMITTERS] pgsql: Implement table partitioning.

On 2016/12/10 7:55, Keith Fiske wrote: > Working on a blog post for this feature and just found some more > inconsistencies with the doc examples. Looks like the city_id column was > defined in the measurements table when it should be in the cities table. > The addition of the partition to the

Re: [HACKERS] jsonb problematic operators

On 12 December 2016 at 12:52, Tom Lane wrote: > Craig Ringer writes: >> It's definitely annoying, in both directions. ? wasn't a great choice >> for an operator character but it's logical and was grandfathered over >> from hstore. > > It was

Re: [HACKERS] Hash Indexes

On Mon, Dec 12, 2016 at 10:25 AM, Jeff Janes wrote: > On Sun, Dec 11, 2016 at 8:37 PM, Amit Kapila > wrote: >> >> On Sun, Dec 11, 2016 at 11:54 AM, Amit Kapila >> wrote: >> > On Wed, Dec 7, 2016 at 2:02 AM, Jeff Janes

Re: [HACKERS] Hash Indexes

On Sun, Dec 11, 2016 at 8:37 PM, Amit Kapila wrote: > On Sun, Dec 11, 2016 at 11:54 AM, Amit Kapila > wrote: > > On Wed, Dec 7, 2016 at 2:02 AM, Jeff Janes wrote: > > > > With above fixes, the test ran successfully for

Re: [HACKERS] jsonb problematic operators

Craig Ringer writes: > It's definitely annoying, in both directions. ? wasn't a great choice > for an operator character but it's logical and was grandfathered over > from hstore. It was grandfathered from a lot further back than that. A quick look into the system

Re: [HACKERS] Hash Indexes

On Tue, Dec 6, 2016 at 1:29 PM, Jeff Janes wrote: > On Thu, Dec 1, 2016 at 10:54 PM, Amit Kapila > wrote: > > With the latest HASH WAL patch applied, I get different but apparently > related errors > > 41993 UPDATE XX002 2016-12-05 22:28:45.333

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

On Tue, Dec 6, 2016 at 9:19 AM, Andres Freund wrote: > 0009 WIP: Add minimal keytest implementation. > > More or less experimental patch that tries to implement simple > expression of the OpExpr(ScalarVar, Const) into a single expression > evaluation step. The benefits

Re: [HACKERS] Hash Indexes

On Sun, Dec 11, 2016 at 11:54 AM, Amit Kapila wrote: > On Wed, Dec 7, 2016 at 2:02 AM, Jeff Janes wrote: > > With above fixes, the test ran successfully for more than a day. > There was a small typo in the previous patch which is fixed in attached.

Re: [HACKERS] jsonb problematic operators

On 11 December 2016 at 18:52, Geoff Winkless wrote: > On 9 Dec 2016 17:54, "Andres Freund" wrote: > > On 2016-12-09 12:17:32 -0500, Robert Haas wrote: >> As Geoff says, you don't have to use the operators; you could use the >> equivalent functions

Re: [HACKERS] Declarative partitioning - another take

Hi, On 2016/12/11 10:02, Venkata B Nagothi wrote: > On Fri, Dec 9, 2016 at 11:11 PM, Amit Langote > wrote: >> On Fri, Dec 9, 2016 at 3:16 PM, Venkata B Nagothi >> wrote: >>> I am testing the partitioning feature from the latest master and got the >>>

Re: [HACKERS] PATCH: two slab-like memory allocators

On 01/12/16 03:26, Tomas Vondra wrote: > > Dne 11/27/2016 v 11:02 PM Andres Freund napsal(a): >> On 2016-11-27 22:21:49 +0100, Petr Jelinek wrote: >>> On 27/11/16 21:47, Andres Freund wrote: Hi, >> +typedef struct SlabBlockData *SlabBlock;/* forward >> reference */

Re: [HACKERS] jacana hung after failing to acquire random number

On Sun, Dec 11, 2016 at 9:06 AM, Andrew Dunstan wrote: > > jascana (mingw, 64 bit compiler, no openssl) is currently hung on "make > check". After starting the autovacuum launcher there are 120 messages on its > log about "Could not acquire random number". Then nothing. > > >

Re: [HACKERS] snapbuild woes

On 12 December 2016 at 00:36, Kevin Grittner wrote: > On Sun, Dec 11, 2016 at 1:17 AM, Craig Ringer > wrote: >> On 11 Dec. 2016 06:50, "Petr Jelinek" wrote: >>> On 10/12/16 23:10, Petr Jelinek wrote: >>> The

Re: [HACKERS] Declarative partitioning - another take

Hi, On 12/07/2016 07:20 PM, Robert Haas wrote: > On Wed, Dec 7, 2016 at 11:53 AM, Erik Rijkers wrote: >>> My bad. The fix I sent last night for one of the cache flush issues >>> wasn't quite right. The attached seems to fix it. >> Yes, fixed here too. Thanks. > > Thanks for

Re: [HACKERS] building HEAD on macos fails with #error no source of random numbers configured

On 12/9/16 9:53 AM, Heikki Linnakangas wrote: I'm not sure what --no-recursion does, but I would say that we'd consider that unsupported as well. Interesting. Running config.status adds those --no-create --no-recursion flags automatically. You can see them in the command-line at the top of

Re: [HACKERS] Optimization for index-only scans with filter conditions

Mateusz Stefek writes: > Attached is a patch, which changes the order of the checks. I.e. the > visibility of the row is confirmed only after the qual condition is > evaluated to true. This cannot be accepted, because it's unsafe to try to apply user code to a dead

Re: [HACKERS] [sqlsmith] Crash in tsquery_rewrite/QTNBinary

Artur Zakirov writes: > 2016-12-07 9:06 GMT+03:00 Andreas Seltenreich : >> the following query crashes master as of 4212cb7. > It happens because 'I' is stop word and substitute query becomes > empty. And for queries above we need recursive

[HACKERS] Optimization for index-only scans with filter conditions

Hi, I noticed that during an index-only scan the filter check is executed after the visibility of a tuple is confirmed. This means a lot of unnecessary heap fetches, if the filter condition is highly selective. In the application I'm maintaining, the visibility map is mostly dirty. Index-only

Re: [HACKERS] proposal: psql statements \gstore \gstore_binary (instead COPY RAW)

Hi 2016-12-09 18:39 GMT+01:00 Pavel Stehule : > Hi > > Long time I am pushing a COPY RAW - without success. > > Now I propose functionally similar solution - reduced to only to psql > console > > Now we have a statement \g for execution query, \gset for exec and store >

Re: [HACKERS] snapbuild woes

On Sun, Dec 11, 2016 at 1:17 AM, Craig Ringer wrote: > On 11 Dec. 2016 06:50, "Petr Jelinek" wrote: >> On 10/12/16 23:10, Petr Jelinek wrote: >> >>> The attached 0002-Skip-unnecessary-snapshot-builds.patch changes this >>> behavior so

Re: [HACKERS] jsonb problematic operators

On 9 Dec 2016 17:54, "Andres Freund" wrote: On 2016-12-09 12:17:32 -0500, Robert Haas wrote: > As Geoff says, you don't have to use the operators; you could use the > equivalent functions instead. Every operator just gets turned into a > function call internally, so this is

Re: [HACKERS] background sessions

Hi! I'm planning to review this patch. I have some questions, maybe answers could help me understand patch better. 1. As far as I can see, we connot use COPY FROM STDIN in bg session? Since one of purposes is to orchestrate transactions, may be that would be valuable. 2. From my point of view the

[HACKERS] Typo in doc/src/sgml/catalogs.sgml

Hi, I found a minor typo at https://www.postgresql.org/docs/9.6/static/catalog-pg-am.html. pg_catalog.pg_am. amhandler is of type "oid" according to the documentation, but it's actually of type "regproc" in reality. Compare with e.g. pg_aggregate where the columns of type "regproc" is both

Re: [HACKERS] pg_background contrib module proposal

2016-12-09 18:00 GMT+05:00 Robert Haas : > It looks like this could be reworked as a client of Peter Eisentraut's > background sessions code, which I think is also derived from > pg_background: > >