Re: [HACKERS] Performance improvement for joins where outer side is unique

Robert Haas writes: > On Fri, Jan 27, 2017 at 1:39 PM, Tom Lane wrote: >> Um ... what's that got to do with the point at hand? > So I assumed from that that the issue was that you'd have to wait for > the first time the irrelevant-joinqual got

Re: [HACKERS] Performance improvement for joins where outer side is unique

On Fri, Jan 27, 2017 at 2:00 PM, Tom Lane wrote: > Robert Haas writes: >> On Fri, Jan 27, 2017 at 1:39 PM, Tom Lane wrote: >>> Um ... what's that got to do with the point at hand? > >> So I assumed from that that the issue was that

Re: [HACKERS] Performance improvement for joins where outer side is unique

Robert Haas writes: > On Fri, Jan 27, 2017 at 11:44 AM, Tom Lane wrote: >> I'm afraid though that we may have to do something about the >> irrelevant-joinquals issue in order for this to be of much real-world >> use for inner joins. > Maybe, but it's

Re: [HACKERS] pg_hba_file_settings view patch

Haribabu Kommi writes: > On Fri, Jan 27, 2017 at 1:36 AM, Tom Lane wrote: >> It might make sense to proceed by writing a separate patch that just >> refactors the existing code to have an API like that, and then revise >> this patch to add an error

Re: [HACKERS] Performance improvement for joins where outer side is unique

On Fri, Jan 27, 2017 at 1:39 PM, Tom Lane wrote: > Robert Haas writes: >> On Fri, Jan 27, 2017 at 11:44 AM, Tom Lane wrote: >>> I'm afraid though that we may have to do something about the >>> irrelevant-joinquals issue in order for

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

> On 27 Jan 2017, at 17:39, Stephen Frost wrote: > > Greetings, > > * Simon Riggs (si...@2ndquadrant.com) wrote: >>> On 27 January 2017 at 14:09, Dave Page wrote: On Fri, Jan 27, 2017 at 1:18 PM, Simon Riggs wrote:

Re: [HACKERS] One-shot expanded output in psql using \G

Re: Stephen Frost 2017-01-27 <20170127160544.gi9...@tamriel.snowman.net> > > > Uh, I figured it was more like \g, which just re-runs the last query.. > > > As in, you'd do: > > > > > > table pg_proc; % blargh, I can't read it like this > > > \G % ahh, much nicer > > > > Sure, that's exactly the

Re: [HACKERS] pg_background contrib module proposal

2017-01-27 19:14 GMT+05:00 Peter Eisentraut : > I suppose we should decide first whether we want pg_background as a > separate extension or rather pursue extending dblink as proposed elsewhere. > > I don't know if pg_background allows any use case that dblink

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

On Fri, Jan 27, 2017 at 12:32 PM, Stephen Frost wrote: > You're completely ignoring the use-cases for which these are being done. > > I've outlined the precise use-case for pgstattuple()'s usage across the > entire database for which the admin has granted the EXECUTE access

Re: [HACKERS] Proposal : For Auto-Prewarm.

On 1/26/17 11:11 PM, Beena Emerson wrote: > In that case, we could add the file location parameter. By default it > would store in the cluster directory else in the location provided. We > can update this parameter in standby for it to access the file. I don't see the need for that. -- Peter

Re: [HACKERS] Parallel Index Scans

On Mon, Jan 23, 2017 at 1:03 AM, Amit Kapila wrote: > parallel_index_opt_exec_support_v6 - Removed the usage of > GatherSupportsBackwardScan. Expanded the comments in > ExecReScanIndexScan. I looked through this and in general it looks reasonable to me. However, I did

Re: [HACKERS] Parallel bitmap heap scan

On Fri, Jan 27, 2017 at 1:32 AM, Dilip Kumar wrote: > There is just one line change in 0003 compared to older version, all > other patches are the same. I spent some time looking at 0001 (and how those changes are used in 0003) and I thought it looked good, so I committed

Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

On Fri, Jan 27, 2017 at 5:28 AM, Rushabh Lathia wrote: > Consider the below test; > > CREATE TABLE tab ( a int primary key); > > SELECT * > FROM pg_constraint pc, > CAST(CASE WHEN pc.contype IN ('f','u','p') THEN generate_series(1, > array_upper(pc.conkey, 1)) ELSE

Re: [HACKERS] pageinspect: Hash index support

On 1/18/17 10:45 AM, Jesper Pedersen wrote: > Fixed in this version: > > * verify_hash_page: Display magic in hex, like hash_metapage_info > * Update header for hash_page_type > > Moving the patch back to 'Needs Review'. Please include tests in your patch. I have posted a sample test suite in

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On 1/26/17 2:05 PM, Robert Haas wrote: > I do not think it can be right to rename the directory and not > anything else. I think this is the root of the confusion. A lot of people apparently consented to renaming pg_xlog with the understanding that that's it, whereas other people understood it

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On 2017-01-27 18:06:11 -0500, Peter Eisentraut wrote: > On 1/24/17 4:47 PM, Robert Haas wrote: > > I'm not excited about starting to change pg_clog before we finish with > > xlog -> wal. Then we just have two half-done things, IMO. But I'm > > also not the only one with a commit bit. > > I

Re: [HACKERS] Typo in comment in postgres_fdw.c

On Thu, Jan 26, 2017 at 10:45 PM, Etsuro Fujita wrote: > I ran into a typo in a comment in contrib/postgres_fdw/postgres_fdw.c. > Attached is a small patch for fixing that. Committed, thanks. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise

Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

On Fri, Jan 27, 2017 at 3:13 PM, David G. Johnston < david.g.johns...@gmail.com> wrote: > In any case the more idiomatic way of writing your query these days (since > 9.4 came out) is: > > SELECT * > FROM pg_constraint pc > LEFT JOIN LATERAL generate_series(1, case when contype in ('f','p','u') >

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On Sat, Jan 28, 2017 at 8:06 AM, Peter Eisentraut wrote: > On 1/24/17 4:47 PM, Robert Haas wrote: >> I'm not excited about starting to change pg_clog before we finish with >> xlog -> wal. Then we just have two half-done things, IMO. But I'm >> also not the only

Re: [HACKERS] Proposal : For Auto-Prewarm.

On 1/26/17 10:11 PM, Beena Emerson wrote: In that case, we could add the file location parameter. By default it would store in the cluster directory else in the location provided. We can update this parameter in standby for it to access the file. I don't see file location being as useful in

Re: [HACKERS] increasing the default WAL segment size

On Thu, Jan 26, 2017 at 8:53 PM, Michael Paquier wrote: >> I've not done like the most careful review ever, but I'm in favor of the >> general change (provided the byval thing is fixed obviously). > > Thanks for the review. Why not use pg_ltoa and pg_lltoa like the

Re: [HACKERS] WIP: About CMake v2

On 2017-01-27 09:09:36 -0500, Peter Eisentraut wrote: > My preferred scenario would be to replace the Windows build system by > this first, then refine it, then get rid of Autoconf. > > The ideal timeline would be to have a ready patch to commit early in a > development cycle, then get rid of the

Re: [HACKERS] pg_hba_file_settings view patch

Haribabu Kommi writes: > [ pg_hba_rules_13.patch ] I spent awhile hacking on this, and made a lot of things better, but I'm still very unhappy about the state of the comments. You changed the APIs of a bunch of functions, often into fairly subtle things, and you did

Re: [HACKERS] Proposal : For Auto-Prewarm.

On Fri, Jan 27, 2017 at 3:18 PM, Peter Eisentraut wrote: > On 1/26/17 11:11 PM, Beena Emerson wrote: >> In that case, we could add the file location parameter. By default it >> would store in the cluster directory else in the location provided. We >> can update

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

On Thu, Jan 26, 2017 at 4:06 PM, Corey Huinker wrote: > > > On Thu, Jan 26, 2017 at 3:55 PM, Fabien COELHO > wrote: > >> >> Hello Daniel, >> >> A comment about control flow and variables: in branches that are not >>> taken, variables are expanded

Re: [HACKERS] WIP: About CMake v2

On Fri, Jan 27, 2017 at 11:09 PM, Peter Eisentraut wrote: > On 1/24/17 8:37 AM, Tom Lane wrote: >> Craig Ringer writes: >>> Personally I think we should aim to have this in as a non default build >>> mode in pg10 if it can be made

Re: [HACKERS] GSoC 2017

On Fri, Jan 27, 2017 at 2:48 PM, Jim Nasby wrote: > On 1/27/17 8:17 AM, Brad DeJong wrote: > >> Add the potential for regulatory requirements to change at any time - >> sort of like timezone information. So no hard coded behavior. >> > > Well, I wish we had support for

Re: [HACKERS] increasing the default WAL segment size

On Sat, Jan 28, 2017 at 7:29 AM, Robert Haas wrote: > On Thu, Jan 26, 2017 at 8:53 PM, Michael Paquier > wrote: >>> I've not done like the most careful review ever, but I'm in favor of the >>> general change (provided the byval thing is fixed

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On 1/24/17 4:47 PM, Robert Haas wrote: > I'm not excited about starting to change pg_clog before we finish with > xlog -> wal. Then we just have two half-done things, IMO. But I'm > also not the only one with a commit bit. I think that depends on which way you slice the overall mission. You

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On 1/26/17 1:10 PM, Tom Lane wrote: > pg_reset_wal It's really more pg_reset_controldata, isn't it? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On Sat, Jan 28, 2017 at 8:03 AM, Peter Eisentraut wrote: > On 1/26/17 2:05 PM, Robert Haas wrote: >> I do not think it can be right to rename the directory and not >> anything else. > > I think this is the root of the confusion. > > A lot of people apparently

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

On Fri, Jan 13, 2017 at 2:36 PM, Peter Geoghegan wrote: > [...] > Yeah. That's basically what the BufFile unification process can > provide you with (or will, once I get around to implementing the > refcount thing, which shouldn't be too hard). As already noted, I'll > also want

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

Hi Thomas, On Fri, Jan 27, 2017 at 5:03 PM, Thomas Munro wrote: > I have broken this up into a patch series, harmonised the private vs > shared hash table code paths better and fixed many things including > the problems with rescans and regression tests mentioned

Re: [HACKERS] pg_hba_file_settings view patch

On Sat, Jan 28, 2017 at 5:47 AM, Tom Lane wrote: > Haribabu Kommi writes: > > On Fri, Jan 27, 2017 at 1:36 AM, Tom Lane wrote: > >> It might make sense to proceed by writing a separate patch that just > >> refactors the existing

Re: [HACKERS] Allow interrupts on waiting standby

On Sat, Jan 28, 2017 at 2:18 AM, Robert Haas wrote: > On Fri, Jan 27, 2017 at 8:17 AM, Michael Paquier > wrote: >> There are no default clauses in the pgstat_get_wait_* routines so my >> compiler is actually complaining... > > That's exactly WHY

Re: [HACKERS] GSoC 2017

On 1/27/17 8:17 AM, Brad DeJong wrote: Add the potential for regulatory requirements to change at any time - sort of like timezone information. So no hard coded behavior. Well, I wish we had support for storing those changing requirements as well. If we had that it would greatly simplify

Re: [HACKERS] Superowners

On 1/26/17 1:25 PM, Simon Riggs wrote: > That should include the ability to dump all objects, yet without any > security details. And it should allow someone to setup logical > replication easily, including both trigger based and new logical > replication. And GRANT ON ALL should work. This

Re: [HACKERS] COPY as a set returning function

On Wed, Jan 25, 2017 at 08:51:38PM -0500, Corey Huinker wrote: > I've put in some more work on this patch, mostly just taking Alvaro's > suggestions, which resulted in big code savings. The patch applies atop master. The test (ls) which previously crashed the backend now doesn't, and works in a

Re: [HACKERS] Add support to COMMENT ON CURRENT DATABASE

On 1/26/17 1:20 PM, Fabrízio de Royes Mello wrote: > Ok, but doing in that way the syntax would be: > > COMMENT ON DATABASE CURRENT_DATABASE IS 'comment'; Yes, that's right. We also have ALTER USER CURRENT_USER already. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL

Re: [HACKERS] GSoC 2017

On 27 January 2017 at 14:52, Thomas Kellerer wrote: > > I don't have the exact syntax at hand, but it's something like this: > > create distinct type customer_id_type as integer; > create distinct type order_id_type as integer; > > create table customers (id customer_id_type

Re: [HACKERS] WIP: About CMake v2

On 1/27/17 6:11 PM, Andres Freund wrote: > On 2017-01-27 09:09:36 -0500, Peter Eisentraut wrote: >> My preferred scenario would be to replace the Windows build system by >> this first, then refine it, then get rid of Autoconf. >> >> The ideal timeline would be to have a ready patch to commit early

[HACKERS] proposal: EXPLAIN ANALYZE formatting

Hi Now EXPLAIN ANALYZE produce too wide rows for usage in presentations What do you think about possibility to implement >>optional<< alternative formatting. Now: node name (estimation) (actual) Alternative: node name (estimation) (actual) Regards Pavel Now ===

Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless)

Hello Corey, And here it is About the patch v3: ## DOCUMENTATION I'm wondering what pg would do on "EXISTS(SELECT 1 FROM customer)" if there are many employees. EXPLAIN suggests a seq_scan, which seems bad. With "(SELECT COUNT(*) FROM pgbench_accounts) <> 0" pg seems to generate an

Re: [HACKERS] BUG: pg_stat_statements query normalization issues with combined queries

On 28 Jan. 2017 02:08, "Tom Lane" wrote: Kyotaro HORIGUCHI writes: > By the way the existing comment for the hook, >> * >> * We provide a function hook variable that lets loadable plugins get >> * control when ProcessUtility is called. Such

Re: [HACKERS] COPY as a set returning function

On 1/27/17 8:07 PM, David Fetter wrote: > There are still neither regression tests nor SGML documentation. > > Are we at a point where we should add these things? One could argue about the documentation at this point, since the function is somewhat self-documenting for the time being. But

Re: [HACKERS] COPY as a set returning function

On 1/25/17 8:51 PM, Corey Huinker wrote: > # select * from copy_srf('echo "x\ty"',true) as t(x text, y text); I find these parameters weird. Just looking at this, one has no idea what the "true" means. Why not have a "filename" and a "program" parameter and make them mutually exclusive? --

Re: [HACKERS] Removing link-time cross-module refs in contrib

On Mon, Oct 03, 2016 at 12:29:18PM -0400, Tom Lane wrote: > Pursuant to Andres' suggestion in > https://www.postgresql.org/message-id/20161002223927.57xns3arkdg4h...@alap3.anarazel.de > attached is a draft patch that gets rid of link-time references > from hstore_plpython to both hstore and

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

On 1/27/17 6:47 PM, Michael Paquier wrote: On Sat, Jan 28, 2017 at 8:03 AM, Peter Eisentraut wrote: On 1/26/17 2:05 PM, Robert Haas wrote: I do not think it can be right to rename the directory and not anything else. I think this is the root of the

Re: [HACKERS] patch proposal

Hi David, On Tue, Jan 24, 2017 at 9:22 AM, David Steele wrote: > Hi Venkata, > > On 11/8/16 5:47 PM, Venkata B Nagothi wrote: > > Attached is the 2nd version of the patch with some enhancements. > > Here's my review of the patch. > Thank you very much for reviewing the

Re: [HACKERS] Radix tree for character conversion

Hi, this is an intermediate report without a patch. At Thu, 26 Jan 2017 21:42:12 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20170126.214212.111556326.horiguchi.kyot...@lab.ntt.co.jp> > > >

Re: [HACKERS] Failure in commit_ts tap tests

On 01/26/2017 03:50 PM, Alvaro Herrera wrote: > Tom Lane wrote: >> Andrew Dunstan writes: >>> On 01/24/2017 05:17 AM, Alvaro Herrera wrote: Maybe we can drop that line and put it back once we get COMMENT ON CURRENT_DATABASE. >>> Works for me. >> If

Re: [HACKERS] increasing the default WAL segment size

Hello Andres, Thank you for your review. On Fri, Jan 27, 2017 at 12:39 AM, Andres Freund wrote: > Hi, > > On 2017-01-23 11:35:11 +0530, Beena Emerson wrote: > > Please find attached an updated WIP patch. I have incorporated almost all > > comments. This is to be applied

Re: [HACKERS] Speedup twophase transactions

>> But, I put the recovery process and the checkpointer process of the >> standby under gdb with breakpoints on these functions, but both did >> not hit CreateRestartPoint() as well as CheckPointGuts() when I issued >> a promote :-| > > No end-of-recovery checkpoints happen at promotion since 9.3.

Re: [HACKERS] Speedup twophase transactions

On 27 January 2017 at 09:59, Nikhil Sontakke wrote: >>> But, I put the recovery process and the checkpointer process of the >>> standby under gdb with breakpoints on these functions, but both did >>> not hit CreateRestartPoint() as well as CheckPointGuts() when I issued

Re: [HACKERS] Speedup twophase transactions

On 27 January 2017 at 15:37, Simon Riggs wrote: > On 27 January 2017 at 09:59, Nikhil Sontakke wrote: But, I put the recovery process and the checkpointer process of the standby under gdb with breakpoints on these functions, but both did

Re: [HACKERS] Push down more full joins in postgres_fdw

On Fri, Jan 13, 2017 at 12:30 PM, Etsuro Fujita wrote: > On 2017/01/12 18:25, Ashutosh Bapat wrote: >> >> On Wed, Jan 11, 2017 at 5:45 PM, Etsuro Fujita >> wrote: > > > On 2017/01/05 21:11, Ashutosh Bapat wrote: >> >> IIUC,

Re: [HACKERS] Speedup twophase transactions

On 27 January 2017 at 11:01, Nikhil Sontakke wrote: > On 27 January 2017 at 15:37, Simon Riggs wrote: >> On 27 January 2017 at 09:59, Nikhil Sontakke wrote: > But, I put the recovery process and the checkpointer

Re: [HACKERS] BUG: pg_stat_statements query normalization issues with combined queries

On 27 Jan. 2017 14:34, "Tom Lane" wrote: Craig Ringer writes: > So perhaps: > "The same query string may be passed to multiple invocations of > ProcessUtility if a utility statement invokes subcommands (e.g. ALTER > TABLE), in which case

Re: [HACKERS] Allow interrupts on waiting standby

On 26 January 2017 at 20:36, Alvaro Herrera wrote: > Simon Riggs wrote: >> On 26 January 2017 at 19:20, Andres Freund wrote: > >> > I'm personally fine with going with a CHECK_FOR_INTERRUPTS >> > for now, but I think it'd better to replace it with a

Re: [HACKERS] Microvacuum support for Hash Index

>>> I have done some more testing with this, and have moved to the patch >>> back to 'Needs Review' pending Amit's comments. >>> >> >> Moved to "Ready for Committer". >> > > Don't you think we should try to identify the reason of the deadlock > error reported by you up thread [1]? I know that you

Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

On 25 January 2017 at 20:06, Jim Nasby wrote: > GUCs support SET LOCAL, but that's not the same as local scoping because the > setting stays in effect unless the substrans aborts. What I'd like is the > ability to set a GUC in a plpgsql block *and have the setting revert

Re: [HACKERS] Failure in commit_ts tap tests

Andrew Dunstan wrote: > On 01/26/2017 03:50 PM, Alvaro Herrera wrote: > > It is really quite annoying that the buildfarm doesn't do what stock > > tests do. What about pushing a bit stronger for having these > > optimizations as part of the standard build run, instead of being only > > in the

Re: [HACKERS] Allow interrupts on waiting standby

On 27 January 2017 at 01:35, Michael Paquier wrote: > On Fri, Jan 27, 2017 at 4:36 AM, Simon Riggs wrote: >> On 26 January 2017 at 19:20, Andres Freund wrote: >>> I'm personally fine with going with a CHECK_FOR_INTERRUPTS

[HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

Consider the below test; CREATE TABLE tab ( a int primary key); SELECT * FROM pg_constraint pc, CAST(CASE WHEN pc.contype IN ('f','u','p') THEN generate_series(1, array_upper(pc.conkey, 1)) ELSE NULL END AS int) AS position; Above query is failing with "set-valued function called in context

Re: [HACKERS] Speedup twophase transactions

On Fri, Jan 27, 2017 at 8:23 PM, Simon Riggs wrote: > On 27 January 2017 at 11:01, Nikhil Sontakke wrote: >> The xact_redo code will add prepared transactions to the >> KnownPreparedList in memory. Earlier it used to create the on-disk 2PC >> file.

Re: [HACKERS] Push down more full joins in postgres_fdw

On 2017/01/27 20:04, Ashutosh Bapat wrote: On Fri, Jan 13, 2017 at 12:30 PM, Etsuro Fujita wrote: A more clean way I'm thinking is: (1) in postgresGetForeignJoinPaths(), create a tlist by build_tlist_to_deparse() and save it in fpinfo->tlist before

Re: [HACKERS] Allow interrupts on waiting standby

On Fri, Jan 27, 2017 at 9:23 PM, Simon Riggs wrote: > On 27 January 2017 at 01:35, Michael Paquier > wrote: >> On Fri, Jan 27, 2017 at 4:36 AM, Simon Riggs wrote: >>> On 26 January 2017 at 19:20, Andres Freund

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Stephen Frost wrote: > I agree that it'd be nice if others would weigh in on this. I support your position. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list

Re: [HACKERS] GSoC 2017

On 24 January 2017 at 03:42, Peter van Hardenberg wrote: > The basic concept is that the value of a currency type is that it would > allow you to operate in multiple currencies without accidentally adding > them. You'd flatten them to a single type if when and how you wanted for any

Re: [HACKERS] Failure in commit_ts tap tests

Alvaro Herrera writes: > There is a lot that you *can* do using the stock makefiles, but that > "make check-world" doesn't do. Why aren't we using USE_MODULE_DB=1 in > "make check-world", is my question. Well, that option isn't all that convenient for manual use ...

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

On Thu, Jan 26, 2017 at 10:36 PM, Stephen Frost wrote: > > Perhaps unsuprisingly, but you've still not convinced me, so I don't > agree with this change. > >> Currently, I count three votes in favor of this approach and one >> opposed. If anyone else wants to weigh in, please

Re: [HACKERS] Speedup twophase transactions

>>> The xact_redo code will add prepared transactions to the >>> KnownPreparedList in memory. Earlier it used to create the on-disk 2PC >>> file. >>> >>> At standby promote, the surviving (yet uncommitted) prepared >>> transactions from KnownPreparedList need to be persisted, right? >> >> I don't

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

On 26 January 2017 at 22:36, Stephen Frost wrote: >> Currently, I count three votes in favor of this approach and one >> opposed. If anyone else wants to weigh in, please do. It would be >> helpful if anyone weighing in can be clear about whether (a) they are >> in favor of

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

On Fri, Jan 27, 2017 at 1:02 PM, Simon Riggs wrote: > On 26 January 2017 at 22:36, Stephen Frost wrote: > >>> Currently, I count three votes in favor of this approach and one >>> opposed. If anyone else wants to weigh in, please do. It would be >>>

Re: [HACKERS] GSoC 2017

Greg Stark writes: > On 24 January 2017 at 03:42, Peter van Hardenberg wrote: >> The basic concept is that the value of a currency type is that it would >> allow you to operate in multiple currencies without accidentally adding >> them. You'd flatten them to a single

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Simon Riggs writes: > [ good general plan ] > 3. Make a list of all functions that would cause security problems. > One by one, precisely. If we did remove all superuser checks we would > need this list documented to advise people of the risks, so it must > exist before

Re: [HACKERS] Performance improvement for joins where outer side is unique

I thought about the patch from the perspective of "grouped relations" (especially [1]). When looking for the appropriate context within the thread, I picked this message. David Rowley wrote: > On 12 March 2016 at 11:43, Tom Lane wrote: > > > >

Re: [HACKERS] Allow interrupts on waiting standby

On Fri, Jan 27, 2017 at 10:35 AM, Michael Paquier wrote: > On Fri, Jan 27, 2017 at 4:36 AM, Simon Riggs wrote: >> On 26 January 2017 at 19:20, Andres Freund wrote: >>> On 2017-01-26 12:24:44 -0500, Robert Haas wrote: On

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

On 27 January 2017 at 12:56, Dave Page wrote: > Probably the most common complaint I get from users > regarding the management & monitoring tools I work on is that they > have to use superuser accounts to get the full benefits, unlike other > DBMSs where you can create a role

Re: [HACKERS] Performance improvement for joins where outer side is unique

On 27 January 2017 at 12:39, Tom Lane wrote: > 2. In these same cases (unique/semi/anti joins), it is possible to avoid > mark/restore overhead in a mergejoin, because we can tweak the executor > logic to not require backing up the inner side. This goes further than > just

[HACKERS] One-shot expanded output in psql using \G

I frequently find myself in the situation that I want the "\x" expanded output mode activated just for one query. There's little wrong with typing "\x" and re-executing the query in that case, but then I'm always annoyed that the expanded output is still active for the next query after that. "\x

Re: [HACKERS] nodes.h - comments comment

Erik Rijkers writes: > Orthography fix in nodes.h comment block. Pushed with some further adjustments. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] One-shot expanded output in psql using \G

Christoph, * Christoph Berg (christoph.b...@credativ.de) wrote: > The same idea was discussed back in 2008. Back then the outcome was > that "\x auto" was implemented, but I still think that \G is a useful > feature to have on its own, and several people in the thread seem to > have agreed back

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

On Fri, Jan 27, 2017 at 1:18 PM, Simon Riggs wrote: > On 27 January 2017 at 12:56, Dave Page wrote: > >> Probably the most common complaint I get from users >> regarding the management & monitoring tools I work on is that they >> have to use superuser

Re: [HACKERS] WIP: About CMake v2

On 1/24/17 8:37 AM, Tom Lane wrote: > Craig Ringer writes: >> Personally I think we should aim to have this in as a non default build >> mode in pg10 if it can be made ready, and aim to make it default in pg11 at >> least for Windows. > > AFAIK we haven't committed

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

On Thu, Jan 26, 2017 at 5:36 PM, Stephen Frost wrote: >> The first is that restricting the ability to GRANT access >> to a function, even a function that allows escalation to superuser >> privileges, doesn't improve security, because the superuser can still >> grant those

Re: [HACKERS] pg_background contrib module proposal

On 1/19/17 12:47 PM, Andrey Borodin wrote: > 4. There is some controversy on where implemented feature shall be: in > separate extension (as in this patch), in db_link, in some PL API, in FDW or > somewhere else. I think that new extension is an appropriate place for the > feature. But I’m not

Re: [HACKERS] GSoC 2017

On January 27, 2017 07:08, Tom Lane wrote: > ... The things I think are unique to the currency situation are: ... Add the potential for regulatory requirements to change at any time - sort of like timezone information. So no hard coded behavior. rounding method/accuracy storage precision

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Robert Haas writes: > - contrib/pageinspect has lots of superuser checks, basically because > they have known input-validation weaknesses. See > 3e1338475ffc2eac25de60a9de9ce689b763aced for the rationale in detail. FWIW, I think that's a bit of an oversimplification.

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

On Fri, Jan 27, 2017 at 8:18 AM, Simon Riggs wrote: > This is still just the Adminpack argument. This has been going on for > about a decade? Longer. Right. > If the monitoring tool requires superuser then that is a problem, so > it would be helpful if it didn't do that,

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

On Fri, Jan 27, 2017 at 9:35 AM, Tom Lane wrote: > Robert Haas writes: >> - contrib/pageinspect has lots of superuser checks, basically because >> they have known input-validation weaknesses. See >> 3e1338475ffc2eac25de60a9de9ce689b763aced for the

Re: [HACKERS] pg_background contrib module proposal

On Fri, Jan 27, 2017 at 9:14 AM, Peter Eisentraut wrote: > On 1/19/17 12:47 PM, Andrey Borodin wrote: >> 4. There is some controversy on where implemented feature shall be: in >> separate extension (as in this patch), in db_link, in some PL API, in FDW or >>

Re: [HACKERS] WIP: About CMake v2

Peter Eisentraut wrote: > Right now, however, the patch isn't moving at all, and I don't see it > going into PG10, so I'm fine with returning with feedback. There are a bunch of side patches that we should apply separately, such as the pgcrypto fix. I don't understand why they are part of this

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

Robert Haas writes: > The problem is if the interpretation functions aren't completely > bulletproof, they might do things like crash the server if you use > them to read a corrupt page. That is not any more appealing if you > happen to be running as superuser() than

Re: [HACKERS] GSoC 2017

Greg Stark wrote > I don't think this even needs to be tied to currencies. I've often > thought this would be generally useful for any value with units. This > would prevent you from accidentally adding miles to kilometers or > hours to parsecs which is just as valid as preventing you from adding

Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check

On Fri, Jan 27, 2017 at 9:42 AM, Tom Lane wrote: > Robert Haas writes: >> The problem is if the interpretation functions aren't completely >> bulletproof, they might do things like crash the server if you use >> them to read a corrupt page. That is not

Re: [HACKERS] One-shot expanded output in psql using \G

Re: To PostgreSQL Hackers 2017-01-27 <20170127132737.6skslelaf4txs...@msg.credativ.de> > The same idea was discussed back in 2008. Back then the outcome was > that "\x auto" was implemented, but I still think that \G is a useful > feature to have on its own, and several people in the thread seem

Re: [HACKERS] BUG: pg_stat_statements query normalization issues with combined queries

Craig Ringer writes: > On 27 Jan. 2017 14:34, "Tom Lane" wrote: >> "The same queryString may be passed to multiple invocations of >> ProcessUtility when processing a query string containing multiple >> semicolon-separated statements; one should

Re: [HACKERS] One-shot expanded output in psql using \G

On Fri, Jan 27, 2017 at 02:27:37PM +0100, Christoph Berg wrote: > I frequently find myself in the situation that I want the "\x" > expanded output mode activated just for one query. There's little > wrong with typing "\x" and re-executing the query in that case, but > then I'm always annoyed that

Re: [HACKERS] BUG: pg_stat_statements query normalization issues with combined queries

Kyotaro HORIGUCHI writes: > By the way the existing comment for the hook, >> * >> * We provide a function hook variable that lets loadable plugins get >> * control when ProcessUtility is called. Such a plugin would normally >> * call standard_ProcessUtility().

  1   2   >