Re: JIT compiling with LLVM v12.2

Hi, On 2018-03-22 09:00:19 +1300, Thomas Munro wrote: > On Thu, Mar 22, 2018 at 8:47 AM, Andres Freund wrote: > > On 2018-03-21 20:06:49 +1300, Thomas Munro wrote: > >> On Wed, Mar 21, 2018 at 4:07 PM, Andres Freund wrote: > >> > Indeed. I've pushed a

Re: JIT compiling with LLVM v12.2

On 2018-03-22 09:51:01 +1300, Thomas Munro wrote: > On Thu, Mar 22, 2018 at 9:09 AM, Andres Freund wrote: > > Hi, > > > > On 2018-03-22 09:00:19 +1300, Thomas Munro wrote: > >> 64 bit CPU, 32 bit OS. I didn't try Debian multi-arch i386 support on > >> an amd64 system, but

Multiple-output-file make rules: We're Doing It Wrong

In https://postgr.es/m/32497.1519858...@sss.pgh.pa.us I griped about a weird make failure I was having with VPATH builds. I did not push the patch I suggested at the time, because I didn't understand why it seemed to resolve the issue, and because neither I nor anyone else could reproduce the

Re: reorganizing partitioning code

Alvaro Herrera writes: > David Steele wrote: >> Are you planning to update this patch? If not, I think it should be >> marked as Returned with Feedback and submitted to the next CF once it >> has been updated. > This is no new development, only code movement. I think

Re: WIP: Covering + unique indexes.

On Thu, Mar 8, 2018 at 7:13 PM, Anastasia Lubennikova < a.lubennik...@postgrespro.ru> wrote: > 06.03.2018 11:52, Thomas Munro: > >> On Wed, Jan 31, 2018 at 3:09 AM, Anastasia Lubennikova >> wrote: >> >>> Thank you for reviewing. All mentioned issues are fixed. >>>

Re: Re: ALTER TABLE ADD COLUMN fast default

On 3/15/18 4:33 AM, Andrew Dunstan wrote: > > rebased and mostly indented patch version attached. It's actually > moderately difficult to produce a nicely indented patch that is > against non-pgindented code. We should look at that a bit. Another > item for my TODO list. It looks like this should

Re: JIT compiling with LLVM v12.2

On Thu, Mar 22, 2018 at 9:09 AM, Andres Freund wrote: > Hi, > > On 2018-03-22 09:00:19 +1300, Thomas Munro wrote: >> 64 bit CPU, 32 bit OS. I didn't try Debian multi-arch i386 support on >> an amd64 system, but that's probably an easier way to do this if you >> already have

Re: JIT compiling with LLVM v12.2

On Thu, Mar 22, 2018 at 9:59 AM, Andres Freund wrote: > On 2018-03-22 09:51:01 +1300, Thomas Munro wrote: >> Hah, that makes sense. I tried setting cpu to "x86", and now it fails >> differently: > > Did you change the variable, or replace the value that's passed to the >

Re: JIT compiling with LLVM v12.2

Hi, On 2018-03-21 23:10:27 +1300, Thomas Munro wrote: > Next up, I have an arm64 system running Debian 9.4. It bombs in > "make check" and in simple tests: Any chance you could try w/ LLVM 6? It looks like some parts of ORC only got aarch64 in LLVM 6. I didn't *think* those were necessary,

Re: JIT compiling with LLVM v12.2

On 2018-03-22 10:50:52 +1300, Thomas Munro wrote: > On Thu, Mar 22, 2018 at 10:44 AM, Andres Freund wrote: > > On 2018-03-21 23:10:27 +1300, Thomas Munro wrote: > >> Next up, I have an arm64 system running Debian 9.4. It bombs in > >> "make check" and in simple tests: > > > >

Re: JIT compiling with LLVM v12.2

Hi, On 2018-03-21 20:06:49 +1300, Thomas Munro wrote: > On Wed, Mar 21, 2018 at 4:07 PM, Andres Freund wrote: > > Indeed. I've pushed a rebased version now, that basically just fixes the > > issue Thomas observed. > > I set up a 32 bit i386 virtual machine and installed

Re: JIT compiling with LLVM v12.2

Hi, On 2018-03-21 08:26:28 +0100, Catalin Iacob wrote: > On Wed, Mar 21, 2018 at 4:07 AM, Andres Freund wrote: > > Indeed. I've pushed a rebased version now, that basically just fixes the > > issue Thomas observed. > > Testing 2d6f2fba from your repository configured

Re: JIT compiling with LLVM v12.2

On Thu, Mar 22, 2018 at 8:47 AM, Andres Freund wrote: > On 2018-03-21 20:06:49 +1300, Thomas Munro wrote: >> On Wed, Mar 21, 2018 at 4:07 PM, Andres Freund wrote: >> > Indeed. I've pushed a rebased version now, that basically just fixes the >> > issue

Re: JIT compiling with LLVM v12.2

On 2018-03-21 23:10:27 +1300, Thomas Munro wrote: > On Wed, Mar 21, 2018 at 8:06 PM, Thomas Munro > wrote: > > On Wed, Mar 21, 2018 at 4:07 PM, Andres Freund wrote: > >> Indeed. I've pushed a rebased version now, that basically just fixes the >

Re: [PoC PATCH] Parallel dump to /dev/null

On Tue, Mar 20, 2018 at 6:57 AM, Michael Paquier wrote: > Now, why are people using pg_dump > /dev/null? Mainly the lack of > better tools, which would be actually able to detect pages in corrupted > pages in one run, and not only heap pages. I honestly think that > amcheck

Re: [HACKERS] Partition-wise aggregation/grouping

On Wed, Mar 21, 2018 at 11:33 AM, Jeevan Chalke wrote: > Let me try to explain this: > 1. GROUPING_CAN_PARTITIONWISE_AGG > 2. extra->is_partial_aggregation > 3. extra->perform_partial_partitionwise_aggregation Please find attached an incremental patch that

Re: JIT compiling with LLVM v12.2

On Thu, Mar 22, 2018 at 9:06 AM, Andres Freund wrote: > On 2018-03-21 23:10:27 +1300, Thomas Munro wrote: >> Next up, I have an arm64 system running Debian 9.4. It bombs in >> "make check" and in simple tests: > > Hum. Is it running a 32bit or 64 bit kernel/os? checking size

Re: JIT compiling with LLVM v12.2

Andres Freund writes: > Hi, > > On 2018-03-21 20:06:49 +1300, Thomas Munro wrote: >> On Wed, Mar 21, 2018 at 4:07 PM, Andres Freund wrote: >> > Indeed. I've pushed a rebased version now, that basically just fixes the >> > issue Thomas observed. >> >> I

Re: JIT compiling with LLVM v12.2

Hi, On 2018-03-22 10:09:23 +1300, Thomas Munro wrote: > > FWIW, a 32bit chroot, on a 64bit kernel works: > > > > 2018-03-21 20:57:56.576 UTC [3708] DEBUG: successfully loaded LLVM in > > current session > > 2018-03-21 20:57:56.577 UTC [3708] DEBUG: JIT detected CPU "skylake", with > >

Re: JIT compiling with LLVM v12.2

On Thu, Mar 22, 2018 at 10:36 AM, Andres Freund wrote: > On 2018-03-21 14:21:01 -0700, Andres Freund wrote: >> I think it's I that did something wrong not you. And the architecture >> thing is a non-issue, because we're taking the target triple from the >> right place. I

Re: JIT compiling with LLVM v12.2

Hi, On 2018-03-22 09:31:12 +1300, Thomas Munro wrote: > Aside from whatever problem is causing this, we can see that there is > no top-level handling of exceptions. That's probably fine if we are > in a no throw scenario (unless there is something seriously corrupted, > as is probably the case

Re: JIT compiling with LLVM v12.2

On Thu, Mar 22, 2018 at 10:44 AM, Andres Freund wrote: > On 2018-03-21 23:10:27 +1300, Thomas Munro wrote: >> Next up, I have an arm64 system running Debian 9.4. It bombs in >> "make check" and in simple tests: > > Any chance you could try w/ LLVM 6? It looks like some parts

Re: JIT compiling with LLVM v12.2

On Thu, Mar 22, 2018 at 10:50 AM, Thomas Munro wrote: > On Thu, Mar 22, 2018 at 10:44 AM, Andres Freund wrote: >> On 2018-03-21 23:10:27 +1300, Thomas Munro wrote: >>> Next up, I have an arm64 system running Debian 9.4. It bombs in >>> "make

Re: [HACKERS] pg_upgrade to clusters with a different WAL segment size

On 3/13/18 20:53, Bossart, Nathan wrote: > Here is a new set of patches that addresses most of Peter's feedback. > I've split it into four pieces: > > 0001: Fix division-by-zero error in pg_controldata committed that > 0002: Fix division-by-zero error in pg_resetwal This looks a bit more

Re: Re: Sample values for pg_stat_statements

Hi Vik, On 3/10/18 9:02 AM, Tomas Vondra wrote: > > I've looked at this patch today. I like the idea / intent in general, as > it helps with some investigation tasks. That being said, I have a couple > of questions/comments based on read through the patch: It looks like there are some privacy

Re: Re: Protect syscache from bloating with negative cache entries

On 3/15/18 1:12 AM, Kyotaro HORIGUCHI wrote: > At Mon, 12 Mar 2018 17:34:08 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI > wrote in > > The attached is the patch set including this plancache stuff. > > 0001- catcache time-based expiration (The origin of this

Re: [HACKERS] MERGE SQL Statement for PG11

On Wed, Mar 21, 2018 at 5:23 AM, Pavan Deolasee wrote: >> * The docs say "A condition cannot contain subqueries, set returning >> functions, nor can it contain window or aggregate functions". Thought >> it can now? > > > Yes, it now supports sub-queries. What about

Re: Re: csv format for psql

Hi Daniel, On 3/10/18 1:49 AM, Fabien COELHO wrote: > >>> recordsep in the unaligned mode doesn't play the role of a line ending >>> because the last line is not finished by recordsep. According to the >>> source >>> code, this is intended, see print_unaligned_text() in print.c: >> >> Something

Re: [HACKERS] pg_upgrade to clusters with a different WAL segment size

On 3/21/18, 12:57 PM, "Peter Eisentraut" wrote: > On 3/13/18 20:53, Bossart, Nathan wrote: >> 0001: Fix division-by-zero error in pg_controldata > > committed that Thanks! >> 0002: Fix division-by-zero error in pg_resetwal > > This looks a bit more

Re: [HACKERS] Secondary index access optimizations

On 01.03.2018 23:15, Andres Freund wrote: Hi, This patch seems like quite a good improvement. One thing I've not really looked at but am slightly concerned in passing: Are there cases where we now would do a lot of predicate pruning work even though the overhead of just evaluating the qual

Re: [PATCH] Add support for ON UPDATE/DELETE actions on ALTER CONSTRAINT

Matheus de Oliveira wrote: > You think this should be applied to all versions that support ALTER > CONSTRAINT, right? This seems a bug fix to me, so yes. > I can do that, no problem. It'll take awhile though, I'm on a trip and will > be home around March 20th. Please do send at your earliest

Re: pgbench - add \if support

Hello Teodor, Patch seems usefull and commitable except comments in conditional.[ch]. I'd like to top/header comment in each file more detailed and descriptive. As for now it mentions only psql usage without explaining how it is basic or common. Indeed, it was not updated. I've fixed the

Re: constraint exclusion and nulls in IN (..) clause

> After further thought, it seems like the place to deal with this is > really operator_predicate_proof(), as in the attached draft patch > against HEAD. This passes the smell test for me, in the sense that > it's an arguably correct and general extension of the proof rules, > but it could use

Re: [HACKERS] [PATCH] Incremental sort

Hi, on a PostGIS system tuned for preferring parallelism heavily ( min_parallel_table_scan_size=10kB) we experience issues with QGIS table discovery query with this patch: Failing query is: [local] gis@gis=# SELECT

Re: JIT compiling with LLVM v12.2

On Wed, Mar 21, 2018 at 8:06 PM, Thomas Munro wrote: > On Wed, Mar 21, 2018 at 4:07 PM, Andres Freund wrote: >> Indeed. I've pushed a rebased version now, that basically just fixes the >> issue Thomas observed. > > I set up a 32 bit i386 virtual

Re: [HACKERS] [PATCH] Incremental sort

Hi! On Wed, Mar 21, 2018 at 2:30 PM, Darafei "Komяpa" Praliaskouski < m...@komzpa.net> wrote: > on a PostGIS system tuned for preferring parallelism heavily ( > min_parallel_table_scan_size=10kB) we experience issues with QGIS table > discovery query with this patch: > > Failing query is: >

Re: handling of heap rewrites in logical decoding

On 16 March 2018 at 10:54, Craig Ringer wrote: > On 16 March 2018 at 08:51, Peter Eisentraut com> wrote: > >> On 2/28/18 13:52, Peter Eisentraut wrote:> Second version, which uses an >> OID. I added another field to the output> plugin

Re: Question about WalSndWriteData

On 21.03.2018 04:50, Peter Eisentraut wrote: On 3/16/18 12:08, Konstantin Knizhnik wrote: pq_putmessage_noblock copies data from ctx->out buffer to libpq buffers. After it we write timestamp to ctx->out buffer. And comments says that we should do it "as late as possible". But this timestamp

Re: missing support of named convention for procedures

2018-03-20 17:31 GMT+01:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > On 3/16/18 06:29, Pavel Stehule wrote: > > attached patch fixes it > > The fix doesn't seem to work for LANGUAGE SQL procedures. For example: > > CREATE PROCEDURE ptest5(a int, b int DEFAULT 0) > LANGUAGE SQL > AS

Re: JIT compiling with LLVM v12.2

On Wed, Mar 21, 2018 at 4:07 AM, Andres Freund wrote: > Indeed. I've pushed a rebased version now, that basically just fixes the > issue Thomas observed. Testing 2d6f2fba from your repository configured --with-llvm I noticed some weird things in the configure output. Without

Re: [PoC PATCH] Parallel dump to /dev/null

Hi, Am Dienstag, den 20.03.2018, 19:19 -0400 schrieb Stephen Frost: > * Christoph Berg (christoph.b...@credativ.de) wrote: > > Re: Tom Lane 2018-03-20 <12960.1521557...@sss.pgh.pa.us> > > > It might help if the patch were less enthusiastic about trying to > > > "optimize" by avoiding extra file

Re: PATCH: psql tab completion for SELECT

On 8 March 2018 at 17:23, Edmund Horner wrote: > New patch that fixes a little bug with appending NULL addons to schema > queries. Hi all, I haven't heard anything for a while and so assume you're beavering away on real features. :) I've been dogfooding this patch at work,

Re: PQHost() undefined behavior if connecting string contains both host and hostaddr types

On Wed, Mar 21, 2018 at 10:33:19AM +1100, Haribabu Kommi wrote: > On Wed, Mar 21, 2018 at 6:06 AM, Peter Eisentraut < > peter.eisentr...@2ndquadrant.com> wrote: > >> On 3/16/18 00:03, Kyotaro HORIGUCHI wrote: >>> I agree to the conclusion that PQhost() shouldn't return hostaddr >>> "if it has any

Re: JIT compiling with LLVM v12.2

On Wed, Mar 21, 2018 at 4:07 PM, Andres Freund wrote: > Indeed. I've pushed a rebased version now, that basically just fixes the > issue Thomas observed. I set up a 32 bit i386 virtual machine and installed Debian 9.4. Compiler warnings: gcc -Wall -Wmissing-prototypes

Re: [PROPOSAL] Shared Ispell dictionaries

On Tue, Mar 20, 2018 at 09:30:15PM +0100, Tomas Vondra wrote: > On 03/20/2018 02:11 PM, Arthur Zakirov wrote: > > max_shared_dictionaries_size is defined as PGC_SIGHUP now. Added check > > of a new value to disallow to set zero if there are loaded dictionaries > > and to decrease maximum allowed

Re: pg_basebackup: Missing newlines in some error messages

> On 21 Mar 2018, at 13:12, Michael Banck wrote: > while working on something else, I noticed that some error messages in > pg_basebackup do not have a "\n" at the end, resulting in output like: > > |pg_basebackup: could not get COPY data stream: pg_basebackup:

Re: pg_basebackup: Missing newlines in some error messages

Alvaro Herrera wrote: > Hi > > Michael Banck wrote: > > > I apparently managed to screw up so badly that no PQerrorMessage was > > set, so saw the above (which indeed has no error message after the > > colon). > > Well, maybe that's a different bug, then: maybe we should print > something other

Re: PQHost() undefined behavior if connecting string contains both host and hostaddr types

On 3/21/18 03:40, Michael Paquier wrote: >>> Moreover, I wonder whether we shouldn't remove the branch where >>> conn->connhost is NULL. When would that be the case? The current >>> behavior is to sometimes return the actual host connected to, and >>> sometimes the host list. That doesn't make

Re: [HACKERS] Partition-wise aggregation/grouping

On Wed, Mar 21, 2018 at 2:04 AM, Robert Haas wrote: > On Tue, Mar 20, 2018 at 10:46 AM, Jeevan Chalke > wrote: > > I have added all these three patches in the attached patch-set and > rebased > > my changes over it. > > > > However, I have

Re: pg_basebackup: Missing newlines in some error messages

Hi Michael Banck wrote: > I apparently managed to screw up so badly that no PQerrorMessage was > set, so saw the above (which indeed has no error message after the > colon). Well, maybe that's a different bug, then: maybe we should print something other than PQerrorMessage (or maybe

Re: handling of heap rewrites in logical decoding

On 3/21/18 03:08, Craig Ringer wrote: > Why was relrewrite / Anum_pg_class_relrewrite inserted at position 28, > not appended to pg_class? > > I don't see how it'd cause any harm, I'm just curious about the rationale. Adding it at the end would not be appropriate, since those are variable-length

pg_basebackup: Missing newlines in some error messages

Hi, while working on something else, I noticed that some error messages in pg_basebackup do not have a "\n" at the end, resulting in output like: |pg_basebackup: could not get COPY data stream: pg_basebackup: removing |data directory "data2" Patch attached. Michael -- Michael Banck

Re: pg_basebackup: Missing newlines in some error messages

Michael Banck wrote: > Hi, > > Am Mittwoch, den 21.03.2018, 09:54 -0300 schrieb Alvaro Herrera: > > Michael Banck wrote: > > > I apparently managed to screw up so badly that no PQerrorMessage was > > > set, so saw the above (which indeed has no error message after the > > > colon). > > > > Well,

Re: Fwd: [BUGS] pg_trgm word_similarity inconsistencies or bug

On Tue, Mar 6, 2018 at 7:59 PM, David Steele wrote: > On 3/6/18 7:04 AM, Teodor Sigaev wrote: > >> I agree with Teodor (upthread, not quoted here) that the documentation > >> could use some editing. > >> > >> I started to do it myself, but quickly realized I have no

Re: pg_basebackup: Missing newlines in some error messages

Hi, Am Mittwoch, den 21.03.2018, 09:46 -0300 schrieb Alvaro Herrera: > Daniel Gustafsson wrote: > > > On 21 Mar 2018, at 13:12, Michael Banck wrote: > > > while working on something else, I noticed that some error messages in > > > pg_basebackup do not have a "\n" at

Re: Hash join in SELECT target list expression keeps consuming memory

Hi, We still get out of memory error during pg_dump execution bin$ ./initdb -D /tmp/test The files belonging to this database system will be owned by user "jsoler". This user must also own the server process. The database cluster will be initialized with locale "es_ES.UTF-8". The default

Re: [HACKERS] taking stdbool.h into use

On 3/21/18 01:51, Tom Lane wrote: > Andres Freund writes: >> On March 20, 2018 8:24:41 PM PDT, Michael Paquier >> wrote: >>> Yeah, I agree with that. Just not using stdbool.h in those cases ought >>> to be fine. Any platforms where sizeof(bool) is 4

Re: Fwd: [BUGS] pg_trgm word_similarity inconsistencies or bug

Thank you, pushed David Steele wrote: On 3/6/18 7:04 AM, Teodor Sigaev wrote: I agree with Teodor (upthread, not quoted here) that the documentation could use some editing. I started to do it myself, but quickly realized I have no knowledge of the content.  I'm afraid I would destroy the

Re: pg_basebackup: Missing newlines in some error messages

Daniel Gustafsson wrote: > > On 21 Mar 2018, at 13:12, Michael Banck wrote: > > > while working on something else, I noticed that some error messages in > > pg_basebackup do not have a "\n" at the end, resulting in output like: > > > > |pg_basebackup: could not get

Re: pg_basebackup: Missing newlines in some error messages

Hi, Am Mittwoch, den 21.03.2018, 09:54 -0300 schrieb Alvaro Herrera: > Michael Banck wrote: > > I apparently managed to screw up so badly that no PQerrorMessage was > > set, so saw the above (which indeed has no error message after the > > colon). > > Well, maybe that's a different bug, then:

pg_basebackup: Allow setting replication slots in recovery.conf even if wal-method is none

Hi, per suggestion from my colleague Christoph Berg, it seems to make sense to allow setting the (permanent) replication slot in recovery.conf even if we don't stream WAL, i.e. allow pg_basebackup -D foo -R --slot=foo -C -X none Currently you get an error message "replication slots can only be

Re: JIT compiling with LLVM v12.2

On Thu, Mar 22, 2018 at 10:59 AM, Andres Freund wrote: > On 2018-03-22 10:50:52 +1300, Thomas Munro wrote: >> Hmm. There is no LLVM 6 in backports. > > I think there now is: > https://packages.debian.org/search?keywords=llvm=names=all=stretch-backports > > Package

Re: JIT compiling with LLVM v12.2

Hi, On 2018-03-22 11:36:47 +1300, Thomas Munro wrote: > On Thu, Mar 22, 2018 at 10:59 AM, Andres Freund wrote: > > On 2018-03-22 10:50:52 +1300, Thomas Munro wrote: > >> Hmm. There is no LLVM 6 in backports. > > > > I think there now is: > >

Re: JIT compiling with LLVM v12.2

On Thu, Mar 22, 2018 at 11:46 AM, Andres Freund wrote: > On 2018-03-22 11:36:47 +1300, Thomas Munro wrote: >> Not sure if we'll want to try to actively identify and avoid known >> buggy versions or not? > > I'm currently not inclined to invest a lot of effort into it, besides

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

> On 12 March 2018 at 06:00, Ashutosh Bapat > wrote: > Thanks for the note. Here are rebased patches. Since I started to look at this patch, I can share few random notes (although it's not a complete review, I'm in the progress now), maybe it can be helpful. In

Re: Jsonb transform for pl/python

On 3/12/18 11:26, Nikita Glukhov wrote: > I have reviewed this patch. Attached new 6th version of the patch with > v5-v6 delta-patch. Thanks for the update. I'm working on committing this. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support,

Re: JIT compiling with LLVM v12.2

On Wed, Mar 21, 2018 at 8:06 PM, Thomas Munro wrote: > "make -C src/interfaces/ecpg/test check" consistently fails on my macOS > machine: > > test compat_oracle/char_array ... stderr source FAILED I can't reproduce this anymore on the tip of your jit branch.

Re: [HACKERS] path toward faster partition pruning

On 2018/03/20 21:41, David Rowley wrote: > On 21 March 2018 at 00:07, Amit Langote wrote: >> Attached is further revised version. > > In the 0004 patch I see: > > @@ -1439,6 +1441,10 @@ inheritance_planner(PlannerInfo *root) > if (IS_DUMMY_PATH(subpath)) >

Re: ON CONFLICT DO UPDATE for partitioned tables

On Tue, Mar 20, 2018 at 10:09 AM, Amit Langote < langote_amit...@lab.ntt.co.jp> wrote: > On 2018/03/20 13:30, Amit Langote wrote: > > I have incorporated your patch in the main patch after updating the > > comments a bit. Also, now that ee49f49 is in [1], the transition > > table related

Re: [HACKERS] Partition-wise aggregation/grouping

On Thu, Mar 22, 2018 at 3:26 AM, Robert Haas wrote: > > Is there a good reason not to use input_rel->relids as the input to > fetch_upper_rel() in all cases, rather than just at subordinate > levels? > That would simplify some code in these patches. We have set

Re: Removing useless DISTINCT clauses

On 21 March 2018 at 16:29, Melanie Plageman wrote: > For a small performance hit but an improvement in readability, the length > check > can be moved from the individual group by and distinct clause checks into the > helper function > > if

Re: constraint exclusion and nulls in IN (..) clause

Emre Hasegeli writes: > I am not sure if we are covering the case when clause_const and > pred_const are both NULL. In this case, we should be able to return > true only by checking op_strict(pred_op) or maybe even without > checking that. Am I mistaken? Yeah, that's there.

Re: Re: Re: reorganizing partitioning code

David Steele wrote: > > Sorry about the confusing comment. It could be sometime later half of > > the next week. > > We are now three weeks into the CF with no new patch. > > Are you planning to update this patch? If not, I think it should be > marked as Returned with Feedback and submitted

Re: Hash join in SELECT target list expression keeps consuming memory

On 03/21/2018 02:18 PM, Jaime Soler wrote: > Hi, > > We still get out of memory error during pg_dump execution > ... > pg_dump: reading row security enabled for table "public.lo_table" > pg_dump: reading policies for table "public.lo_table" > pg_dump: reading publications > pg_dump: reading

Re: Re: Re: reorganizing partitioning code

Hi Amit, On 3/2/18 11:17 AM, Amit Langote wrote: > > On Fri, Mar 2, 2018 at 11:53 PM, David Steele wrote: >> Hi Amit, >> >> On 2/16/18 3:36 AM, Amit Langote wrote: >>> >>> Attached updated version. >> >> This patch no longer applies and the conflicts do not appear to be

Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two

On 3/6/18 4:12 PM, Tom Lane wrote: > Peter Eisentraut writes: >> On 3/4/18 16:09, Andrew Dunstan wrote: >>> If you want to do this soon I can put out a Buildfarm Client release >>> fairly quickly. > >> I think the dependency is mostly the other way around. How

Re: [HACKERS] Partition-wise aggregation/grouping

On Wed, Mar 21, 2018 at 8:01 AM, Jeevan Chalke wrote: >> In the patch as proposed, create_partial_grouping_paths() can get >> called even if GROUPING_CAN_PARTIAL_AGG is not set. I think that's >> wrong. > > I don't think so. For parallel case, we do check that.

Re: Re: new function for tsquery creartion

Hi Victor, On 3/5/18 7:52 AM, Aleksander Alekseev wrote: > It seems that this patch doesn't apply anymore, see > http://commitfest.cputube.org/ > > The new status of this patch is: Waiting on Author This patch needs a rebase and should address the comments from Aleksander and Andres. We are

Re: General purpose hashing func in pgbench

I finally managed to perform this test on sparc v9 machine which is 64 bit big-endian architecture. I run pgbench script (see previous message) with default_seed=123 on both x86-64 and sparc machines and visualized the results. You can find them in the attached chart. Both images showed the same

Re: pgsql: Fix CommandCounterIncrement in partition-related DDL

Alvaro Herrera wrote: > Alvaro Herrera wrote: > > Alvaro Herrera wrote: > > > Fix CommandCounterIncrement in partition-related DDL > > > > Hmm, Prion seems unhappy about this. Looking > > Here's a patch that seems to fix the problem, and generally looks sane > to me. Pushed, after editing a

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

On Wed, Mar 21, 2018 at 01:40:23AM -0400, Tom Lane wrote: > Michael Paquier writes: >> On Tue, Mar 20, 2018 at 01:27:35PM -0400, Tom Lane wrote: >>> + if (flags & GUC_LIST_QUOTE) >>> + elog(FATAL, "extensions cannot define GUC_LIST_QUOTE >>> variables");

Re: [PoC PATCH] Parallel dump to /dev/null

On Wed, Mar 21, 2018 at 09:07:41AM +0100, Michael Banck wrote: > Am Dienstag, den 20.03.2018, 19:19 -0400 schrieb Stephen Frost: >> Instead of trying to use pg_dump for this, we should provide a way to >> actually check for corruption across everything (instead of just the >> heap..), and have all

Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two

On Wed, Mar 21, 2018 at 10:51:04AM -0400, David Steele wrote: > On 3/6/18 4:12 PM, Tom Lane wrote: > It seems the consensus is that we'll need a build farm update before we > can move forward with the patch and that we don't need to wait long for > people to upgrade. > > Andrew, do you have a

Re: Faster inserts with mostly-monotonically increasing values

On Mon, Mar 19, 2018 at 12:06 PM, Claudio Freire wrote: > On Mon, Mar 19, 2018 at 11:57 AM, Pavan Deolasee > wrote: >> >> >> On Thu, Mar 15, 2018 at 7:51 AM, Claudio Freire >> wrote: >>> >>> >>> >>> I applied the attached

Re: Boolean partitions syntax

Hi David. On 2018/03/21 23:31, David Steele wrote: > Hi Amit, > > On 3/6/18 9:44 AM, David Steele wrote: >> On 3/2/18 2:27 AM, Amit Langote wrote: >>> On 2018/03/02 15:58, Andres Freund wrote: On 2018-02-02 17:00:24 -0500, Tom Lane wrote: > Peter Eisentraut

Re: JIT compiling with LLVM v12.2

On Thu, Mar 22, 2018 at 1:36 PM, Thomas Munro wrote: > I've now run out of things to complain about for now. Nice work! I jumped on a POWER8 box. As expected, the same breakage occurs. So I hacked LLVM 6.0 thusly: diff --git

Re: faster testing with symlink installs

On Wed, Mar 07, 2018 at 05:06:59PM -0500, Robert Haas wrote: > TBH I find that Homebrew example pretty odd. I would understand > installing each major release in a version directory, but putting > every point release in a different versioned directory seems like a > bad plan. That's a project

Re: [HACKERS] logical decoding of two-phase transactions

Hi Nikhil, I've been looking at this patch over the past few days, so here are my thoughts so far ... decoding aborted transactions = First, let's talk about handling of aborted transaction, which was originally discussed in thread [1]. I'll try to summarize the

Re: [HACKERS] taking stdbool.h into use

On Wed, Mar 21, 2018 at 07:48:02AM -0400, Peter Eisentraut wrote: > I've pushed the configure tests. Let's see what they say. At least the buildfarm is green. Browsing the buildfarm logs manually is kind of annoying for any normal human being. I guess that you have access to the database

Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two

On Thu, Mar 22, 2018 at 09:42:35AM +0800, Craig Ringer wrote: > I'm super excited by the idea of multi-version support in TAP, if that's > what you mean. > > Why? Because I use TAP heavily in extensions. Especially replication > extensions. Which like to talk across multiple versions. I currently

Re: Multiple-output-file make rules: We're Doing It Wrong

I wrote: > I looked for rules with this bug by looking for comments that > mention parser/Makefile. There may well be some more, but I have > no good idea how to find them --- any thoughts? I realized that grepping for line-ending semicolons in makefiles would be a pretty efficient way to check

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

Michael Paquier writes: > On Wed, Mar 21, 2018 at 01:40:23AM -0400, Tom Lane wrote: >> I don't mind making it an ereport, but I think it needs to be FATAL >> for the reason stated in the comment. > Okay for the FATAL. I can see that at this time of the day your patch > 0002

Re: Re: Rewriting the test of pg_upgrade as a TAP test - take two

On 22 March 2018 at 09:39, Michael Paquier wrote: > On Wed, Mar 21, 2018 at 10:51:04AM -0400, David Steele wrote: > > On 3/6/18 4:12 PM, Tom Lane wrote: > > It seems the consensus is that we'll need a build farm update before we > > can move forward with the patch and that

Re: [HACKERS] taking stdbool.h into use

Michael Paquier writes: > On Wed, Mar 21, 2018 at 07:48:02AM -0400, Peter Eisentraut wrote: >> I've pushed the configure tests. Let's see what they say. > At least the buildfarm is green. Browsing the buildfarm logs manually > is kind of annoying for any normal human

Re: file cloning in pg_upgrade and CREATE DATABASE

On Tue, Mar 20, 2018 at 10:55:04AM -0400, Peter Eisentraut wrote: > On 3/19/18 22:58, Michael Paquier wrote: >> - Extend copy_file so as it is able to use fcopyfile. > > fcopyfile() does not support cloning. (This is not documented.) You are right. I have been reading the documentation here to

Re: JIT compiling with LLVM v12.2

Hi, On 2018-03-22 16:09:51 +1300, Thomas Munro wrote: > On Thu, Mar 22, 2018 at 1:36 PM, Thomas Munro > wrote: > > I've now run out of things to complain about for now. Nice work! > > I jumped on a POWER8 box. As expected, the same breakage occurs. So > I

pg_stat_statements HLD for futur developments

Hello Kackers, As a new user of PostgreSQL, I have started using pg_stat_statements, and was pleased but a little surprised: First of all, the normalized form of the query string makes it impossible to be used in EXPLAIN commands. Second, normalized constants and parameters values where missing

Re: FOR EACH ROW triggers on partitioned tables

Here's v8, which addresses all your comments except the doc updates. I added a few more tests, too. Thanks for the review! I intend to commit this shortly, probably not before Friday to give some more time for others to review/comment. Some notes: Peter Eisentraut wrote: > I'm not sure why

Re: Re: Re: Boolean partitions syntax

Hi Amit, On 3/6/18 9:44 AM, David Steele wrote: > On 3/2/18 2:27 AM, Amit Langote wrote: >> On 2018/03/02 15:58, Andres Freund wrote: >>> On 2018-02-02 17:00:24 -0500, Tom Lane wrote: Peter Eisentraut writes: > There might be other options, but one way

Re: pgbench randomness initialization

Patch isn't applyed cleanly anymore. Fabien COELHO wrote: But now the documentation is back to its original state of silence on what base or how many bases might be allowed. Could it just say "or an unsigned decimal integer value"? Then no one will wonder. Done in the attached. Thanks for

  1   2   >