Re: Add default role 'pg_access_server_files'

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:tested, passed I ran make installcheck-world and all tests passed except one

Re: Add default role 'pg_access_server_files'

(Duplicated to make sure it's in the commitfest Thread, didn't seem to get in there when I replied to the email) Oops! I made a mistake, which clearly showed up in my last email: I forgot to psql back in as "tester". Now I get the right behavior: $ psql postgres tester postgres=>

Re: Add default role 'pg_access_server_files'

Oops! I made a mistake, which clearly showed up in my last email: I forgot to psql back in as "tester". Now I get the right behavior: $ psql postgres tester psql (9.4.5, server 11devel) Type "help" for help. postgres=> select pg_read_file('/Users/postgres/temp'); ERROR: absolute path not

Re: Add default role 'pg_access_server_files'

Hi Stephen, I have another question then based on what you said earlier today, and some testing I did using your patch. TLDR: I created a role "tester" and was (as expected) not able to perform pg_read_file() on files outside the data directory. But then I granted EXECUTE on that function for

Re: Fix a Oracle-compatible　instr function　in the documentation

Tatsuo Ishii writes: >> The documentation of PL/pgSQL provides sample codes of Oracle-compatible >> instr functions. However, the behaviour is a little differet. >> Oracle's instr raises an error when the forth argument value is less than >> zero, but the sample code returns

Re: proposal: alternative psql commands quit and exit

Chapman Flack writes: > I'm not sure what the usual shape of 'consensus' or 'resolution' is in these > things, > but it seems to me that the branch of this email thread that leads here > (through the > message from Robert that I'm replying to) is the one that felt like it

Re: [HACKERS] GUC for cleanup indexes threshold.

Hi Stephen, On Sat, Jan 6, 2018 at 4:02 PM, Stephen Frost wrote: > Perhaps it should really be in Needs review state then..? Probably. As I pointed out already some time ago, this RecentGlobalXmin interlock stuff is our particular implementation of what Lanin & Shasha call

Re: proposal: alternative psql commands quit and exit

I'm not sure what the usual shape of 'consensus' or 'resolution' is in these things, but it seems to me that the branch of this email thread that leads here (through the message from Robert that I'm replying to) is the one that felt like it was converging. I thought it was converging on the

Re: [HACKERS] Refactoring identifier checks to consistently use strcmp

Stephen Frost writes: > Thinking through it, for my own 2c on this, I tend to agree with Tom > that, really, we should be using strcmp() for anything coming out of the > parser and that the backward-compatibility break from that is > acceptable. I also understand Robert's

Re: [HACKERS] Refactoring identifier checks to consistently use strcmp

Greetings Michael, Daniel, all, * Michael Paquier (michael.paqu...@gmail.com) wrote: > On Fri, Dec 1, 2017 at 4:14 AM, Robert Haas wrote: > > I think the changes in DefineView and ATExecSetRelOptions is wrong, > > because transformRelOptions() is still using pg_strcasecmp.

Parallel append plan instability/randomness

According to buildfarm member silverfish, https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=silverfish=2018-01-06%2008%3A53%3A38 it's possible to sometimes get this failure in the regression tests: ***

Re: [HACKERS] GUC for cleanup indexes threshold.

Greetings Peter, * Peter Geoghegan (p...@bowt.ie) wrote: > On Sat, Jan 6, 2018 at 2:20 PM, Stephen Frost wrote: > >> > IIRC the patches that makes the cleanup scan skip has a problem > >> > pointed by Peter[1], that is that we stash an XID when a btree page is > >> > deleted,

Re: [HACKERS] plpgsql - additional extra checks

Greetings Pavel, * Pavel Stehule (pavel.steh...@gmail.com) wrote: > 2017-11-30 3:44 GMT+01:00 Michael Paquier : > > At least documentation needs patching, or this is going to generate > > warnings on HEAD at compilation. I am moving this to next CF for lack > > of

Re: to_typemod(type_name) information function

Sophie Herold writes: > the following patch allows to retrieve the typemod. Without this patch, > it does not seem to be possible to generate the first column. I thought about this a bit, and I now follow the problem you want to solve, and agree that format_type() is going in

Re: [HACKERS] GUC for cleanup indexes threshold.

On Sat, Jan 6, 2018 at 2:20 PM, Stephen Frost wrote: >> > IIRC the patches that makes the cleanup scan skip has a problem >> > pointed by Peter[1], that is that we stash an XID when a btree page is >> > deleted, which is used to determine when it's finally safe to recycle >> >

Re: [HACKERS] [PATCH] Overestimated filter cost and its mitigation

Greetings, * Michael Paquier (michael.paqu...@gmail.com) wrote: > On Thu, Nov 9, 2017 at 12:33 PM, Ashutosh Bapat > wrote: > > Looking at order_qual_clauses(), we can say that a set of quals q1 > > qn are ordered the same irrespective of the set of clauses

Re: [HACKERS] Secondary index access optimizations

Greetings, * Konstantin Knizhnik (k.knizh...@postgrespro.ru) wrote: > On 04.12.2017 19:44, Alvaro Herrera wrote: > >Konstantin Knizhnik wrote: > >> > >>On 30.11.2017 05:16, Michael Paquier wrote: > >>>On Mon, Nov 6, 2017 at 10:13 PM, Konstantin Knizhnik > >>> wrote: >

Re: [HACKERS] Surjective functional indexes

Greetings, * Konstantin Knizhnik (k.knizh...@postgrespro.ru) wrote: > On 15.12.2017 01:21, Michael Paquier wrote: > >On Fri, Dec 15, 2017 at 6:15 AM, Alvaro Herrera > >wrote: > >>Konstantin Knizhnik wrote: > >>>If you still thing that additional 16 bytes per relation in

Re: [HACKERS] SQL/JSON in PostgreSQL

On 07.01.2018 00:11, Pavel Stehule wrote: 2018-01-06 22:02 GMT+01:00 Oleg Bartunov >: On Sat, Jan 6, 2018 at 8:22 AM, Pavel Stehule > wrote: > Hi > > I am checking the

Re: [HACKERS] Cached plans and statement generalization

Greetings, * Konstantin Knizhnik (k.knizh...@postgrespro.ru) wrote: > On 30.11.2017 04:59, Michael Paquier wrote: > >On Wed, Sep 13, 2017 at 2:11 AM, Konstantin Knizhnik > > wrote: > >>One more patch passing all regression tests with autoprepare_threshold=1. > >>I still

Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently

Greetings Claudio, * Michael Paquier (michael.paqu...@gmail.com) wrote: > On Mon, Nov 27, 2017 at 2:39 PM, Jing Wang wrote: > > A few general comments. > > > > + FreeSpaceMapVacuum(onerel, 64); > > > > Just want to know why '64' is used here? It's better to give a

Re: [HACKERS] GUC for cleanup indexes threshold.

Greetings, (pruned the CC list) * Michael Paquier (michael.paqu...@gmail.com) wrote: > On Thu, Nov 30, 2017 at 12:06 AM, Masahiko Sawada > wrote: > > On Wed, Nov 29, 2017 at 11:05 PM, Simon Riggs wrote: > >> Unless there is disagreement on the

Re: General purpose hashing func in pgbench

Greetings Ildar, * Fabien COELHO (coe...@cri.ensmp.fr) wrote: > >>I noticed from the source of all human knowledege (aka Wikipedia:-) > >>that there seems to be a murmur3 successor. Have you considered it? > >>One good reason to skip it would be that the implementation is long > >>and complex.

Re: PATCH: pgbench - option to build using ppoll() for larger connection counts

Doug, * Rady, Doug (radyd...@amazon.com) wrote: > This patch enables building pgbench to use ppoll() instead of select() > to allow for more than (FD_SETSIZE - 10) connections. As implemented, > when using ppoll(), the only connection limitation is system resources. Looks like this patch had

Re: Condition variable live lock

I wrote: > I still think that we ought to change the Asserts on cv_sleep_target in > ConditionVariablePrepareToSleep and ConditionVariableSleep to be full > test-and-elog tests. Those are checking a global correctness property > ("global" meaning "interactions between completely unrelated modules

Re: [HACKERS] SQL/JSON in PostgreSQL

On 07.01.2018 00:33, Pavel Stehule wrote: 2018-01-06 22:23 GMT+01:00 Nikita Glukhov >: On 07.01.2018 00:22, Pavel Stehule wrote: Hi I try jsonpath on json {     "book":     [     {    

Re: [HACKERS] SQL/JSON in PostgreSQL

2018-01-06 22:23 GMT+01:00 Nikita Glukhov : > On 07.01.2018 00:22, Pavel Stehule wrote: > > Hi > > I try jsonpath on json > > { > "book": > [ > { > "title": "Beginning JSON", > "author": "Ben Smith", > "price": 49.99 >

Re: [HACKERS] SQL/JSON in PostgreSQL

On 07.01.2018 00:22, Pavel Stehule wrote: Hi I try jsonpath on json {     "book":     [     {     "title": "Beginning JSON",     "author": "Ben Smith",     "price": 49.99     },     {     "title": "JSON at Work",     "author": "Tom Marrs",  

Re: [HACKERS] SQL/JSON in PostgreSQL

Hi I try jsonpath on json { "book": [ { "title": "Beginning JSON", "author": "Ben Smith", "price": 49.99 }, { "title": "JSON at Work", "author": "Tom Marrs", "price": 29.99 },

Re: [HACKERS] SQL/JSON in PostgreSQL

2018-01-06 22:02 GMT+01:00 Oleg Bartunov : > On Sat, Jan 6, 2018 at 8:22 AM, Pavel Stehule > wrote: > > Hi > > > > I am checking the JSONPath related code > > > > Questions, notes: > > > > 1. jsonpath operators are not consistent with any other ..

Re: Challenges preventing us moving to 64 bit transaction id (XID)?

Ryan Murphy writes: > Alexander, what is the process you're using to create the patch? I've heard > someone (maybe Tom Lane?) say that he sometimes uses "patch" directly instead > of "git" to create the patch, with better results. I forget the exact > command. Nah,

Re: [HACKERS] SQL/JSON in PostgreSQL

On Sat, Jan 6, 2018 at 8:22 AM, Pavel Stehule wrote: > Hi > > I am checking the JSONPath related code > > Questions, notes: > > 1. jsonpath operators are not consistent with any other .. json, xml .. I am > missing ?, @> operátors I have slides about jsonpath

Re: Condition variable live lock

I wrote: > Robert Haas writes: >> No opinion without seeing what you propose to change. > OK, will put out a proposal. I began with the intention of making no non-cosmetic changes, but then I started to wonder why ConditionVariablePrepareToSleep bothers with a

Re: Add default role 'pg_access_server_files'

Greetings Ryan! * Ryan Murphy (ryanfmur...@gmail.com) wrote: > Stephen, so far I've read thru your patch and familiarized myself with some > of the auth functionality in pg_authid.h and src/backend/utils/adt/acl.c > > The only question I have so far about your patch is the last several hunks of

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

On 30 November 2017 at 17:26, Robert Haas wrote: > I wonder if we could instead think about R NORMALIZE S ON R.x = S.y > WITH (R.time, S.time) as an ordinary join on R.x = S.y with some extra > processing afterwards. That would work nicely, kindof like a Projection, but

Re: Add default role 'pg_access_server_files'

Stephen, so far I've read thru your patch and familiarized myself with some of the auth functionality in pg_authid.h and src/backend/utils/adt/acl.c The only question I have so far about your patch is the last several hunks of the diff, which remove superuser checks without adding anything

Re: [PATCH] Logical decoding of TRUNCATE

Attached here there is the complete list of patches required to pass all the tests. The 0001 patch is discussed in a separate thread, but I've posted it also here to ease the review of the 0002. Regards, Marco -- Marco Nenciarini - 2ndQuadrant Italy PostgreSQL Training, Services and Support

Re: Challenges preventing us moving to 64 bit transaction id (XID)?

Thanks for this contribution! I think it's a hard but important problem to upgrade these xids. Unfortunately, I've confirmed that this patch 0001-64bit-guc-relopt-3.patch doesn't apply correctly on my computer. Here's what I did: I did a "git pull" to the current HEAD, which is

Re: Challenges preventing us moving to 64 bit transaction id (XID)?

Since the Patch Tester (http://commitfest.cputube.org/) says this Patch will not apply correctly, I am tempted to change the status to Waiting on Author. However, I'm new to the CommitFest process, so I'm leaving the status as-is for now and asking Stephen Frost whether he agrees. I haven't

Re: to_timestamp TZH and TZM format specifiers

On 01/03/2018 02:21 PM, Andrew Dunstan wrote: > > On 01/03/2018 01:34 PM, Tom Lane wrote: >> Andrew Dunstan writes: >>> This small and simple standalone patch extracted from the SQL/JSON work >>> would allow the user to supply a string with a time zone specified

Re: [PATCH] Logical decoding of TRUNCATE

Patch rebased on the current master. Regards, Marco -- Marco Nenciarini - 2ndQuadrant Italy PostgreSQL Training, Services and Support marco.nenciar...@2ndquadrant.it | www.2ndQuadrant.it diff --git a/contrib/test_decoding/expected/ddl.out b/contrib/test_decoding/expected/ddl.out index

Re: unique indexes on partitioned tables

On 29 December 2017 at 23:06, Alvaro Herrera wrote: > This is the patch series for UNIQUE / PRIMARY KEY indexes on partitioned > tables. This is on top of the patch in > https://postgr.es/m/20171229175930.3aew7lzwd5w6m2x6@alvherre.pgsql > but I included it here as 0001

Re: FOR EACH ROW triggers on partitioned tables

On 3 January 2018 at 03:12, Peter Eisentraut wrote: > On 12/29/17 17:53, Alvaro Herrera wrote: >> This patch enables FOR EACH ROW triggers on partitioned tables. >> >> As presented, this patch is sufficient to discuss the semantics that we >> want for triggers on

Re: [HACKERS] Removing useless DISTINCT clauses

Hi Jeff, Thanks for looking at the patch. On 6 January 2018 at 10:34, Jeff Janes wrote: > Couldn't the Unique node be removed entirely? If k is a primary key, you > can't have duplicates in need of removal. It probably could be, if there were no joins, but any join could

Re: [HACKERS] Creating backup history files for backups taken from standbys

On Fri, Jan 5, 2018 at 11:27 PM, Simon Riggs wrote: > I'm not. > > If we want to do this why not only do it in the modes that have meaning? > i.e. put an if() test in for archive_mode == always. OK, I can see value in your point as well. The check is a bit more complicated