Re: [BDR] Question on compatibility of Postgres with Open JDK

Criag, Thanks a lot for the prompt reply. >From what you mentioned, I assume that other the client side jdbc there is no Java dependency from Server side. What I mean is I assume there is no jdk/java dependency for Postgres server to work. Request your input. Thanks Pratheej On Wed, Jan 30, 201

Question on compatibility of Postgres with Open JDK

Hello, We are using Postgresql (postgresql-bdr94). Please let us know whether Postgresql supports Open JDK? Thanks Pratheej

Unused parameters & co in code

Hi all, I just got a run with CFLAGS with the following options: -Wunused-function -Wunused-variable -Wunused-const-variable -Wno-unused-result -Wunused-parameter -Wunused-macros And while this generates a lot of noise for callbacks and depending on the environment used, this is also pointing to

Re: jsonpath

Hi, On 2019-01-30 07:34:00 +0300, Alexander Korotkov wrote: > Thank you for your review! Let me answer some points of your review > while others will be answered later. > > On Wed, Jan 30, 2019 at 5:28 AM Andres Freund wrote: > > On 2019-01-29 04:00:19 +0300, Alexander Korotkov wrote: > > > +/*

Re: [BDR] Question on compatibility of Postgres with Open JDK

I don't understand the question. If you want to use PgJDBC, then yes, PgJDBC works on OpenJDK. You do not need to use pgjdbc 9.4 with PostgreSQL 9.4, you may use the latest version. If you want to use pl/java, then I don't know if it's been tested with postgres-bdr 9.4. But it should work fine if

RE: [HACKERS][PATCH] Applying PMDK to WAL operations for persistent memory

Hi, Sorry but I found that the patchset v2 had a bug in managing WAL segment file offset. I fixed it and updated a patchset as v3 (attached). Regards, Takashi -- Takashi Menjo - NTT Software Innovation Center 0001-Add-configure-option-for-PMDK-v3.patch Description: Binary data 0002-Read-

Re: FETCH FIRST clause PERCENT option

On Mon, Jan 28, 2019 at 1:28 AM Tomas Vondra wrote: > > > OK. Does that mean you agree the incremental approach is reasonable? > there are no noticeable performance difference but i love previous approach more regarding cursor operation it fetch tuple forward and backward from tuplestore only bu

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

On Tue, Jan 29, 2019 at 09:51:35PM +0100, Peter Eisentraut wrote: > On 16/01/2019 09:27, Michael Paquier wrote: >> index_create does not actually need its extra argument with the tuple >> descriptor. I think that we had better grab the column name list from >> indexInfo and just pass that down to

RE: Protect syscache from bloating with negative cache entries

Hi >> > I suggest you go with just syscache_prune_min_age, get that into PG >> > 12, and we can then reevaluate what we need. If you want to >> > hard-code a minimum cache size where no pruning will happen, maybe >> > based on the system catalogs or typical load, that is fine. >> >> Please forgiv

Re: Early WIP/PoC for inlining CTEs

On Tuesday, January 29, 2019, Tom Lane wrote: > Merlin Moncure writes: > > On Tue, Jan 29, 2019 at 1:53 PM Tom Lane wrote: > >> I propose that we implement and document this as > >> WITH ctename AS [ MATERIALIZE { ON | OFF } ] ( query ) > > > I hate to bikeshed here, but I think it's better eng

Re: jsonpath

Hi! Thank you for your review! Let me answer some points of your review while others will be answered later. On Wed, Jan 30, 2019 at 5:28 AM Andres Freund wrote: > On 2019-01-29 04:00:19 +0300, Alexander Korotkov wrote: > > +/*INPUT/OUTPUT

RE: speeding up planning with partitions

On Wed, Jan 30, 2019 at 3:26 PM, Alvaro Herrera wrote: > On 2019-Jan-30, Imai, Yoshikazu wrote: > > > Why I did these tests is that I wanted to confirm that even if we > > apply each patch one by one, there's no performance problem. Because > > patches are quite large, I just felt it might be diff

Re: ALTER SESSION

At Tue, 29 Jan 2019 21:46:28 -0500, Stephen Frost wrote in <20190130024628.ge5...@tamriel.snowman.net> > Greetings, > > * Andres Freund (and...@anarazel.de) wrote: > > On 2019-01-29 21:09:22 -0500, Stephen Frost wrote: > > > * Andres Freund (and...@anarazel.de) wrote: > > > > On 2019-01-29 20:52

Re: Early WIP/PoC for inlining CTEs

David Fetter writes: > On Tue, Jan 29, 2019 at 02:52:44PM -0500, Tom Lane wrote: >> I propose that we implement and document this as >> WITH ctename AS [ MATERIALIZE { ON | OFF } ] ( query ) > I think this would be better with parentheses like this: > WITH ctename [ ( MATERIALIZE { ON | OFF

Re: WIP: Avoid creation of the free space map for small tables

On Tue, Jan 29, 2019 at 8:12 PM John Naylor wrote: > > On Tue, Jan 29, 2019 at 11:56 AM Amit Kapila wrote: > > > You can find this change in attached patch. Then, I ran the make > > check in src/bin/pgbench multiple times using test_conc_insert.sh. > > You can vary the number of times the test s

Re: speeding up planning with partitions

On 2019-Jan-30, Imai, Yoshikazu wrote: > Why I did these tests is that I wanted to confirm that even if we > apply each patch one by one, there's no performance problem. Because > patches are quite large, I just felt it might be difficult to commit > these patches all at once and I thought committ

RE: speeding up planning with partitions

Amit-san, On Tue, Jan 29, 2019 at 10:11 AM, Amit Langote wrote: > On 2019/01/28 10:44, Imai, Yoshikazu wrote: > > On Thu, Jan 24, 2019 at 6:10 AM, Imai, Yoshikazu wrote: > >> updating partkey case: > >> > >> part-num master 0001 0002 0003 0004 > >> 18215.34 7924.99 7931.

RE: [HACKERS] Cached plans and statement generalization

Hi, On Mon, Jan 28, 2019 at 10:46 PM, Konstantin Knizhnik wrote: > Rebased version of the patch is attached. Thank you for your quick rebase. > This files are just output of test execution and it is not possible to expect > lack of > trailing spaces in output of test scripts execution. I underst

Re: ALTER SESSION

Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2019-01-29 21:09:22 -0500, Stephen Frost wrote: > > * Andres Freund (and...@anarazel.de) wrote: > > > On 2019-01-29 20:52:08 -0500, Stephen Frost wrote: > > > > * Andres Freund (and...@anarazel.de) wrote: > > > > > Leaving the desirabilit

Re: Early WIP/PoC for inlining CTEs

On Tue, Jan 29, 2019 at 02:52:44PM -0500, Tom Lane wrote: > Michael Paquier writes: > > On Mon, Jan 28, 2019 at 05:05:32PM -0500, Tom Lane wrote: > >> Yeah, I thought about that too, but it doesn't seem like an improvement. > >> If the query is very long (which isn't unlikely) I think people would

Re: jsonpath

Hi, On 2019-01-29 04:00:19 +0300, Alexander Korotkov wrote: > +/* > + * Make datetime type from 'date_txt' which is formated at argument 'fmt'. > + * Actual datatype (returned in 'typid', 'typmod') is determined by > + * presence of date/time/zone components in the format string. > + */ > +Datum >

Re: Control your disk usage in PG: Introduction to Disk Quota Extension

Hi Michael, Robert For you question about the hook position, I want to explain more about the background why we want to introduce these hooks. We wrote a diskquota extension for Postgresql(which is inspired by Heikki's pg_quota

Re: ALTER SESSION

On 2019-01-29 21:09:22 -0500, Stephen Frost wrote: > Greetings, > > * Andres Freund (and...@anarazel.de) wrote: > > On 2019-01-29 20:52:08 -0500, Stephen Frost wrote: > > > * Andres Freund (and...@anarazel.de) wrote: > > > > Leaving the desirability of the feature aside, isn't this racy as hell? >

Re: speeding up planning with partitions

On Tue, 29 Jan 2019 at 22:32, Amit Langote wrote: > > On 2019/01/29 11:23, David Rowley wrote: > > 7. In set_inherit_target_rel_sizes() I still don't really like the way > > you're adjusting the EquivalenceClasses. Would it not be better to > > invent a function similar to adjust_appendrel_attrs()

Re: ALTER SESSION

Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2019-01-29 20:52:08 -0500, Stephen Frost wrote: > > * Andres Freund (and...@anarazel.de) wrote: > > > Leaving the desirability of the feature aside, isn't this racy as hell? > > > I.e. it seems entirely possible that backends stop/start b

Re: ALTER SESSION

On 2019-01-29 20:52:08 -0500, Stephen Frost wrote: > * Andres Freund (and...@anarazel.de) wrote: > > Leaving the desirability of the feature aside, isn't this racy as hell? > > I.e. it seems entirely possible that backends stop/start between > > determining the PID, and the ALTER SESSION creating t

Re: [PATCH] Pass COPT and PROFILE to CXXFLAGS as well

Hi, On 2019-01-29 16:18:46 +0100, Christoph Berg wrote: > Re: Michael Paquier 2019-01-23 <20190123004722.ge3...@paquier.xyz> > > >> Largely because I think it's an independent patch from the CXXOPT need > > >> from Christopher / Debian packaging. It's a larger patch, that needs > > >> more docs e

Re: ALTER SESSION

Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2019-01-29 20:32:54 +0900, Kyotaro HORIGUCHI wrote: > > Hello. > > > > https://www.postgresql.org/message-id/20190128.133143.115303042.horiguchi.kyot...@lab.ntt.co.jp > > > > > C. Provide session-specific GUC variable (that overides the

Re: [HACKERS] Restricting maximum keep segments by repslots

At Thu, 20 Dec 2018 16:24:38 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20181220.162438.121484007.horiguchi.kyot...@lab.ntt.co.jp> > Thank you for piking this and sorry being late. > > At Mon, 19 Nov 2018 13:39:58 +0900, Michael Paquier > wrote in <20181119043958.ge4...@paquier.

Re: [PATCH] Pass COPT and PROFILE to CXXFLAGS as well

On Tue, Jan 29, 2019 at 04:18:46PM +0100, Christoph Berg wrote: > Re backpatching, I would at least need them in PG11 because that's > what is going to be released with Debian buster. An official backpatch > to all supported versions would be nice, but I could also sneak in > that change into the D

Re: ALTER SESSION

Hi, On 2019-01-29 20:32:54 +0900, Kyotaro HORIGUCHI wrote: > Hello. > > https://www.postgresql.org/message-id/20190128.133143.115303042.horiguchi.kyot...@lab.ntt.co.jp > > > C. Provide session-specific GUC variable (that overides the global one) > >- Add new configuration file "postgresql.co

Re: ALTER SESSION

At Tue, 29 Jan 2019 20:32:54 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20190129.203254.115361483.horiguchi.kyot...@lab.ntt.co.jp> > Hello. > > https://www.postgresql.org/message-id/20190128.133143.115303042.horiguchi.kyot...@lab.ntt.co.jp > > > C. Provide session-specific GUC va

Re: [HACKERS] WAL logging problem in 9.4.3?

Rebased. regards. -- Kyotaro Horiguchi NTT Open Source Software Center >From d5f2b47b6ba191d0ad1673f9bd9c5851d91a1b59 Mon Sep 17 00:00:00 2001 From: Kyotaro Horiguchi Date: Thu, 11 Oct 2018 10:03:21 +0900 Subject: [PATCH 1/4] TAP test for copy-truncation optimization. --- src/test/recovery/t/

Re: Covering GiST indexes

On 29/01/2019 19.58, Andrey Borodin wrote: PFA patch without redundant checks. I hope it is ok that I fixed a typo and some wording in the comment, plus re-added the btree query which I accidentally removed in my last mail. I think the current state of the patch is fine, assuming the solutio

Re: [HACKERS] Block level parallel vacuum

On Thu, Jan 24, 2019 at 1:16 PM Masahiko Sawada wrote: > > Attached the latest patches. > Thanks for the updated patches. Some more code review comments. + started by a single utility command. Currently, the parallel + utility commands that support the use of parallel workers a

Re: A few new options for vacuumdb

On Tue, Jan 29, 2019 at 09:48:18PM +, Bossart, Nathan wrote: > On 1/28/19, 6:35 PM, "Michael Paquier" wrote: >> -" ON c.relnamespace OPERATOR(pg_catalog.=) ns.oid\n"); >> +" ON c.relnamespace OPERATOR(pg_catalog.=) ns.oid\n" >> +" LEFT JOIN pg_catalog.pg_class t" >> +" ON c.rel

Re: COPY FROM WHEN condition

Hi, On 2019-01-30 10:33:30 +1300, David Rowley wrote: > On Wed, 30 Jan 2019 at 10:12, Andres Freund wrote: > > > > On 2019-01-30 10:05:35 +1300, David Rowley wrote: > > > On Wed, 30 Jan 2019 at 04:22, Andres Freund wrote: > > > > I think I might have a patch addressing the problem incidentally.

Re: COPY FROM WHEN condition

On Wed, 30 Jan 2019 at 10:12, Andres Freund wrote: > > On 2019-01-30 10:05:35 +1300, David Rowley wrote: > > On Wed, 30 Jan 2019 at 04:22, Andres Freund wrote: > > > I think I might have a patch addressing the problem incidentally. For > > > pluggable storage I slotified copy.c, which also remov

Re: COPY FROM WHEN condition

Hi, On 2019-01-30 10:05:35 +1300, David Rowley wrote: > On Wed, 30 Jan 2019 at 04:22, Andres Freund wrote: > > I think I might have a patch addressing the problem incidentally. For > > pluggable storage I slotified copy.c, which also removes the first > > heap_form_tuple. Quite possible that no

Re: COPY FROM WHEN condition

On Tue, 29 Jan 2019 at 22:51, Tomas Vondra wrote: > > On 1/29/19 8:18 AM, David Rowley wrote: > > So looks like your change slows this code down 4% for this test case. > > That's about twice as bad as the 2.2% regression that I had to solve > > for the multi-insert partition patch (of which you've

Re: COPY FROM WHEN condition

On Wed, 30 Jan 2019 at 04:22, Andres Freund wrote: > I think I might have a patch addressing the problem incidentally. For > pluggable storage I slotified copy.c, which also removes the first > heap_form_tuple. Quite possible that nothing more is needed. I've removed the > batch context altoget

Re: COPY FROM WHEN condition

On Wed, 30 Jan 2019 at 03:26, Tomas Vondra wrote: > > On 1/29/19 8:18 AM, David Rowley wrote: > > (details about performance regression) > > How do I reproduce this? I don't see this test in the thread you linked, > so I'm not sure how many partitions you were using, what's the structure > of the

Re: Early WIP/PoC for inlining CTEs

On 1/29/19 3:36 PM, Merlin Moncure wrote: > I hate to bikeshed here, but I think it's better english using that > style of syntax to say, > WITH ctename AS [ MATERIALIZATION { ON | OFF } ] ( query ) I had been just about to also engage in bikeshedding, on grounds that (to me) the MATERIALIZED/NOT

Re: [HACKERS] REINDEX CONCURRENTLY 2.0

Here is an updated patch, which addresses some of your issues below as well as the earlier reported issue that comments were lost during REINDEX CONCURRENTLY. On 16/01/2019 09:27, Michael Paquier wrote: > On Fri, Jan 04, 2019 at 03:18:06PM +0300, Sergei Kornilov wrote: >> NOTICE seems unnecessary

Re: Early WIP/PoC for inlining CTEs

Merlin Moncure writes: > On Tue, Jan 29, 2019 at 1:53 PM Tom Lane wrote: >> I propose that we implement and document this as >> WITH ctename AS [ MATERIALIZE { ON | OFF } ] ( query ) > I hate to bikeshed here, but I think it's better english using that > style of syntax to say, > WITH ctename A

Re: Why are we PageInit'ing buffers in RelationAddExtraBlocks()?

On 2019-01-29 11:25:41 -0800, Andres Freund wrote: > While chatting with Robert about this issue I came across the following > section of code: > > /* >* If the FSM knows nothing of the rel, try the last page > before we >* give up and extend. This a

Re: Early WIP/PoC for inlining CTEs

On Tue, Jan 29, 2019 at 1:53 PM Tom Lane wrote: > > Michael Paquier writes: > > On Mon, Jan 28, 2019 at 05:05:32PM -0500, Tom Lane wrote: > >> Yeah, I thought about that too, but it doesn't seem like an improvement. > >> If the query is very long (which isn't unlikely) I think people would > >> p

Re: Why are we PageInit'ing buffers in RelationAddExtraBlocks()?

On 2019-01-29 11:25:41 -0800, Andres Freund wrote: > On 2019-01-28 22:37:53 -0500, Tom Lane wrote: > > Andres Freund writes: > > > I did that now. I couldn't reproduce it locally, despite a lot of > > > runs. Looking at the buildfarm it looks like the failures were, > > > excluding handfish which

Re: pg_upgrade: Pass -j down to vacuumdb

Hi, On 1/29/19 12:08 AM, Michael Paquier wrote: On Tue, Jan 29, 2019 at 12:35:30AM +, Jamison, Kirk wrote: I just checked the patch. As per advice, you removed the versioning and specified --jobs. The patch still applies, builds and passed the tests successfully. I would document the opti

Re: Early WIP/PoC for inlining CTEs

Michael Paquier writes: > On Mon, Jan 28, 2019 at 05:05:32PM -0500, Tom Lane wrote: >> Yeah, I thought about that too, but it doesn't seem like an improvement. >> If the query is very long (which isn't unlikely) I think people would >> prefer to see the option(s) up front. > Having these options

Re: Fixing findDependentObjects()'s dependency on scan order (regressions in DROP diagnostic messages)

Alvaro Herrera writes: > On 2019-Jan-18, Peter Geoghegan wrote: >> I thought that your ALTER OBJECT DEPENDS ON EXTENSION example made the >> case for fixing that directly inarguable. I'm slightly surprised that >> you're not fully convinced of this already. Have I missed some >> subtlety? > I agr

Re: Why are we PageInit'ing buffers in RelationAddExtraBlocks()?

On 2019-01-28 22:37:53 -0500, Tom Lane wrote: > Andres Freund writes: > > I did that now. I couldn't reproduce it locally, despite a lot of > > runs. Looking at the buildfarm it looks like the failures were, > > excluding handfish which failed without recognizable symptoms before and > > after, on

Re: ATTACH/DETACH PARTITION CONCURRENTLY

On Fri, Jan 25, 2019 at 4:18 PM Alvaro Herrera wrote: > > I wrote a little patch that stores the relation OIDs of the partitions > > into the PartitionedPruneRelInfo and then, at execution time, does an > > Assert() that what it gets matches what existed at plan time. I > > figured that a good st

Re: Covering GiST indexes

> 29 янв. 2019 г., в 23:43, Andreas Karlsson написал(а): > > On 29/01/2019 18.45, Andrey Borodin wrote: >> Also, I've unified gist and r-tree syntax tests for INCLUDE. > > Why not just keep it simple? The purpose is not to test the GiST indexes, for > that we have index_including_gist.sql. >

Re: Covering GiST indexes

On 29/01/2019 18.45, Andrey Borodin wrote: Also, I've unified gist and r-tree syntax tests for INCLUDE. Why not just keep it simple? The purpose is not to test the GiST indexes, for that we have index_including_gist.sql. I propose the following. /* * 7. Check various AMs. All but btree and

Re: Covering GiST indexes

Thanks! Here's new version 8 > 29 янв. 2019 г., в 22:00, Andreas Karlsson написал(а): > > * I think it is worth writing a short comment when you create truncTupdesc > about why this is done. It resulted in not so short comment, but I think it is OK. > > * Very minor thing: the diff below is po

Ltree syntax improvement

Dear all, Please find attached the patch extending the sets of symbols allowed in ltree labels. The patch introduces 2 variants of escaping symbols, via backslashing separate symbols and via quoting the labels in whole for ltree, lquery and ltxtquery datatypes. -- SY, Dmitry Belyavsky diff --git

Re: Covering GiST indexes

On 29/01/2019 18.00, Andreas Karlsson wrote: Thanks for the new version of the patch. Based on my knowledge of PG this is starting to look good, and I have only three small comments below. Sorry, I missed retree in the tests. Can you fix the below to match the gist example? CREATE INDEX on

Re: Covering GiST indexes

Thanks for the new version of the patch. Based on my knowledge of PG this is starting to look good, and I have only three small comments below. I am not 100% a fan of truncTupdesc, but as long as it is well commented I think that it is fine. = Review * I think it is worth writing a short com

Re: ATTACH/DETACH PARTITION CONCURRENTLY

On Tue, Jan 29, 2019 at 12:29 AM Simon Riggs wrote: >> But I kind of wonder whether we're really gaining as much as you think >> by trying to support concurrent DETACH in the first place. If there >> are queries running against the table, there's probably at least >> AccessShareLock on the partit

Re: Rename nodes/relation.h => nodes/pathnodes.h ?

Hi, On 2019-01-29 10:31:39 -0500, Tom Lane wrote: > Alvaro Herrera writes: > > On 2019-Jan-28, Tom Lane wrote: > > I do like planner/pathnodes.h as a name, FWIW. > > Yeah, I think I'll go with pathnodes.h. We'd probably keep using that > for the Path node typedefs themselves, even if somebody c

Re: Follow-up on INSERT INTO ... SET ...

On Tue, Jan 29, 2019 at 6:26 PM Sven Berkvens-Matthijsse < s...@postgresql.berkvens.net> wrote: > On 29/01/2019 07.20, Tom Lane wrote: > > Looking at the thread, it seems like Marko lost interest for some > > reason, and never submitted a revised patch. > > That was my conclusion too, but I didn't

Re: [HACKERS] Transactions involving multiple postgres foreign servers, take 2

Hello, The patch needs rebase as it doesn't apply to the current master. I applied it to the older commit to test it. It worked fine so far. I found one bug though which would cause resolver to finish by timeout even though there are unresolved foreign transactions in the list. The `fdw_xact_exis

Re: "could not reattach to shared memory" on buildfarm member dory

On Thu, Jan 17, 2019 at 3:27 AM Noah Misch wrote: > On Sun, Dec 02, 2018 at 09:35:06PM -0800, Noah Misch wrote: > > On Tue, Sep 25, 2018 at 08:05:12AM -0700, Noah Misch wrote: > > > On Mon, Sep 24, 2018 at 01:53:05PM -0400, Tom Lane wrote: > > > > Overall, I agree that neither of these approaches

Re: Follow-up on INSERT INTO ... SET ...

Hi Tom, On 29/01/2019 07.20, Tom Lane wrote: Sven Berkvens-Matthijsse writes: In 2016, a thread was started about implementing INSERT INTO ... SET ... that included a patch and was basically ready for inclusion in PostgreSQL. However, it seems as though it stagnated for some reason. Does anybo

Re: Why does execReplication.c lock tuples?

On 29/01/2019 17:14, Andres Freund wrote: > Hi > > On January 29, 2019 8:04:55 AM PST, Petr Jelinek > wrote: >> On 29/01/2019 16:28, Andres Freund wrote: >>> Hi, >>> >>> On January 29, 2019 4:19:52 AM PST, Petr Jelinek >> wrote: Hi, On 20/01/2019 21:03, Andres Freund wrote: >

Re: Why does execReplication.c lock tuples?

Hi On January 29, 2019 8:04:55 AM PST, Petr Jelinek wrote: >On 29/01/2019 16:28, Andres Freund wrote: >> Hi, >> >> On January 29, 2019 4:19:52 AM PST, Petr Jelinek > wrote: >>> Hi, >>> >>> On 20/01/2019 21:03, Andres Freund wrote: Hi, Currently RelationFindReplTupleByIndex(), >Re

Re: pg_basebackup, walreceiver and wal_sender_timeout

Greetings, I also would like to thank everyone for looking into this. On Sat, Jan 26, 2019 at 01:45:46PM +0100, Magnus Hagander wrote: > One workaround you could perhaps look at here is to run pg_basebackup > with --no-sync. That way there will be no fsyncs issued while running. You > will then of

Re: Why does execReplication.c lock tuples?

On 29/01/2019 16:28, Andres Freund wrote: > Hi, > > On January 29, 2019 4:19:52 AM PST, Petr Jelinek > wrote: >> Hi, >> >> On 20/01/2019 21:03, Andres Freund wrote: >>> Hi, >>> >>> Currently RelationFindReplTupleByIndex(), RelationFindReplTupleSeq() >>> lock the found tuple. I don't quite get wh

Re: Allowing extensions to supply operator-/function-specific info

Simon Riggs writes: > On Tue, 29 Jan 2019 at 09:55, Tom Lane wrote: >> I have no particular >> interest in working on that right now, because it doesn't respond to >> what I understand PostGIS' need to be, and there are only so many >> hours in the day. But maybe it could be made workable in the

Re: pgsql: Build src/port files as a library with -fPIC, and use that in li

Re: Tom Lane 2019-01-29 <27653.1548774...@sss.pgh.pa.us> > > It took a while to notice, but this change does break 8.2's initdb if > > libpq5 from PG12 is installed: > > $ /usr/lib/postgresql/8.2/bin/initdb > > /usr/lib/postgresql/8.2/bin/initdb: symbol lookup error: > > /usr/lib/postgresql/8.2/bi

Re: [PATCH] Log PostgreSQL version number on startup

Re: Peter Eisentraut 2019-01-16 <92bfdfdf-4164-aec5-4e32-c26e67821...@2ndquadrant.com> > > Why don't we start the logging collector before opening the sockets? > > Specifically, something like the attached. > > This keeps the dynamic module loading before the logging collector > start, so we see

Re: Rename nodes/relation.h => nodes/pathnodes.h ?

Alvaro Herrera writes: > On 2019-Jan-28, Tom Lane wrote: >> (There was some mention of trying to split relation.h into multiple >> files, but I fail to see any advantage in that.) > Hmm, nodes/relation.h includes lots of other files and is widely > included. Yup, that's why I'm trying to reduce

Re: Why does execReplication.c lock tuples?

Hi, On January 29, 2019 4:19:52 AM PST, Petr Jelinek wrote: >Hi, > >On 20/01/2019 21:03, Andres Freund wrote: >> Hi, >> >> Currently RelationFindReplTupleByIndex(), RelationFindReplTupleSeq() >> lock the found tuple. I don't quite get what that achieves - why >isn't >> dealing with concurrency

Re: COPY FROM WHEN condition

Hi, On January 29, 2019 6:25:59 AM PST, Tomas Vondra wrote: >On 1/29/19 8:18 AM, David Rowley wrote: >> ... >> Here are my performance tests of with and without your change to the >> memory contexts (I missed where you posted your results). >> >> $ cat bench.pl >> for (my $i=0; $i < 8912891; $i

Re: [PATCH] Pass COPT and PROFILE to CXXFLAGS as well

Re: Michael Paquier 2019-01-23 <20190123004722.ge3...@paquier.xyz> > >> Largely because I think it's an independent patch from the CXXOPT need > >> from Christopher / Debian packaging. It's a larger patch, that needs > >> more docs etc. If whoever applies that wants to backpatch it - I'm not > >>

Re: pgsql: Build src/port files as a library with -fPIC, and use that in li

Christoph Berg writes: > Re: Tom Lane 2018-09-28 <20671.1538142...@sss.pgh.pa.us> >> I proposed in >> https://www.postgresql.org/message-id/19581.1538077...@sss.pgh.pa.us >> that we should remove pqsignal, as well as >> pg_utf_mblen >> pg_encoding_to_char >> pg_char_to_encoding >> pg_valid_server_

Re: WIP: Avoid creation of the free space map for small tables

On Tue, Jan 29, 2019 at 11:56 AM Amit Kapila wrote: > You can find this change in attached patch. Then, I ran the make > check in src/bin/pgbench multiple times using test_conc_insert.sh. > You can vary the number of times the test should run, if you are not > able to reproduce it with this. > >

Re: COPY FROM WHEN condition

On 1/29/19 8:18 AM, David Rowley wrote: > ... > Here are my performance tests of with and without your change to the > memory contexts (I missed where you posted your results). > > $ cat bench.pl > for (my $i=0; $i < 8912891; $i++) { > print "1\n1\n2\n2\n"; > } > 36a1281f86c: (with your change) >

Re: pgsql: Build src/port files as a library with -fPIC, and use that in li

Re: Tom Lane 2018-09-28 <20671.1538142...@sss.pgh.pa.us> > >> I proposed in > >> https://www.postgresql.org/message-id/19581.1538077...@sss.pgh.pa.us > >> > >> that we should remove pqsignal, as well as > >> pg_utf_mblen > >> pg_encoding_to_char > >> pg_char_to_encoding > >> pg_valid_server_encodi

Re: pg_basebackup, walreceiver and wal_sender_timeout

> On 29. Jan 2019, at 10:45, Magnus Hagander wrote: > > On Tue, Jan 29, 2019 at 6:19 AM Michael Paquier > wrote: > On Mon, Jan 28, 2019 at 02:00:59PM +0100, Alex Kliukin wrote: > > While reading the doc page for the pg_basebackup, I've been confused > > by the fact

Re: move hash_any to utils/hash/hashfn.c

Hello On 2019-Jan-25, Andres Freund wrote: > I hate the current split quite a bit, albeit for somewhat different > reasons. We make things like tag_hash, uint32_hash unnecessarily more > expensive by adding an entirely useless external function call. And > some of these can be fairly hot (e.g. fo

Re: pg_dump multi VALUES INSERT

On 2019-Jan-23, David Rowley wrote: > On Wed, 23 Jan 2019 at 04:08, Alvaro Herrera wrote: > > Is it possible to avoid the special case for 0 columns by using the > > UNION ALL syntax I showed? > > It would be possible, but my thoughts are that we're moving away from > the SQL standard by doing s

Re: pg_basebackup, walreceiver and wal_sender_timeout

On Tue, Jan 29, 2019 at 10:45:34AM +0100, Magnus Hagander wrote: > Since you also agreed on it, I went ahead and pushed (with backpatch). Thanks for taking care of it, Magnus. -- Michael signature.asc Description: PGP signature

Re: pg_stat_ssl additions

At Tue, 29 Jan 2019 13:50:17 +0900, Michael Paquier wrote in <20190129045017.gc3...@paquier.xyz> > On Tue, Jan 29, 2019 at 12:18:29PM +0900, Kyotaro HORIGUCHI wrote: > > At Mon, 28 Jan 2019 14:53:43 +0100, Peter Eisentraut > > wrote in > > <24783370-5acd-e0f3-8eb7-7f42ff2a0...@2ndquadrant.com>

Re: Why does execReplication.c lock tuples?

Hi, On 20/01/2019 21:03, Andres Freund wrote: > Hi, > > Currently RelationFindReplTupleByIndex(), RelationFindReplTupleSeq() > lock the found tuple. I don't quite get what that achieves - why isn't > dealing with concurrency in the table_update/delete calls at the > callsites sufficient? As far a

Re: WIP: Avoid creation of the free space map for small tables

On Tue, Jan 29, 2019 at 5:20 PM Masahiko Sawada wrote: > > On Tue, Jan 29, 2019 at 9:29 AM Amit Kapila wrote: > > > > I'd suspect the alignment of integer. In my environemnt, the tuple > actual size is 28 bytes but the aligned size is 32 bytes (= > MAXALIGN(28)), so we can store 226 tuples to sin

Re: pg_stat_ssl additions

On 29/01/2019 04:18, Kyotaro HORIGUCHI wrote: > Some further investigation told me that the file > ~/.postgresql/root.cert was the culprit. OK, I could reproduce the problem and found a fix for it. Basically you need to specify sslrootcert in each test, and these new tests didn't do it. All othe

Re: Thread-unsafe coding in ecpg

> I like having a hard limit on the number of loop iterations; > that should ensure that the test terminates no matter how confused > ecpglib is. I get your point and thus will only clean up the tests a little bit. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De

Re: [WIP] CREATE SUBSCRIPTION with FOR TABLES clause (table filter)

Hi! 1. done 2. rename to pg_user_subscriptions 3. by pg_dump, i checked upgrade from 10 to 12devel, it's work fine 4. done 5. done 6. I took it from AlterSubscription_refresh, in that function no any free() 7. done Ефимкин Евгений diff --git a/doc/src/sgml/logical-replication.sgml b/doc/

Re: WIP: Avoid creation of the free space map for small tables

On Tue, Jan 29, 2019 at 9:29 AM Amit Kapila wrote: > > On Tue, Jan 29, 2019 at 12:37 AM John Naylor > wrote: > > > > On Mon, Jan 28, 2019 at 12:10 PM Amit Kapila > > wrote: > > > > > 2. > > > @@ -15,13 +15,9 @@ > > > SELECT octet_length(get_raw_page('test_rel_forks', 'main', 100)) AS > > > ma

ALTER SESSION

Hello. https://www.postgresql.org/message-id/20190128.133143.115303042.horiguchi.kyot...@lab.ntt.co.jp > C. Provide session-specific GUC variable (that overides the global one) >- Add new configuration file "postgresql.conf." and > pg_reload_conf() let the session with the PID loads it a

Re: WIP: Avoid creation of the free space map for small tables

On Tue, Jan 29, 2019 at 5:59 AM Amit Kapila wrote: > > On Tue, Jan 29, 2019 at 12:37 AM John Naylor > wrote: > > > I think here you need to clear the map if it exists or clear it > > > unconditionally, the earlier one would be better. > > > > Ok, maybe all callers should call it unconditonally, b

Re: [HACKERS] Cached plans and statement generalization

On 29.01.2019 4:38, Nagaura, Ryohei wrote: Hi, Although I became your reviewer, it seems to be difficult to feedback in this CF. I continue to review, so would you update your patch please? Until then I review your current patch. There is one question. date_1.out which maybe is copy of date.

Re: speeding up planning with partitions

Imai-san, On 2019/01/28 10:44, Imai, Yoshikazu wrote: > On Thu, Jan 24, 2019 at 6:10 AM, Imai, Yoshikazu wrote: >> updating partkey case: >> >> part-num master 0001 0002 0003 0004 >> 18215.34 7924.99 7931.15 8407.40 8475.65 >> 27137.49 7026.45 7128.84 7583.0

Re: COPY FROM WHEN condition

On 1/29/19 8:18 AM, David Rowley wrote: > On Wed, 23 Jan 2019 at 06:35, Tomas Vondra > wrote: >> It turned out to be a tad more complex due to partitioning, because when >> we find the partitions do not match, the tuple is already allocated in >> the "current" context (be it per-tuple or batch

Re: pg_basebackup, walreceiver and wal_sender_timeout

On Tue, Jan 29, 2019 at 6:19 AM Michael Paquier wrote: > On Mon, Jan 28, 2019 at 02:00:59PM +0100, Alex Kliukin wrote: > > While reading the doc page for the pg_basebackup, I've been confused > > by the fact that it says WAL files will be written to .tarballs > > (either base.tar or pg_wal.tar) w

Re: Built-in connection pooler

On 29.01.2019 8:14, Michael Paquier wrote: On Mon, Jan 28, 2019 at 10:33:06PM +0100, Dimitri Fontaine wrote: In other cases, it's important to measure and accept the possible performance cost of running a proxy server between the client connection and the PostgreSQL backend process. I believe

Re: Built-in connection pooler

On 29.01.2019 0:10, Bruce Momjian wrote: On Thu, Jan 24, 2019 at 08:14:41PM +0300, Konstantin Knizhnik wrote: The main differences with pgbouncer&K are that: 1. It is embedded and requires no extra steps for installation and configurations. 2. It is not single threaded (no bottleneck) 3. It

RE: static global variable openLogOff in xlog.c seems no longer used

Michael Paquier wrote: > It seems to me that keeping openLogOff is still useful to get a report > about the full chunk area being written if the data gets written in > multiple chunks and fails afterwards. Your patch would modify the > report so as only the area with the partial write is reported.

  1   2   >