Re: SP-GiST failing to complete SP-GiST index build

> On May 27, 2018, at 8:24 PM, Peter Geoghegan wrote: > > On Sun, May 27, 2018 at 5:10 PM, Tom Lane wrote: >> Instrumenting the test case suggests that getQuadrant pretty much always >> returns 1, resulting in a worst-case unbalanced SPGiST tree. I think this

Re: Undo logs

Exciting stuff! Really looking forward to having a play with this. James Sewell, *Chief Architect* Suite 112, Jones Bay Wharf, 26-32 Pirrama Road, Pyrmont NSW 2009 *P *(+61) 2 8099 9000 <(+61)%202%208099%209000> *W* www.jirotech.com *F * (+61) 2 8099 9099 <(+61)%202%208099%209000> On 25 May

Re: Handling better supported channel binding types for SSL implementations

On Thu, Mar 08, 2018 at 02:19:55PM -0500, Peter Eisentraut wrote: > Moved to next CF along with those other two patches. Attached is a refreshed patch for this thread, which failed to apply after recent changes. This is tied with patches for other SSL implementations, so let's see about it later

Re: In what range of the code can we read debug_query_string?

Thank you for the comment. At Fri, 25 May 2018 10:08:08 -0400, Tom Lane wrote in <3389.1527257...@sss.pgh.pa.us> > Kyotaro HORIGUCHI writes: > > It is set for other kinds of message, (parse, bind, execute). I > > think fastpath, close, flush

Re: Is a modern build system acceptable for older platforms

> > Can't see getting rid of those entirely. None of the github style > platforms copes with reasonable complex discussions. I disagree. A good example of complex discussions on github is Rust language tracker for RFCs: https://github.com/rust-lang/rfcs/issues and one concrete example:

Re: Is a modern build system acceptable for older platforms

I suppose I can make summary after reading all this: 1. Any change in the development process will be possible if it will be convenient for each key developers personally only. (development process include build system) 2. Currently, almost all key developers use Unix like systems, they have

Re: SCRAM with channel binding downgrade attack

On Sat, May 26, 2018 at 11:42:38PM +0900, Michael Paquier wrote: > On Sat, May 26, 2018 at 09:08:50AM -0400, Bruce Momjian wrote: >> On Sat, May 26, 2018 at 08:32:20AM +0900, Michael Paquier wrote: >>> >>> OK, I can live with that as well. So we'll go in the direction of two >>> parameters then:

Re: SP-GiST failing to complete SP-GiST index build

On Sun, May 27, 2018 at 5:10 PM, Tom Lane wrote: > Instrumenting the test case suggests that getQuadrant pretty much always > returns 1, resulting in a worst-case unbalanced SPGiST tree. I think this > is related to the fact that the test case inserts the values in increasing

Re: SP-GiST failing to complete SP-GiST index build

Peter Geoghegan writes: > Looks like I spoke too soon. The SP-GiST index build finished a moment > ago. The index build took a horrifically long time for a 122 MB index, > though. Instrumenting the test case suggests that getQuadrant pretty much always returns 1, resulting in a

Re: SP-GiST failing to complete SP-GiST index build

On Sun, May 27, 2018 at 2:09 PM, Peter Geoghegan wrote: > On Sun, May 27, 2018 at 12:45 PM, Jonathan S. Katz > wrote: >> Next, see bad.sql. 1.2MM sparsely clustered rows inserted, GiST indexes >> builds in about 30s on my machine. SP-GiST does not build at

Re: jsonb iterator not fully initialized

> On 26 May 2018 at 16:47, Andrew Dunstan > wrote: > On 05/26/2018 03:09 AM, Piotr Stefaniak wrote: >> On 2018-05-26 02:02, Peter Eisentraut wrote: >>> >>> It can be fixed this way: >>> >>> --- a/src/backend/utils/adt/jsonb_util.c >>> +++

Re: found xmin from before relfrozenxid on pg_catalog.pg_authid

Hi, On 2018-05-27 13:22:21 -0400, Tom Lane wrote: > But I don't think there's any need for special magic here: we just > have to accept the fact that there's a need to flush that cache > sometimes. In normal use it shouldn't happen often enough to be a > performance problem. Yea, it's not that

SP-GiST failing to complete SP-GiST index build

Hi, While preparing for an upcoming presentation, I was playing around with SP-GiST indexes on tstz ranges and was having an issue where some would fail to build to completion in a reasonable time, especially compared to corresponding GiST builds. Version: PostgreSQL 10.4 on

Re: found xmin from before relfrozenxid on pg_catalog.pg_authid

Andres Freund writes: > On May 27, 2018 9:39:49 AM PDT, "Nasby, Jim" wrote: >> How about only keeping the critical info for being able to find >> relations in the .init files, and then fully populate the cache by >> doing a normal lookup? > Then the cache

Re: found xmin from before relfrozenxid on pg_catalog.pg_authid

On May 27, 2018 9:39:49 AM PDT, "Nasby, Jim" wrote: >On May 26, 2018, at 1:45 PM, Andres Freund wrote: >> Does anybody see a way to not have to remove the .init file? > >How about only keeping the critical info for being able to find >relations in the

Re: found xmin from before relfrozenxid on pg_catalog.pg_authid

On May 26, 2018, at 1:45 PM, Andres Freund wrote: > Does anybody see a way to not have to remove the .init file? How about only keeping the critical info for being able to find relations in the .init files, and then fully populate the cache by doing a normal lookup? Since

Re: Redesigning the executor (async, JIT, memory efficiency)

> > I think we're going to have to continue showing the tree plan. I think > the linear version is far too hard to understand for anything > nontrivial. > Hey Andres, what you're pitching here is very similar to the way DB2 works. It actually has two different explain tools that dumps the two

Re: perlcritic and perltidy

On 05/25/2018 03:04 PM, Bruce Momjian wrote: On Sun, May 6, 2018 at 11:53:34AM -0400, Tom Lane wrote: What sort of changes do we get if we remove those two flags as you prefer? It'd help to see some examples. Since we just went to a new perltidy version, and made some other policy changes

Re: Periods

2018-05-26 22:56 GMT+02:00 Vik Fearing : > SQL:2011 introduced the concept of a "period". It takes two existing > columns and basically does the same thing as our range types except there > is no new storage. I believe if Jeff Davis had given us range types a few >