Re: [HACKERS] Restricting maximum keep segments by repslots

Oops! The previous patch is forgetting the default case and crashes. At Wed, 08 Nov 2017 13:14:31 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20171108.131431.170534842.horiguchi.kyot...@lab.ntt.co.jp> > > I don't think 'distance' is a good metric -

Re: [HACKERS] (spelling) Ensure header of postgresql.auto.conf is consistent

Em qui, 9 de nov de 2017 às 06:15, Feike Steenbergen < feikesteenber...@gmail.com> escreveu: > Attached a patch that ensures the header of postgresql.auto.conf is > consistent, whether created by initdb or recreated when ALTER SYSTEM > is issued. > > The tiny difference caused some

Re: [HACKERS] proposal - Default namespaces for XPath expressions (PostgreSQL 11)

Hi 2017-11-06 14:00 GMT+01:00 Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp>: > Thank you for the new patch. > > - The latest patch is missing xpath_parser.h at least since > ns-3. That of the first (not-numbered) version was still > usable. > > - c29c578 conflicts on

Re: [HACKERS] (spelling) Ensure header of postgresql.auto.conf is consistent

On Thu, Nov 9, 2017 at 6:25 PM, Fabrízio de Royes Mello wrote: > Interesting... IMHO this typo should be backpatched to 9.4 when ALTER SYSTEM > was introduced. Yeah, that's harmless. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

[HACKERS] (spelling) Ensure header of postgresql.auto.conf is consistent

Attached a patch that ensures the header of postgresql.auto.conf is consistent, whether created by initdb or recreated when ALTER SYSTEM is issued. The tiny difference caused some false-positives on our configuration management identifying changes, which was enough of an itch for me to scratch.

Re: [HACKERS] [PATCH] Improve geometric types

Hello, > I'd like to put comments on 0001 and 0004 only now: ... I don't have a comment on 0002. About 0003: > @@ -4487,21 +4486,21 @@ circle_in(PG_FUNCTION_ARGS) > ... > circle->radius = single_decode(s, , "circle", str); > - if (circle->radius < 0) > + if

Re: [HACKERS] path toward faster partition pruning

On Mon, Nov 6, 2017 at 3:31 PM, Amit Langote wrote: > On 2017/11/06 14:32, David Rowley wrote: >> On 6 November 2017 at 17:30, Amit Langote wrote: >>> On 2017/11/03 13:32, David Rowley wrote: On 31 October 2017 at 21:43, Amit Langote wrote: [] > > Attached

[HACKERS] libpq connection strings: control over the cipher suites?

Hi all, According to the docs at https://www.postgresql.org/docs/9.5/static/libpq-connect.html#LIBPQ-CONNSTRING there are various parameters that control ssl from the client side, including providing the ssl certs, keys, etc. Is there a parameter or mechanism for setting the required ssl

Re: [HACKERS] Fix bloom WAL tap test

On Wed, Nov 8, 2017 at 5:46 AM, Masahiko Sawada wrote: > > So I think > > that you should instead do something like that: > > > > --- a/contrib/bloom/Makefile > > +++ b/contrib/bloom/Makefile > > @@ -20,5 +20,12 @@ include $(top_builddir)/src/Makefile.global > > include

Re: [HACKERS] Runtime Partition Pruning

Hello all, Here is the updated patch which is rebased over v10 of Amit Langote's path towards faster pruning patch [1]. It modifies the PartScanKeyInfo struct to hold expressions which is then evaluated by the executor to fetch the correct partitions using the function. The code still chooses

Re: [HACKERS] why not parallel seq scan for slow functions

On Wed, Nov 8, 2017 at 6:48 PM, Robert Haas wrote: > On Wed, Nov 8, 2017 at 7:26 AM, Amit Kapila wrote: >> We do want to generate it later when there isn't inheritance involved, >> but only if there is a single rel involved (simple_rel_array_size

Re: [HACKERS] Proposal: Improve bitmap costing for lossy pages

Hi Dilip, v6 patch: 42 + /* 43 +* Estimate number of hashtable entries we can have within maxbytes. This 44 +* estimates the hash cost as sizeof(PagetableEntry). 45 +*/ 46 + nbuckets = maxbytes / 47 + (sizeof(PagetableEntry) + sizeof(Pointer) + sizeof(Pointer)); It

Re: [HACKERS] Runtime Partition Pruning

On Thu, Nov 9, 2017 at 6:18 AM, Beena Emerson wrote: > The code still chooses the custom plan instead of the generic plan for > the prepared statements. I am working on it. I don't think it's really the job of this patch to do anything about that problem. -- Robert

[HACKERS] Reorder header files in alphabetical order

Hi, Attached is a patch to reorder header files in joinrels.c and pathnode.c in alphabetical order, removing unnecessary ones. Best regards, Etsuro Fujita *** a/src/backend/optimizer/path/joinrels.c --- b/src/backend/optimizer/path/joinrels.c *** *** 16,30 #include

Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager

On Wed, Nov 8, 2017 at 9:40 AM, Masahiko Sawada wrote: > Speaking of the acquiring these four lock types and heavy weight lock, > there obviously is a call path to acquire any of four lock types while > holding a heavy weight lock. In reverse, there also is a call path >

Re: [HACKERS] Jsonb transform for pl/python

The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed Hello Anthony, Great job! I decided to take a closer look

Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager

Robert Haas writes: > No, that's not right. Now that you mention it, I realize that tuple > locks can definitely cause deadlocks. Example: Yeah. Foreign-key-related tuple locks are another rich source of examples. > ... So I don't > think we can remove speculative

Re: [HACKERS] A weird bit in pg_upgrade/exec.c

Alvaro Herrera writes: > I think odd coding this was introduced recently because of the > pg_resetxlog -> pg_resetwal renaming. Dunno about that, but certainly somebody fat-fingered a refactoring there. The 9.6 code looks quite different but doesn't seem to be doing

Re: [HACKERS] libpq connection strings: control over the cipher suites?

On 11/09/2017 03:27 AM, Graham Leggett wrote: > Is there a parameter or mechanism for setting the required ssl cipher list > from the client side? I don't believe so. That is controlled by ssl_ciphers, which requires a restart in order to change.

[HACKERS] Aggregates push-down to partitions

There is a huge thread concerning pushing-down aggregates to FDW: https://www.postgresql.org/message-id/flat/CAFjFpRcnueviDpngJ3QSVvj7oyukr9NkSiCspqd4N%2BdCEdvYvg%40mail.gmail.com#cafjfprcnuevidpngj3qsvvj7oyukr9nksicspqd4n+dcedv...@mail.gmail.com but as far as I understand nothing is done for

[HACKERS] pageinspect option to forgo buffer locking?

Hi, Occasionally, when debugging issues, I find it quite useful to be able to do a heap_page_items() on a page that's actually locked exclusively concurrently. E.g. investigating the recent multixact vacuuming issues, it was very useful to attach a debugger to one backend to step through

Re: [HACKERS] pageinspect option to forgo buffer locking?

On 2017-11-09 12:55:30 -0500, Robert Haas wrote: > On Thu, Nov 9, 2017 at 12:49 PM, Andres Freund wrote: > > Occasionally, when debugging issues, I find it quite useful to be able > > to do a heap_page_items() on a page that's actually locked exclusively > > concurrently. E.g.

Re: [HACKERS] Pg V10: Patch for bug in bonjour support

Thomas Munro writes: > On Thu, Nov 9, 2017 at 6:27 PM, Tom Lane wrote: >> Is there really much interest in Bonjour support on non-macOS platforms? >> I hadn't heard that anybody but Apple was invested in it. > Not from me. My only interest

Re: [HACKERS] (spelling) Ensure header of postgresql.auto.conf is consistent

=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes: > Em qui, 9 de nov de 2017 às 06:15, Feike Steenbergen < > feikesteenber...@gmail.com> escreveu: >> Attached a patch that ensures the header of postgresql.auto.conf is >> consistent, whether created by initdb or recreated

Re: [HACKERS] A weird bit in pg_upgrade/exec.c

a.akent...@postgrespro.ru wrote: > This function has two calls: > check_bin_dir(_cluster); > check_bin_dir(_cluster); > > I'd like to substitute these last two lines with this: > get_bin_version(cluster); Odd indeed. One would think that if a cluster variable is passed as parameter, the global

Re: [HACKERS] pageinspect option to forgo buffer locking?

On Thu, Nov 9, 2017 at 9:49 AM, Andres Freund wrote: > Currently the locking in get_raw_page_internal() prevents that. If it's > an option defaulting to off, I don't see why we couldn't allow that to > skip locking the page's contents. Obviously you can get corrupted >

Re: [HACKERS] pageinspect option to forgo buffer locking?

On Thu, Nov 9, 2017 at 12:58 PM, Andres Freund wrote: > You can already pass arbitrary byteas to heap_page_items(), so I don't > see how this'd change anything exposure-wise? Or are you thinking that > users would continually do this with actual page contents and would be >

Re: [HACKERS] A weird bit in pg_upgrade/exec.c

a.akent...@postgrespro.ru writes: > I've came across a weird bit in pg_upgrade/exec.c > We have a function check_bin_dir() which goes like this (old_cluster and > new_cluster are global variables): > void check_bin_dir(ClusterInfo *cluster) > { > ... > get_bin_version(_cluster); >

Re: [HACKERS] pageinspect option to forgo buffer locking?

On Thu, Nov 9, 2017 at 12:49 PM, Andres Freund wrote: > Occasionally, when debugging issues, I find it quite useful to be able > to do a heap_page_items() on a page that's actually locked exclusively > concurrently. E.g. investigating the recent multixact vacuuming issues, >

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

Michael Paquier writes: > On Thu, Nov 9, 2017 at 6:05 AM, Tom Lane wrote: >> Another idea would be to invent a new external flag bit "INV_WRITE_ONLY", >> so that people who wanted true write-only could get it, without breaking >>

Re: [HACKERS] [PATCH] A hook for session start

On Thu, Nov 9, 2017 at 12:09 AM, Michael Paquier wrote: > > On Thu, Nov 9, 2017 at 2:42 AM, Fabrízio de Royes Mello > wrote: > > On Wed, Nov 8, 2017 at 12:47 AM, Michael Paquier < michael.paqu...@gmail.com> > > wrote: > >> - Let's restrict the

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

On Thu, Nov 9, 2017 at 1:52 PM, Stephen Frost wrote: >> I disagree that that is, or should be, a guiding principle. > > It was what I was using as the basis of the work which I did in this > area and, at least at that time, there seemed to be little issue with > that. Well,

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

On Thu, Nov 9, 2017 at 2:56 PM, Stephen Frost wrote: > I agree that it may not be obvious which cases lead to a relatively easy > way to obtain superuser and which don't, and that's actually why I'd > much rather it be something that we're considering and looking out for >

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

Tom, Michael, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Michael Paquier writes: > > On Thu, Nov 9, 2017 at 6:05 AM, Tom Lane wrote: > >> Another idea would be to invent a new external flag bit "INV_WRITE_ONLY", > >> so that people who wanted true

Re: [HACKERS] proposal: psql command \graw

Hi 2017-08-24 5:50 GMT+02:00 Fabien COELHO : > > Hello Pavel, > > I have added the patch to the next commitfest. > > Patch applies, compiles, works. > > I'm okay with the names graw/graw+, and for having such short-hands. > > Missing break in switch, even if last item and

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Thu, Nov 9, 2017 at 1:16 PM, Stephen Frost wrote: > > While we have been working to reduce the number of superuser() checks in > > the backend in favor of having the ability to GRANT explicit rights, one > > of the

Re: [HACKERS] why not parallel seq scan for slow functions

On Thu, Nov 9, 2017 at 3:47 AM, Amit Kapila wrote: > I think I understood your concern after some offlist discussion and it > is primarily due to the inheritance related check which can skip the > generation of gather paths when it shouldn't. So what might fit > better

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Thu, Nov 9, 2017 at 1:52 PM, Stephen Frost wrote: > > This is not unlike the discussions we've had in the past around allowing > > non-owners of a table to modify properties of a table, where the > > argument has been

Re: [HACKERS] [PATCH] Improve geometric types

>> This is also effecting lseg ## box operator. > > Mmm.. It returns (1.5, 1.5) with the 0004 patch. It is surely a > point on the second operand but I'm not sure it's right that the > operator returns a specific point for two parallel segments. I am changing it to return NULL, when they are

Re: [HACKERS] proposal: psql command \graw

Hello Pavel, I hope so I fixed all mentioned issues. Patch applies with a warning: > git apply ~/psql-graw-2.patch /home/fabien/psql-graw-2.patch:192: new blank line at EOF. + warning: 1 line adds whitespace errors. Otherwise it compiles. "make check" ok. doc gen ok. Two spurious

Re: [HACKERS] proposal: psql command \graw

2017-11-09 21:03 GMT+01:00 Fabien COELHO : > > Hello Pavel, > > I hope so I fixed all mentioned issues. >> > > Patch applies with a warning: > > > git apply ~/psql-graw-2.patch > /home/fabien/psql-graw-2.patch:192: new blank line at EOF. > + > warning: 1 line adds

[HACKERS] Inlining functions with "expensive" parameters

All, As we try and make PostGIS more "parallel sensitive" we have been added costs to our functions, so that their relative CPU cost is more accurately reflected in parallel plans. This has resulted in an odd side effect: some of our "wrapper" functions stop giving index scans in plans [1]. This

Re: [HACKERS] Parallel Append implementation

On Sat, Oct 28, 2017 at 5:50 AM, Robert Haas wrote: > No, because the Append node is *NOT* getting copied into shared > memory. I have pushed a comment update to the existing functions; you > can use the same comment for this patch. I spent the last several days working

Re: [HACKERS] [POC] Faster processing at Gather node

On Thu, Nov 9, 2017 at 12:08 AM, Amit Kapila wrote: > This change looks suspicious to me. I think here we can't use the > tupDesc constructed from targetlist. One problem, I could see is that > the check for hasOid setting in tlist_matches_tupdesc won't give the >

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

On Thu, Nov 9, 2017 at 1:16 PM, Stephen Frost wrote: > While we have been working to reduce the number of superuser() checks in > the backend in favor of having the ability to GRANT explicit rights, one > of the guideing principles has always been that capabilities which can >

Re: [HACKERS] Aggregates push-down to partitions

Hi Konstantin! 09.11.17 20:14, Konstantin Knizhnik wrote: It is still far from ideal plan because each worker is working with all partitions, instead of spitting partitions between workers and calculate partial aggregates for each partition. But if we add FDW as a child of parent table,

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

Robert Haas writes: > On Thu, Nov 9, 2017 at 2:56 PM, Stephen Frost wrote: >> Further, I agree entirely that we >> shouldn't be deciding that certain capabilities are never allowed to be >> given to a user- but that's why superuser *exists* and why it's

Re: [HACKERS] pageinspect option to forgo buffer locking?

Robert Haas writes: > On Thu, Nov 9, 2017 at 12:58 PM, Andres Freund wrote: >> You can already pass arbitrary byteas to heap_page_items(), so I don't >> see how this'd change anything exposure-wise? Or are you thinking that >> users would continually do

[HACKERS] OpeSSL - PostgreSQL

Hi All, I am using PostgreSQL version *9.5.7* on Red hat enterprise Linux *7.2.* *OpenSSL version : * OpenSSL 1.0.1e-fips 11 Feb 2013. I have a requirement to enable the SSL in my environment with specific cipher suites,we want to restrict weak cipher suites from open SSL default list. We have

[HACKERS] different content of pg_depend after pg_upgrade

Hi We checked some check query based on some operations on pg_depend table. This query did different result when database was migrated with pg_dump or with pg_upgrade. I found so this query was broken, but I found interesting thing. The count is 1 for any objid select distinct count(distinct

Re: [HACKERS] pageinspect option to forgo buffer locking?

On 2017-11-09 17:14:11 -0500, Tom Lane wrote: > If we do this, I'd suggest exposing it as a separate SQL function > get_raw_page_unlocked() rather than as an option to get_raw_page(). > > The reasoning is that if we ever allow these functions to be controlled > via GRANT instead of hardwired

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

On Fri, Nov 10, 2017 at 7:05 AM, Tom Lane wrote: > I did miss the need to fix the docs, and am happy to put in some strong > wording about the security hazards of these functions while fixing the > docs. But I do not think that leaving them with hardwired superuser > checks

Re: [HACKERS] [POC] hash partitioning

On Wed, Nov 1, 2017 at 6:16 AM, amul sul wrote: > Fixed in the 0003 patch. I have committed this patch set with the attached adjustments. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company hash-adjustments.patch Description: Binary

Re: [HACKERS] libpq connection strings: control over the cipher suites?

On Fri, Nov 10, 2017 at 2:53 AM, Joe Conway wrote: > On 11/09/2017 03:27 AM, Graham Leggett wrote: >> Is there a parameter or mechanism for setting the required ssl cipher list >> from the client side? > > I don't believe so. That is controlled by ssl_ciphers, which requires

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Thu, Nov 9, 2017 at 2:56 PM, Stephen Frost wrote: > > Further, I agree entirely that we > > shouldn't be deciding that certain capabilities are never allowed to be > > given to a user- but that's why superuser *exists*

Re: [HACKERS] libpq connection strings: control over the cipher suites?

On 11/09/2017 03:17 PM, Michael Paquier wrote: > On Fri, Nov 10, 2017 at 2:53 AM, Joe Conway wrote: >> On 11/09/2017 03:27 AM, Graham Leggett wrote: >>> Is there a parameter or mechanism for setting the required ssl cipher list >>> from the client side? >> >> I don't believe

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

Michael Paquier writes: > On Fri, Nov 10, 2017 at 7:05 AM, Tom Lane wrote: >> I did miss the need to fix the docs, and am happy to put in some strong >> wording about the security hazards of these functions while fixing the >> docs. But I do not

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

On Thu, Nov 9, 2017 at 2:24 PM, Andres Freund wrote: > Attached is a version of the already existing regression test that both > reproduces the broken hot chain (and thus failing index lookups) and > then also the tuple reviving. I don't see any need for letting this run >

Re: [HACKERS] path toward faster partition pruning

Hi Amul. On 2017/11/09 20:05, amul sul wrote: > On Mon, Nov 6, 2017 at 3:31 PM, Amit Langote > wrote: >> On 2017/11/06 14:32, David Rowley wrote: >>> On 6 November 2017 at 17:30, Amit Langote wrote: On 2017/11/03 13:32, David Rowley wrote: > On 31 October

Re: [HACKERS] [PATCH] A hook for session start

On Fri, Nov 10, 2017 at 2:32 AM, Fabrízio de Royes Mello wrote: > On Thu, Nov 9, 2017 at 12:09 AM, Michael Paquier > wrote: >> +++ b/src/test/modules/test_session_hooks/session_hooks.conf >> @@ -0,0 +1 @@ >> +shared_preload_libraries =

Re: [HACKERS] pg_basebackup --progress output for batch execution

On Fri, Sep 29, 2017 at 4:00 PM, Martin Marques < martin.marq...@2ndquadrant.com> wrote: > Hi, > > Some time ago I had to work on a system where I was cloning a standby > using pg_basebackup, that didn't have screen or tmux. For that reason I > redirected the output to a file and ran it with

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

On 2017-11-09 16:02:17 -0800, Peter Geoghegan wrote: > > What I'm currently wondering about is how much we need to harden > > postgres against such existing corruption. If e.g. the hot chains are > > broken somebody might have reindexed thinking the problem is fixed - but > > if they then later

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

On 2017-11-04 06:15:00 -0700, Andres Freund wrote: > The reason for that is that I hadn't yet quite figured out how the bug I > described in the commit message (and the previously committed testcase) > would cause that. I was planning to diagnose / experiment more with this > and write an email if

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

On Thu, Nov 9, 2017 at 4:17 PM, Andres Freund wrote: >> I don't follow you here. Why would REINDEXing make the rows that >> should be dead disappear again, even for a short period of time? > > It's not the REINDEX that makes them reappear. Of course. I was just trying to make

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

On Thu, Nov 9, 2017 at 4:17 PM, Andres Freund wrote: >> Actually, on second thought, I take that back -- I don't think that >> REINDEXing will even finish once a HOT chain is broken by the bug. >> IndexBuildHeapScan() actually does quite a good job of making sure >> that HOT

Re: [HACKERS] Runtime Partition Pruning

On Thu, Nov 9, 2017 at 9:01 PM, Robert Haas wrote: > On Thu, Nov 9, 2017 at 6:18 AM, Beena Emerson wrote: >> The code still chooses the custom plan instead of the generic plan for >> the prepared statements. I am working on it. > > I don't think

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

On Fri, Nov 10, 2017 at 10:00 AM, Tom Lane wrote: > Stephen Frost writes: >> I'm guessing no, which essentially means that *we* consider access to >> lo_import/lo_export to be equivilant to superuser and therefore we're >> not going to implement anything

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

On 2017-11-09 16:45:07 -0800, Peter Geoghegan wrote: > On Thu, Nov 9, 2017 at 4:17 PM, Andres Freund wrote: > >> Actually, on second thought, I take that back -- I don't think that > >> REINDEXing will even finish once a HOT chain is broken by the bug. > >>

Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

Stephen Frost writes: > I'm guessing no, which essentially means that *we* consider access to > lo_import/lo_export to be equivilant to superuser and therefore we're > not going to implement anything to try and prevent the user who has > access to those functions from becoming

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

On Thu, Nov 9, 2017 at 4:53 PM, Andres Freund wrote: > Primarily because it's not an anti-corruption tool. I'd be surprised if > there weren't ways to corrupt the page using these corruptions that > aren't detected by it. It's very hard to assess the risk of missing something

Re: [HACKERS] [POC] Faster processing at Gather node

On Fri, Nov 10, 2017 at 12:05 AM, Robert Haas wrote: > On Thu, Nov 9, 2017 at 12:08 AM, Amit Kapila wrote: >> This change looks suspicious to me. I think here we can't use the >> tupDesc constructed from targetlist. One problem, I could see is

Re: [HACKERS] [POC] Faster processing at Gather node

On Thu, Nov 9, 2017 at 9:31 PM, Amit Kapila wrote: > Have you set force_parallel_mode=regress; before running the > statement? Yes, I tried that first. > If so, then why you need to tune other parallel query > related parameters? Because I couldn't get it to break the

[HACKERS] User defined data types in Logical Replication

Hi, We are getting the bellow error while trying use Logical Replication with user defined data types in a C program (when call elog function). ERROR: XX000: cache lookup failed for type X # X is remote type's oid It occurs in worker.c:slot_store_error_callback function when

Re: [HACKERS] Fix bloom WAL tap test

On Thu, Nov 9, 2017 at 7:51 PM, Alexander Korotkov wrote: > On Wed, Nov 8, 2017 at 5:46 AM, Masahiko Sawada > wrote: >> > So I think >> > that you should instead do something like that: >> > >> > --- a/contrib/bloom/Makefile >> > +++

Re: [HACKERS] path toward faster partition pruning

Hello, this is the second part of the review. At Fri, 10 Nov 2017 12:30:00 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20171110.123000.151902771.horiguchi.kyot...@lab.ntt.co.jp> > In 0002, bms_add_range has a bit naive-looking loop > In 0003, In

Re: [HACKERS] [POC] hash partitioning

On Fri, Nov 10, 2017 at 4:41 AM, Robert Haas wrote: > On Wed, Nov 1, 2017 at 6:16 AM, amul sul wrote: >> Fixed in the 0003 patch. > > I have committed this patch set with the attached adjustments. > Thanks a lot for your support & a ton of thanks to all

Re: [HACKERS] path toward faster partition pruning

Ooops! The following comment is wrong. Please ignore it. At Fri, 10 Nov 2017 14:38:11 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20171110.143811.97616847.horiguchi.kyot...@lab.ntt.co.jp> > Those two conditions are not orthogonal. Maybe something

Re: [HACKERS] proposal: psql command \graw

2017-11-09 21:12 GMT+01:00 Pavel Stehule : > > > 2017-11-09 21:03 GMT+01:00 Fabien COELHO : > >> >> Hello Pavel, >> >> I hope so I fixed all mentioned issues. >>> >> >> Patch applies with a warning: >> >> > git apply ~/psql-graw-2.patch >>

Re: [HACKERS] pg_basebackup --progress output for batch execution

Hello, On Sun, Oct 01, 2017 at 04:49:17PM -0300, Martin Marques wrote: > Updated patch with documentation of the new option. > I have checked the patch. The patch is applied and compiled correctly without any errors. Tests passed. The documentation doesn't have errors too. I have a little

[HACKERS] A weird bit in pg_upgrade/exec.c

Hello! I've came across a weird bit in pg_upgrade/exec.c We have a function check_bin_dir() which goes like this (old_cluster and new_cluster are global variables): void check_bin_dir(ClusterInfo *cluster) { ... get_bin_version(_cluster); get_bin_version(_cluster); ... } This

Re: [HACKERS] path toward faster partition pruning

Hello, At Fri, 10 Nov 2017 09:34:57 +0900, Amit Langote wrote in <5fcb1a9f-b4ad-119d-14c7-282c30c7f...@lab.ntt.co.jp> > Hi Amul. > > On 2017/11/09 20:05, amul sul wrote: > > On Mon, Nov 6, 2017 at 3:31 PM, Amit Langote > > wrote:

Re: [HACKERS] [POC] Faster processing at Gather node

On Fri, Nov 10, 2017 at 8:36 AM, Robert Haas wrote: > On Thu, Nov 9, 2017 at 9:31 PM, Amit Kapila wrote: >> Have you set force_parallel_mode=regress; before running the >> statement? > > Yes, I tried that first. > >> If so, then why you need to

Re: [HACKERS] path toward faster partition pruning

Hello, At Fri, 10 Nov 2017 14:44:55 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20171110.144455.117208639.horiguchi.kyot...@lab.ntt.co.jp> > > Those two conditions are not orthogonal. Maybe something like > > following seems more understantable. >

Re: [HACKERS] proposal: psql command \graw

ISTM that you can remove "force_column_header" and just set "tuple_only" to what you need, that is you do not need to change anything in function "print_unaligned_text". Last point is not possible - I would not to break original tuple only mode. Hmmm... I do not understand. I can see only

Re: [HACKERS] proposal: psql command \graw

2017-11-10 8:12 GMT+01:00 Fabien COELHO : > > ISTM that you can remove "force_column_header" and just set "tuple_only" >>> to what you need, that is you do not need to change anything in function >>> "print_unaligned_text". >>> >> >> Last point is not possible - I would not

[HACKERS] pg audit requirements

Hi I am sending some notes, experience about usage of pgAudit. pgAudit provides basic functionality and usually is good enough. But it is not good enough for some applications in financial services. The requirements: 1. structured output - attached query is not good enough - column name, table

Re: [HACKERS] path toward faster partition pruning

On 10 November 2017 at 16:30, Kyotaro HORIGUCHI wrote: > In 0002, bms_add_range has a bit naive-looking loop > > + while (wordnum <= uwordnum) > + { > + bitmapword mask = (bitmapword) ~0; > + > + /* If working on the lower

Re: [HACKERS] UPDATE of partition key

On 9 November 2017 at 09:27, Thomas Munro wrote: > On Wed, Nov 8, 2017 at 5:57 PM, Amit Khandekar wrote: >> On 8 November 2017 at 07:55, Thomas Munro >> wrote: >>> On Tue, Nov 7, 2017 at 8:03 AM, Robert Haas