Re: [HACKERS] Bogus ANALYZE results for an otherwise-unique column with many nulls

On 5 August 2016 at 21:48, Tom Lane wrote: > OK, thanks. What shall we do about Andreas' request to back-patch this? > I'm personally willing to do it, but there is the old bugaboo of "maybe > it will destabilize a plan that someone is happy with". > My inclination would be

Re: [HACKERS] Bogus ANALYZE results for an otherwise-unique column with many nulls

På søndag 07. august 2016 kl. 09:01:40, skrev Dean Rasheed < dean.a.rash...@gmail.com >: On 5 August 2016 at 21:48, Tom Lane wrote: > OK, thanks.  What shall we do about Andreas' request to back-patch this? > I'm personally willing to do it,

[HACKERS] patch: xmltable - proof concept

Hi I am sending a initial implementation of xmltable function: The code is not clean now, but it does almost of expected work. The usage is simple. It is fast - 16K entries in 400ms. I invite any help with documentation and testing. The full ANSI/SQL, or Oracle compatible implementation is not

[HACKERS] Wait events monitoring future development

Hi, I've summarized Wait events monitoring discussion at Developer unconference in Ottawa this year on wiki: https://wiki.postgresql.org/wiki/PgCon_2016_Developer_Unconference/Wait_events_monitoring (Thanks to Alexander Korotkov for patiently pushing me to make this thing finally done) If you

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Sat, Aug 6, 2016 at 10:51:21AM -0400, Bruce Momjian wrote: > > If we need to find an efficient way to convert WARM chains back to HOT, > > which > > will happen soon when the old index tuple retires, the system can attain a > > stable state, not for all but many use cases. > > I don't see

Re: [HACKERS] Consolidate 'unique array values' logic into a reusable function?

Thomas Munro writes: > Here's a sketch patch that creates a function array_unique which takes > the same arguments as qsort or qsort_arg and returns the new length. Hmm ... I'd be against using this in backend/regex/, because I still have hopes of converting that

Re: [HACKERS] Bogus ANALYZE results for an otherwise-unique column with many nulls

Dean Rasheed writes: > On 5 August 2016 at 21:48, Tom Lane wrote: >> OK, thanks. What shall we do about Andreas' request to back-patch this? >> I'm personally willing to do it, but there is the old bugaboo of "maybe >> it will destabilize a plan

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Sun, Aug 7, 2016 at 10:49:45AM -0400, Bruce Momjian wrote: > OK, crazy idea time --- what if we only do WARM chain additions when all > indexed values are increasing (with NULLs higher than all values)? (If > a key is always-increasing, it can't match a previous value in the > chain.) That

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

On Sat, Aug 6, 2016 at 4:05 AM, Dmitry Dolgov <9erthali...@gmail.com> wrote: >> For example, suppose I create a fast temporary table and then I create a >> functional index on the fast temporary table that uses some SQL function >> defined in pg_proc. > Just to clarify, did you mean something like

Re: [HACKERS] garbage in xml regress test

Pavel Stehule writes: > When I checked result of xml test I found some strange lines in > expected/xml.out file > It is little bit strange - regress test reports ok, but diff is not empty Probably your copy of libxml produces the results in xml_2.out instead.

Re: [HACKERS] [sqlsmith] Crash in pg_get_viewdef_name_ext()

On Mon, Aug 8, 2016 at 6:57 AM, Tom Lane wrote: > Andreas Seltenreich writes: >> sqlsmith just triggered a crash in pg_get_viewdef_name_ext(). Looks >> like commit 976b24fb4 failed to update this caller of >> pg_get_viewdef_worker(). Backtrace below.

Re: [HACKERS] Slowness of extended protocol

On Sun, Aug 7, 2016 at 7:46 PM, Shay Rojansky wrote: > We could call this "protocol 3.1" since it doesn't break backwards > compatibility (no incompatible server-initiated message changes, but it does > include a feature that won't be supported by servers which only support 3.0. >

Re: [HACKERS] pg_ctl promote wait

On Sat, Aug 6, 2016 at 10:43 AM, Peter Eisentraut wrote: > On 8/5/16 12:14 AM, Michael Paquier wrote: >> In do_stop, this patches makes the wait happen for a maximum of >> wait_seconds * 2, once when getting the control file information, and >> once when waiting

Re: [HACKERS] Oddity in EXPLAIN for foreign/custom join pushdown plans

On 2016/08/05 21:47, Robert Haas wrote: On Tue, Jul 26, 2016 at 11:20 PM, Etsuro Fujita wrote: I noticed that currently the core doesn't show any information on the target relations involved in a foreign/custom join in EXPLAIN, by itself. I think that's a

Re: [HACKERS] Refactoring of heapam code.

On Sat, Aug 6, 2016 at 2:56 AM, Alvaro Herrera wrote: > Anastasia Lubennikova wrote: >> So there is a couple of patches. They do not cover all mentioned problems, >> but I'd like to get a feedback before continuing. > > I agree that we could improve things in this

Re: [HACKERS] garbage in xml regress test

2016-08-07 23:16 GMT+02:00 Tom Lane : > Pavel Stehule writes: > > When I checked result of xml test I found some strange lines in > > expected/xml.out file > > It is little bit strange - regress test reports ok, but diff is not empty > > Probably your

Re: [HACKERS] garbage in xml regress test

Pavel Stehule writes: > 2016-08-07 23:16 GMT+02:00 Tom Lane : >> Probably your copy of libxml produces the results in xml_2.out instead. > no - it is in expected/xml.out No, the output you're producing is in results/xml.out, but if the regression

Re: [HACKERS] [RFC] Change the default of update_process_title to off

From: David Rowley [mailto:david.row...@2ndquadrant.com] > But perhaps it's better written like: > > + This value defaults to "off" on Windows platforms due to the > platform's significant overhead for updating the process title. Thank you, I copied this. But I changed "off" to off because

Re: [HACKERS] Detecting skipped data from logical slots (data silently skipped)

On 5 August 2016 at 14:07, Andres Freund wrote: > > > > The simplest fix would be to require downstreams to flush their > replication > > > origin when they get a hot standby feedback message, before they send a > > > reply with confirmation. That could be somewhat painful

Re: [HACKERS] No longer possible to query catalogs for index capabilities?

Tom Lane wrote: > Building on the has-property approach Andrew suggested, I wonder if > we need something like pg_index_column_has_property(indexoid, colno, > propertyname) with properties like "sortable", "desc", "nulls first". This seems simple enough, on the surface. Why not run with this

Re: [HACKERS] No longer possible to query catalogs for index capabilities?

On Sun, Aug 07, 2016 at 07:19:39PM -0400, Tom Lane wrote: > Had the complaint been raised sooner, maybe there would've been time > to get a well-thought-out API into 9.6. The fact that it wasn't raised > till more than 6 months after we committed the pg_am changes, and more > than 2 months after

Re: [HACKERS] garbage in xml regress test

2016-08-08 5:44 GMT+02:00 Tom Lane : > Pavel Stehule writes: > > 2016-08-07 23:16 GMT+02:00 Tom Lane : > >> Probably your copy of libxml produces the results in xml_2.out instead. > > > no - it is in expected/xml.out > > No, the

Re: [HACKERS] Declarative partitioning

On 2016/08/05 21:38, Ashutosh Bapat wrote: >>> Consider lists ('e', 'i', 'f'), ('h', 'd','m') and ('l', 'b', 'a') for a >>> list partitioned tables. I am suggesting that we arrange them as >>> ('a','b','l'), ('d', 'h', 'm') and ('e', 'f', 'i'). If the given row >> (either >>> for comparison or for

Re: [HACKERS] Slowness of extended protocol

On Fri, Aug 5, 2016 at 8:07 PM, Shay Rojansky wrote: >> > I really don't get what's problematic with posting a message on a >> > mailing >> > list about a potential performance issue, to try to get people's >> > reactions, >> > without diving into profiling right away. I'm not a

Re: [HACKERS] [RFC] Change the default of update_process_title to off

On Fri, Aug 5, 2016 at 12:19 PM, Jeff Janes wrote: > On Fri, Aug 5, 2016 at 3:25 AM, Tsunakawa, Takayuki > wrote: >>> From: Tom Lane [mailto:t...@sss.pgh.pa.us] >>> Yeah, I think I agree. It would be bad to disable it by default on Unix, >>>

Re: [HACKERS] No longer possible to query catalogs for index capabilities?

On Sat, Aug 6, 2016 at 8:00 AM, Andrew Gierth wrote: > Anyway, what I haven't seen in this thread is any implementable > counter-proposal other than the "just hardcode the name 'btree'" > response that was given in the JDBC thread, which I don't consider > acceptable

Re: [HACKERS] Slowness of extended protocol

On Sun, Aug 7, 2016 at 6:11 PM, Robert Haas wrote: > I'm glad reducing the overhead of out-of-line parameters seems like an > > important goal. FWIW, if as Vladimir seems to suggest, it's possible to > > bring down the overhead of the v3 extended protocol to somewhere near

[HACKERS] garbage in xml regress test

Hi When I checked result of xml test I found some strange lines in expected/xml.out file It is little bit strange - regress test reports ok, but diff is not empty [pavel@nemesis regress]$ diff results/xml.out expected/xml.out 11a12,13 >^ 63a66,67 > ^ 222a227,228 > & >

Re: [HACKERS] [sqlsmith] Crash in GetOldestSnapshot()

On Sun, Aug 7, 2016 at 5:46 PM, Tom Lane wrote: > Robert Haas writes: >> On Sun, Aug 7, 2016 at 2:03 PM, Tom Lane wrote: >>> What I suggested just now in <2850.1470592...@sss.pgh.pa.us> might >>> be implementable with a couple

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

Robert Haas writes: > I think the whole idea of a fast temporary table is that there are no > catalog entries. If there are no catalog entries, then dependencies > are not visible. If there ARE catalog entries, to what do they refer? > Without a pg_class entry for the

Re: [HACKERS] No longer possible to query catalogs for index capabilities?

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Robert Haas wrote: > But I'm neither willing to commit a patch to fix the day before rc1 > nor to argue that the whole release cycle should be put back by > several weeks on account of this issue. Seriously? First, not sure why this would

[HACKERS] [sqlsmith] Crash in pg_get_viewdef_name_ext()

Hi, sqlsmith just triggered a crash in pg_get_viewdef_name_ext(). Looks like commit 976b24fb4 failed to update this caller of pg_get_viewdef_worker(). Backtrace below. Patch attached. regards, Andreas Program terminated with signal SIGSEGV, Segmentation fault. (gdb) bt #0 strlen () at

Re: [HACKERS] No longer possible to query catalogs for index capabilities?

On Sun, Aug 7, 2016 at 4:09 PM, Greg Sabino Mullane wrote: > Robert Haas wrote: >> But I'm neither willing to commit a patch to fix the day before rc1 >> nor to argue that the whole release cycle should be put back by >> several weeks on account of this issue. > > Seriously?

Re: [HACKERS] No longer possible to query catalogs for index capabilities?

Robert Haas writes: > On Sat, Aug 6, 2016 at 8:00 AM, Andrew Gierth > wrote: >> Anyway, what I haven't seen in this thread is any implementable >> counter-proposal other than the "just hardcode the name 'btree'" >> response that was given in

Re: [HACKERS] [sqlsmith] Crash in pg_get_viewdef_name_ext()

Andreas Seltenreich writes: > sqlsmith just triggered a crash in pg_get_viewdef_name_ext(). Looks > like commit 976b24fb4 failed to update this caller of > pg_get_viewdef_worker(). Backtrace below. Patch attached. Pushed, thanks. (For the record, you can trigger this by

Re: [HACKERS] [sqlsmith] Crash in GetOldestSnapshot()

On Sat, Aug 6, 2016 at 9:00 AM, Andrew Gierth wrote: > Hmm. > > So this happens because RETURNING queries run to completion immediately > and populate a tuplestore with the results, and the portal then fetches > from the tuplestore to send to the destination. The

Re: [HACKERS] [sqlsmith] Crash in GetOldestSnapshot()

Andrew Gierth writes: > In a similar case in the past involving holdable cursors, the solution > was to detoast _before_ storing in the tuplestore (see > PersistHoldablePortal). I guess the question now is, under what > circumstances is it now allowable to detoast a

Re: [HACKERS] [sqlsmith] Crash in GetOldestSnapshot()

On Sun, Aug 7, 2016 at 1:57 PM, Tom Lane wrote: > Andrew Gierth writes: >> In a similar case in the past involving holdable cursors, the solution >> was to detoast _before_ storing in the tuplestore (see >> PersistHoldablePortal). I guess the

Re: [HACKERS] [sqlsmith] Crash in GetOldestSnapshot()

On Sun, Aug 7, 2016 at 2:03 PM, Tom Lane wrote: > Robert Haas writes: >> So I think in the short term what we should do about this is just fix >> it so it doesn't crash. > > Well, we clearly need to fix GetOldestSnapshot so it won't crash, > but I do

Re: [HACKERS] [sqlsmith] Crash in GetOldestSnapshot()

Robert Haas writes: > So I think in the short term what we should do about this is just fix > it so it doesn't crash. Well, we clearly need to fix GetOldestSnapshot so it won't crash, but I do not think that having RETURNING queries randomly returning "ERROR: no known

Re: [HACKERS] [sqlsmith] Crash in GetOldestSnapshot()

Robert Haas writes: > On Sun, Aug 7, 2016 at 2:03 PM, Tom Lane wrote: >> What I suggested just now in <2850.1470592...@sss.pgh.pa.us> might >> be implementable with a couple hours' work, though. Do you have a >> reason to think it'd be insufficient? >

Re: [HACKERS] [sqlsmith] Crash in GetOldestSnapshot()

Robert Haas writes: > On Sun, Aug 7, 2016 at 2:03 PM, Tom Lane wrote: >> What I suggested just now in <2850.1470592...@sss.pgh.pa.us> might >> be implementable with a couple hours' work, though. Do you have a >> reason to think it'd be insufficient? >