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 tha

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=> sele

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 allow

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 t

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 zero. This patch fixes

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 was > converging. > I

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 "The Drain Technique"

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 ide

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 concern that there may b

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. With the > > patch: >

Parallel append plan instability/randomness

According to buildfarm member silverfish, https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=silverfish&dt=2018-01-06%2008%3A53%3A38 it's possible to sometimes get this failure in the regression tests: *** /mnt/buildfarm/buildroot/HEAD/pgsql.build/../pgsql/src/test/regress/expected/select_

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, which is used to det

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 reviews, and the status is waitin

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 the wrong direction.

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 >> > the page. Yura's pat

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 they > > are subset of. E.g. if {q1

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: > Concerning broken partiti

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 statistic is > >>>too >

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 mailto:pavel.steh...@gmail.com>> wrote: > Hi > > I am checking the JSONPath related code > > Questions, not

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 do not think that it should

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

Greetings, * Michael Paquier (michael.paqu...@gmail.com) wrote: > On Mon, Dec 4, 2017 at 2:38 PM, Claudio Freire wrote: > > They did apply at the time, but I think major work on vacuum was > > pushed since then, and also I was traveling so out of reach. > > > > It may take some time to rebase the

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 description. > > > > +else

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 above, it seems we should apply > >> Yura's patch

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. I'm

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 som

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":     [     {     "title": "Beginning JSON",

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 .. json, xml .. > I am > > missing ?, @> operátors >

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, you've got that the other

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 http://www.sai.msu.su/~megera/postgre

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 !proclist_contains test, when the c

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 one that can vary the num

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 immed

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 mar

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 6271fceb8a4f07d

Re: Rangejoin rebased

On 29 December 2017 at 18:25, Jeff Davis wrote: > New rangejoin patch attached. > > I had previously attempted to make this work well for multiple range > join keys, but this patch implements single rangejoin keys only, and > the rest of the rangejoin clauses are effectively just rechecks. I > bel

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 tri

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

On 1/6/18 3:48 AM, Michael Paquier wrote: On Fri, Jan 5, 2018 at 11:27 PM, Simon Riggs wrote: Which also makes it a smaller and clearer patch Yes, this generates less diffs, reducing the likelihood of bugs. What do you think about the v3 attached? I agree that this is a cleaner solution.

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 as >>> hh:mm thus: >>> SELECT

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 1e22c1eef

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 for simplicity. (Don't rev

Re: [HACKERS] Removing [Merge]Append nodes which contain a single subpath

On 28 December 2017 at 18:31, David Rowley wrote: > I've attached a rebased patch. > > The previous patch was conflicting with parallel Hash Join (180428404) And another one. Thanks to the patch tester [1], I realised that I didn't make check-world and there was a postgres_fdw test that was faili

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 partitioned tables, which is the m

Re: [HACKERS] Removing useless DISTINCT clauses

On 6 January 2018 at 23:08, David Rowley wrote: >> I think remove_functionally_dependant_groupclauses should have a more >> generic name, like remove_functionally_dependant_clauses. > > It's been a while since I looked at this. I remember thinking > something similar at the time but I must have no

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 duplicate those rows,

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 that just looking for a