Re: [HACKERS] Performance degradation in commit ac1d794

On 2016-01-14 10:39:55 -0500, Robert Haas wrote: > Doesn't this code make it possible for the self-pipe to fill up, > self-deadlocking the process? Suppose we repeatedly enter > WaitLatchOrSocket(). Each time we do, just after waiting = true is > set, somebody sets the latch. We handle the

Re: [HACKERS] pgindent-polluted commits

On 01/13/2016 12:13 PM, Tom Lane wrote: Simon Riggs writes: On 13 January 2016 at 14:48, Noah Misch wrote: I've noticed commits, from a few of you, carrying pgindent changes to lines the patch would not otherwise change. Could we review again why

Re: [HACKERS] Performance degradation in commit ac1d794

On January 14, 2016 5:16:59 PM GMT+01:00, Robert Haas wrote: >Yeah. Although I think for now it would be fine to just error out if >somebody tries to add a socket and there already is one. Then we >could lift that limitation in a later commit. Of course if Andres >wants

Re: [HACKERS] pgindent-polluted commits

On Thu, Jan 14, 2016 at 11:25 AM, Andrew Dunstan wrote: > I do think it makes life easier when going through the git history if > semantic changes are separated from formatting changes. I agree. And I agree with Mark Dilger's point, too. -- Robert Haas EnterpriseDB:

Re: [HACKERS] Performance degradation in commit ac1d794

On Thu, Jan 14, 2016 at 12:06 PM, Andres Freund wrote: > On 2016-01-14 11:31:03 -0500, Robert Haas wrote: >> On Thu, Jan 14, 2016 at 10:56 AM, Andres Freund wrote: >> I think your idea of a data structure the encapsulates a set of events >> for which to

Re: [HACKERS] Performance degradation in commit ac1d794

On 2016-01-14 18:14:21 +0100, Andres Freund wrote: > I'm thinking of something like; > > int WaitOnLatchSet(LatchEventSet *set, int wakeEvents, long timeout); > > int > WaitLatchOrSocket(volatile Latch *latch, int wakeEvents, pgsocket sock,long > timeout) > { > LatchEventSet set; > >

Re: [HACKERS] Performance degradation in commit ac1d794

Andres Freund writes: > This brings me to something related: I'm wondering if we shouldn't merge > unix/win32_latch.c. Well, it's duplicated code on the one hand versus maze-of-ifdefs on the other. Feel free to try it and see, but I'm unsure it'd be an improvement.

Re: [HACKERS] Performance degradation in commit ac1d794

On 2016-01-14 18:14:21 +0100, Andres Freund wrote: > On 2016-01-14 12:07:23 -0500, Robert Haas wrote: > > > Do we want to provide a backward compatible API for all this? I'm fine > > > either way. > > > > How would that work? > > I'm thinking of something like; > > int

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

On 2016/01/12 20:31, Rushabh Lathia wrote: On Thu, Jan 7, 2016 at 6:15 PM, Etsuro Fujita > wrote: On 2016/01/06 18:58, Rushabh Lathia wrote: .) What the need of following change ? @@ -833,9 +833,6 @@

Re: [HACKERS] Removing service-related code in pg_ctl for Cygwin

On 14/01/2016 06:38, Michael Paquier wrote: Hi all, Beginning a new thread seems more adapted regarding $subject but that's mentioned here as well: http://www.postgresql.org/message-id/CAB7nPqQXghm_SdB5iniupz1atzMxk=95gv9a8ocdo83sxcn...@mail.gmail.com It happens based on some investigation

Re: [HACKERS] extend pgbench expressions with functions

Hello Michaël, Hmmm, this is subjective:-) And dependent on personal opinions and views. I've decided to stay with the current behavior (\setrandom), that is to abort the current transaction on errors but not to abort pgbench itself. The check is done before calling the functions, and I

Re: [HACKERS] checkpointer continuous flushing

Hello Andres, Argh! This is a key point: the sort/flush is designed to help HDDs, and would have limited effect on SSDs, and it seems that you are showing that the effect is in fact negative on SSDs, too bad:-( As you quoted, I could reproduce the slowdown both with SSDs *and* with rotating

Re: [HACKERS] Removing Functionally Dependent GROUP BY Columns

On 14/01/2016 01:30, David Rowley wrote: > Many thanks for the thorough review! > And thanks for the patch and fast answer! > On 12 January 2016 at 23:37, Julien Rouhaud > wrote: > > > In identify_key_vars() > > +

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

On Thu, Jan 14, 2016 at 2:00 PM, Etsuro Fujita wrote: > On 2016/01/12 20:31, Rushabh Lathia wrote: > >> On Thu, Jan 7, 2016 at 6:15 PM, Etsuro Fujita >> > wrote: >> On 2016/01/06 18:58, Rushabh

Re: [HACKERS] Removing Functionally Dependent GROUP BY Columns

On 14 January 2016 at 13:16, Julien Rouhaud wrote: > You're absolutely right, but in this case the comment is more like a > reminder of a bigger comment few lines before that wasn't quoted in my mail Fair enough, although I have two niggles with that: a) the second

Re: [HACKERS] Close handle leak in SSPI auth

On Sun, Jan 10, 2016 at 8:58 PM, Christian Ullrich wrote: > Hello, > > here's a one-line patch to close a handle leak in pg_SSPI_recvauth(). > > According to the docs, the token retrieved with > QuerySecurityContextToken() must be closed. We still leak it in a number of

Re: [HACKERS] Removing Functionally Dependent GROUP BY Columns

On 14 January 2016 at 11:19, Julien Rouhaud wrote: > + /* don't try anything unless there's two Vars */ > + if (varlist == NULL || list_length(varlist) < 2) > + continue; > > To be perfectly correct, the comment should

Re: [HACKERS] Removing Functionally Dependent GROUP BY Columns

On 14/01/2016 14:04, Geoff Winkless wrote: > On 14 January 2016 at 11:19, Julien Rouhaud wrote: >> + /* don't try anything unless there's two Vars */ >> + if (varlist == NULL || list_length(varlist) < 2) >> + continue;

[HACKERS] tiny doc patch

(include RLS option in CREATE USER doc) should go into HEAD and REL9_5_STABLE diff --git a/doc/src/sgml/ref/create_user.sgml b/doc/src/sgml/ref/create_user.sgml index 6c690b3..574604f 100644 --- a/doc/src/sgml/ref/create_user.sgml +++ b/doc/src/sgml/ref/create_user.sgml @@ -31,6 +31,7 @@ CREATE

Re: [HACKERS] Removing Functionally Dependent GROUP BY Columns

On 14/01/2016 14:29, Geoff Winkless wrote: > On 14 January 2016 at 13:16, Julien Rouhaud wrote: >> You're absolutely right, but in this case the comment is more like a >> reminder of a bigger comment few lines before that wasn't quoted in my mail > > Fair enough,

Re: [HACKERS] PATCH: Extending the HyperLogLog API a bit

On Mon, Jan 11, 2016 at 2:22 PM, Alvaro Herrera wrote: > Tomas Vondra wrote: >> Attached is v2 of the patch, adding the comments. > > Looks pretty reasonable to me. I'm not sure we want to push this ahead > of the bloom filter stuff, but it looks ready to commit

Re: [HACKERS] About get_relation_constraints and include_notnull

Amit Langote writes: > Why does the argument include_notnull argument exist if > get_relation_constraints() is being called from only one place? Perhaps we > could remove it and add the IS NOT NULL test expression unconditionally if > there are any NOT NULL columns.

Re: [HACKERS] Performance degradation in commit ac1d794

Robert Haas writes: > Incidentally, if we're going to whack around the latch API, it would > be nice to pick a design which wouldn't be too hard to extend to > waiting on multiple sockets. The application I have in mind is to > send of queries to several foreign servers at

Re: [HACKERS] tiny doc patch

On Thu, Jan 14, 2016 at 8:40 AM, Filip Rembiałkowski wrote: > (include RLS option in CREATE USER doc) > > should go into HEAD and REL9_5_STABLE Doesn't ALTER USER need the same fix? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise

Re: [HACKERS] SET syntax in INSERT

Hi, SET syntax for INSERT was brought up a few years ago here: http://www.postgresql.org/message-id/2c5ef4e30908251010s46d9d566m1da21357891ba...@mail.gmail.com From the discussion it seems that one committer was against, one committer was not against, and one committer saw something good in

Re: [HACKERS] Performance degradation in commit ac1d794

On 2016-01-14 12:07:23 -0500, Robert Haas wrote: > > Do we want to provide a backward compatible API for all this? I'm fine > > either way. > > How would that work? I'm thinking of something like; int WaitOnLatchSet(LatchEventSet *set, int wakeEvents, long timeout); int

Re: [HACKERS] proposal: PL/Pythonu - function ereport

On Wed, Jan 13, 2016 at 7:40 PM, Jim Nasby wrote: > On 1/12/16 11:25 AM, Catalin Iacob wrote: >> They're similar but not really the same thing. raise Error and >> plpy.error are both ways to call ereport(ERROR, ...) while SPIError is >> raised when coming back after

Re: [HACKERS] Performance degradation in commit ac1d794

On Thu, Jan 14, 2016 at 10:46 AM, Tom Lane wrote: > Robert Haas writes: >> Incidentally, if we're going to whack around the latch API, it would >> be nice to pick a design which wouldn't be too hard to extend to >> waiting on multiple sockets. The

Re: [HACKERS] Performance degradation in commit ac1d794

On 2016-01-14 11:31:03 -0500, Robert Haas wrote: > On Thu, Jan 14, 2016 at 10:56 AM, Andres Freund wrote: > I think your idea of a data structure the encapsulates a set of events > for which to wait is probably a good one. WaitLatch doesn't seem like > a great name. Maybe

Re: [HACKERS] Performance degradation in commit ac1d794

Robert Haas writes: > On Thu, Jan 14, 2016 at 12:06 PM, Andres Freund wrote: >> Do we want to provide a backward compatible API for all this? I'm fine >> either way. > How would that work? I see no great need to be backwards-compatible on this,

[HACKERS] Comment typo in port/atomics/generic.h

Hi, I found a typo in generic.h The attached patch fixes it: s/tomic/atomic/g Best regards, Tatsuro Yamada *** a/src/include/port/atomics/generic.h --- b/src/include/port/atomics/generic.h *** *** 1,7 /*-

Re: [HACKERS] SET syntax in INSERT

On Thu, Jan 14, 2016 at 3:25 PM, Tom Lane wrote: > "David G. Johnston" writes: >> On Thu, Jan 14, 2016 at 1:07 PM, Tom Lane wrote: >>> Vitaly Burovoy writes: You can't now do something like

[HACKERS] Doubt in 9.5 release note

I saw following item in release-9.5.sgml: Support comments on domain constraints (lvaro Herrera) It seems the release note has nothing to do with the commit. Also, commenting on DOMAIN constraints is not new in 9.5, I think. Best regards, -- Tatsuo Ishii

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

On 1/11/16 6:50 PM, Alvaro Herrera wrote: David Steele wrote: The patch creates a new counter to separate the log filtering from the authentication functionality. This makes it possible to get the same filtering in other parts of the code (or extensions) without abusing the

[HACKERS] Comment thinko in expand_inherited_rtentry()

Hi, Attached fixes what looks like a thinko in a comment: It is the child relations that are "non-local" temp tables that are skipped from being included the inheritance set. The comment in question as it stands, doesn't note that. Thanks, Amit diff --git a/src/backend/optimizer/prep/prepunion.c

Re: [HACKERS] [PROPOSAL] Client Log Output Filtering

On Mon, Jan 11, 2016 at 6:50 PM, Alvaro Herrera wrote: > I think maybe it's better to have each individual error > message be marked as "don't show to client" rather than a global var. +1. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise

Re: [HACKERS] Doubt in 9.5 release note

Tatsuo Ishii writes: > I saw following item in release-9.5.sgml: > > > Support comments on domain > constraints (lvaro Herrera) > > > It seems the release note has nothing to do with the commit. Also, > commenting on DOMAIN

Re: [HACKERS] Removing Functionally Dependent GROUP BY Columns

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14/01/2016 23:05, David Rowley wrote: > On 15 January 2016 at 00:19, Julien Rouhaud > > > wrote: > > > +* Technically we could look at UNIQUE indexes > too, however we'd

Re: [HACKERS] About get_relation_constraints and include_notnull

On 2016/01/14 23:36, Tom Lane wrote: > Amit Langote writes: >> Why does the argument include_notnull argument exist if >> get_relation_constraints() is being called from only one place? Perhaps we >> could remove it and add the IS NOT NULL test expression

Re: [HACKERS] extend pgbench expressions with functions

On Thu, Jan 14, 2016 at 5:54 PM, Fabien COELHO wrote: > I wrote: >> - fprintf(stderr, "gaussian parameter must be at least >> %f (not \"%s\")\n", MIN_GAUSSIAN_PARAM, argv[5]); >> +fprintf(stderr, >> + "random gaussian

Re: [HACKERS] SET syntax in INSERT

2016-01-14 20:09 GMT+01:00 Marko Tiikkaja : > On 2016-01-14 8:06 PM, Pavel Stehule wrote: > >> Probably there is less risk than 7 years ago, but still creating own >> syntax >> isn't the best idea. This is syntactic sugar only and different from ANSi >> SQL or common standard. >> >

Re: [HACKERS] SET syntax in INSERT

2016-01-14 19:51 GMT+01:00 Robert Haas : > On Thu, Jan 14, 2016 at 12:13 PM, Marko Tiikkaja wrote: > > SET syntax for INSERT was brought up a few years ago here: > > >

Re: [HACKERS] SET syntax in INSERT

>SET syntax for INSERT was brought up a few years ago here: >http://www.postgresql.org/message-id/2c5ef4e30908251010s46d9d566m1da21357891ba...@mail.gmail.com >What do we think? +1 this would save comments in long queries. and usindg AS as style helper as suggested in the old post has its caveat:

Re: [HACKERS] SET syntax in INSERT

On 2016-01-14 8:06 PM, Pavel Stehule wrote: Probably there is less risk than 7 years ago, but still creating own syntax isn't the best idea. This is syntactic sugar only and different from ANSi SQL or common standard. So is RETURNING, UPSERT, PL/PgSQL and many other useful features. .m --

Re: [HACKERS] SET syntax in INSERT

On 1/14/16, Tom Lane wrote: > Pavel Stehule writes: Probably there is less risk than 7 years ago, but still creating own syntax isn't the best idea. This is syntactic sugar only and different from ANSi SQL or common standard. > > It's

Re: [HACKERS] Spelling corrections

On Sun, Jan 10, 2016 at 5:17 AM, David Rowley wrote: > On 10 January 2016 at 19:34, Peter Geoghegan wrote: >> >> Attached patch fixes a couple of misspellings. > > Snap! >

Re: [HACKERS] Spelling corrections

On 15 January 2016 at 17:19, Robert Haas wrote: > On Sun, Jan 10, 2016 at 5:17 AM, David Rowley > wrote: > > On 10 January 2016 at 19:34, Peter Geoghegan wrote: > >> > >> Attached patch fixes a couple of misspellings. > > >

[HACKERS] dealing with extension dependencies that aren't quite 'e'

Hi. I'm looking at an extension that creates some triggers (on user tables) dynamically (i.e., not during CREATE EXTENSION, but afterwards). The author has two problems with it: * «DROP EXTENSION ext» won't work without adding CASCADE, which is an (admittedly relatively minor) inconvenience to

[HACKERS] Typo in sequence.c

Hi, I found a typo in sequence.c Please check the attached patch. Regards, Vinayak typo-sequence-c.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Proposal: BSD Authentication support

On Tue, Jan 12, 2016 at 2:27 AM, Marisa Emerson wrote: > I've attached the latest version of this patch. I've fixed up an issue with > the configuration scripts that I missed. Looks reasonable on a quick read-through. Can anyone with access to a BSD system review and test? --

Re: [HACKERS] Combining Aggregates

On Fri, Jan 15, 2016 at 3:34 PM, David Rowley wrote: > On 8 January 2016 at 22:43, David Rowley > wrote: >> >> I've attached some re-based patched on current master. This is just to fix >> a duplicate OID problem. >> > > I've attached

Re: [HACKERS] SET syntax in INSERT

On 2016-01-14 20:50, Vitaly Burovoy wrote: On 1/14/16, Tom Lane wrote: Assume a table with an int-array column, and consider INSERT INTO foo SET arraycol[2] = 7, arraycol[4] = 11; Right part is a column name, not an expression. Isn't it? So "arraycol[2]" is not possible

Re: [HACKERS] SET syntax in INSERT

On 1/14/16, Tom Lane wrote: > Vitaly Burovoy writes: >> On 1/14/16, Tom Lane wrote: >>> It's more than syntactic sugar; you are going to have to invent >>> semantics, >>> as well, because it's less than clear what partial-field

Re: [HACKERS] SET syntax in INSERT

"David G. Johnston" writes: > On Thu, Jan 14, 2016 at 1:07 PM, Tom Lane wrote: >> Vitaly Burovoy writes: >>> You can't now do something like >>> INSERT INTO foo (arraycol[2], arraycol[4]) VALUES(7, 11); >> Hm ...

Re: [HACKERS] SET syntax in INSERT

On Thu, Jan 14, 2016 at 12:13 PM, Marko Tiikkaja wrote: > SET syntax for INSERT was brought up a few years ago here: > http://www.postgresql.org/message-id/2c5ef4e30908251010s46d9d566m1da21357891ba...@mail.gmail.com > > From the discussion it seems that one committer was against,

Re: [HACKERS] SET syntax in INSERT

Pavel Stehule writes: >>> Probably there is less risk than 7 years ago, but still creating own >>> syntax isn't the best idea. This is syntactic sugar only and different >>> from ANSi SQL or common standard. It's more than syntactic sugar; you are going to have to invent

Re: [HACKERS] SET syntax in INSERT

Vitaly Burovoy writes: > On 1/14/16, Tom Lane wrote: >> It's more than syntactic sugar; you are going to have to invent semantics, >> as well, because it's less than clear what partial-field assignments >> should do. >> >> Assume a table with an

Re: [HACKERS] SET syntax in INSERT

On 01/14/2016 03:00 PM, Marko Tiikkaja wrote: On 2016-01-14 20:50, Vitaly Burovoy wrote: On 1/14/16, Tom Lane wrote: Assume a table with an int-array column, and consider INSERT INTO foo SET arraycol[2] = 7, arraycol[4] = 11; Right part is a column name, not an

Re: [HACKERS] SET syntax in INSERT

On Thu, Jan 14, 2016 at 1:07 PM, Tom Lane wrote: > Vitaly Burovoy writes: > > On 1/14/16, Tom Lane wrote: > >> It's more than syntactic sugar; you are going to have to invent > semantics, > >> as well, because it's less than

Re: [HACKERS] SET syntax in INSERT

On Thu, Jan 14, 2016 at 1:25 PM, Tom Lane wrote: > "David G. Johnston" writes: > > On Thu, Jan 14, 2016 at 1:07 PM, Tom Lane wrote: > >> Vitaly Burovoy writes: > >>> You can't now do something like >

Re: [HACKERS] Performance degradation in commit ac1d794

On Thu, Jan 14, 2016 at 12:14 PM, Andres Freund wrote: > On 2016-01-14 12:07:23 -0500, Robert Haas wrote: >> > Do we want to provide a backward compatible API for all this? I'm fine >> > either way. >> >> How would that work? > > I'm thinking of something like; > > int

Re: [HACKERS] SET syntax in INSERT

On 2016-01-14 20:33, Tom Lane wrote: Pavel Stehule writes: Probably there is less risk than 7 years ago, but still creating own syntax isn't the best idea. This is syntactic sugar only and different from ANSi SQL or common standard. It's more than syntactic sugar;

Re: [HACKERS] Performance degradation in commit ac1d794

On 2015-12-26 12:22:48 +0100, Andres Freund wrote: > On 2015-12-25 16:29:53 -0500, Tom Lane wrote: > > Andres Freund writes: > > > There's a couple solutions I can think of to that problem: > > > 1) Use epoll()/kqueue, or other similar interfaces that don't require > > >

Re: [HACKERS] Performance degradation in commit ac1d794

Andres Freund writes: > 0004 currently contains one debatable optimization, which I'd like to > discuss: Currently the 'sock' passed to WaitLatchOrSocket is not > removed/added to the epoll fd, if it's the numerically same as in the > last call. That's good for performance,

Re: [HACKERS] Python 3.x versus PG 9.1 branch

On Wed, Jan 13, 2016 at 11:46 AM, Tom Lane wrote: > Or we could just blow it off on the grounds that 9.1 is not long > for this world anyhow. +1 for blowing it off. I can't see the point in putting effort into this. Nobody should be spinning up new PostgreSQL 9.1

Re: [HACKERS] Performance degradation in commit ac1d794

On Thu, Jan 14, 2016 at 9:39 AM, Andres Freund wrote: > I finally got back to working on this. Attached is a WIP patch series > implementing: > 0001: Allow to easily choose between the readiness primitives in unix_latch.c > Pretty helpful for testing, not useful for

Re: [HACKERS] Performance degradation in commit ac1d794

On Thu, Jan 14, 2016 at 10:56 AM, Andres Freund wrote: > So, I'm wondering how we'd exactly use a hyptothetical > SetSocketToWaitOn, or SetSocketsToWaitOn (or whatever). I mean it can > make a fair bit of sense to sometimes wait on MyLatch/port->sock and > sometimes on

Re: [HACKERS] Removing Functionally Dependent GROUP BY Columns

On 15 January 2016 at 00:19, Julien Rouhaud wrote: > > +* Technically we could look at UNIQUE indexes too, > however we'd also > +* have to ensure that each column of the unique index had > a NOT NULL > > > s/had/has/ > > > +