Re: [HACKERS] Proposal: SET ROLE hook

2016-03-05 21:49 GMT+01:00 Joe Conway : > On 03/01/2016 08:18 AM, Pavel Stehule wrote: > > 2016-03-01 16:52 GMT+01:00 Joe Conway: > > On 03/01/2016 02:09 AM, Pavel Stehule wrote: > > > > On 01/06/2016 10:36 AM, Tom Lane wrote: > > > >> I think a design that was actually somewha

Re: [HACKERS] How can we expand PostgreSQL ecosystem?

On 6 March 2016 at 13:29, MauMau wrote: > However, there is a problem. The number of software is very small that > the users can know to interoperate with PostgreSQL. > Yep, even among many big and popular OSS apps. > Many applications might be interoperable through standard interfaces like

Re: [HACKERS] Proposal: SET ROLE hook

Joe Conway writes: > I still don't see any point in trying to pass data back from the hooks > as the extension can maintain that state just fine, although it looks > like it would be pretty trivial to do using a new void* member added to > role_auth_extra. Tom (or anyone else), any comment on that

Re: [HACKERS] How can we expand PostgreSQL ecosystem?

On 06/03/16 18:29, MauMau wrote: > As I said in the previous greeting mail, I'd like to discuss how to > expand PostgreSQL ecosystem. Here, ecosystem means "interoperability" > -- the software products and cloud services which use/support > PostgreSQL. If pgsql-advocacy or somewhere else is be

Re: [HACKERS] WIP: Upper planner pathification

On Sat, Mar 5, 2016 at 10:11 PM, Tom Lane wrote: > > Amit Kapila writes: > > On Fri, Mar 4, 2016 at 11:31 PM, Tom Lane wrote: > >> (BTW, I found what seemed to be a couple of pre-existing bugs of > >> the same kind, eg create_mergejoin_path was different from the > >> other two kinds of join as

[HACKERS] How can we expand PostgreSQL ecosystem?

Hello, As I said in the previous greeting mail, I'd like to discuss how to expand PostgreSQL ecosystem. Here, ecosystem means "interoperability" -- the software products and cloud services which use/support PostgreSQL. If pgsql-advocacy or somewhere else is better for this topic, just tell me

Re: [HACKERS] Greeting for coming back, and where is PostgreSQL going

Thankyou, Michael, Nagayasu-san, Ishii-san, and Joshua. Your reply gave me energy! I'm relieved to know that community people use Emacs for editing SGML/XML. My main editor on Linux is Emacs. These days, there is a lot of discussion and activity to make Postgres better at scaling out. There

Re: [HACKERS] Proposal: SET ROLE hook

On 6 March 2016 at 04:49, Joe Conway wrote: > I still don't see any point in trying to pass data back from the hooks > as the extension can maintain that state just fine, although it looks > like it would be pretty trivial to do using a new void* member added to > role_auth_extra. Tom (or anyone

Re: [HACKERS] silent data loss with ext4 / all current versions

On 2016-03-05 22:25:36 +0900, Michael Paquier wrote: > OK, I hacked a v7: > - Move the link()/rename() group with HAVE_WORKING_LINK into a single > routine, making the previous link_safe renamed to replace_safe. This > is sharing a lot of things with rename_safe. I am not sure it is worth > complic

Re: [HACKERS] Fix handling of invalid sockets returned by PQsocket()

Peter Eisentraut wrote: > On 2/17/16 10:52 PM, Michael Paquier wrote: > > On Thu, Feb 18, 2016 at 1:58 AM, Alvaro Herrera > > wrote: > >> Michael Paquier wrote: > >>> Hi all, > >>> > >>> After looking at Alvaro's message mentioning the handling of > >>> PQsocket() for invalid sockets, I just had a

Re: [HACKERS] WIP: Upper planner pathification

I wrote: > Attached is a version that addresses today's concerns, and also finishes > filling in the loose ends I'd left before, such as documentation and > outfuncs.c support. I think this is in a committable state now, though > I plan to read through the whole thing again. Sigh, forgot to press

Re: [HACKERS] WIP: Upper planner pathification

Attached is a version that addresses today's concerns, and also finishes filling in the loose ends I'd left before, such as documentation and outfuncs.c support. I think this is in a committable state now, though I plan to read through the whole thing again. regards, tom l

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

On 5 March 2016 at 10:43, Alvaro Herrera wrote: > I wonder why do we have two identical copies of clause_sides_match_join ... Yeah, I noticed the same a while back, and posted about it. Here was the response: http://www.postgresql.org/message-id/26820.1405522...@sss.pgh.pa.us -- David Rowley

Re: [HACKERS] Fix handling of invalid sockets returned by PQsocket()

On 2/17/16 10:52 PM, Michael Paquier wrote: > On Thu, Feb 18, 2016 at 1:58 AM, Alvaro Herrera > wrote: >> Michael Paquier wrote: >>> Hi all, >>> >>> After looking at Alvaro's message mentioning the handling of >>> PQsocket() for invalid sockets, I just had a look by curiosity at >>> other calls of

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 03/05/2016 01:31 PM, Michael Paquier wrote: On Sat, Mar 5, 2016 at 11:34 PM, Andrew Dunstan wrote: Here is a translation into perl of the sed script, courtesy of the s2p incarnation of psed: The sed script appears to have been stable

Re: [HACKERS] Proposal: SET ROLE hook

On 03/01/2016 08:18 AM, Pavel Stehule wrote: > 2016-03-01 16:52 GMT+01:00 Joe Conway: > On 03/01/2016 02:09 AM, Pavel Stehule wrote: > > > On 01/06/2016 10:36 AM, Tom Lane wrote: > > >> I think a design that was actually somewhat robust would require > two > > >> hooks,

Re: [HACKERS] Relaxing SSL key permission checks

Re: Alvaro Herrera 2016-03-04 <20160304205521.GA735336@alvherre.pgsql> > For the sake of cleanliness, I propose splitting out the checks for > regular file and for owned-by-root-or-us from the actual chmod-level > checks at the same time. That way we can provide more specific error > messages for

Re: [HACKERS] WIP: Upper planner pathification

I wrote: > Amit Kapila writes: >> I think here we should use rel->consider_parallel to set parallel_safe as >> is done in create_mergejoin_path. > Well, the "rel" is going to be an upperrel that will have been > manufactured by fetch_upper_rel, and it will contain no useful > information about pa

Re: [HACKERS] WIP: Upper planner pathification

Greg Stark writes: > What query is that lone data point that took 8ms instead of 6ms to > plan in both charts (assuming it's the same data point)? Ah, sorry, I should probably have spent a little more time on making those charts. That thing you're looking at isn't a data point, it's gnuplot show

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On 02/28/2016 07:45 PM, Michael Paquier wrote: > On Mon, Feb 29, 2016 at 3:50 AM, Joe Conway wrote: >> If there are no other complaints or comments, I will commit the attached >> sometime this coming week (the the requisite catversion bump). > > Thanks for the updated patch, I have nothing else t

Re: [HACKERS] WIP: Upper planner pathification

On Sat, Mar 5, 2016 at 6:09 PM, Tom Lane wrote: > There might be some other things we could do to provide a fast-path for > particularly trivial cases. But on the whole I think this plot shows that > there's no systematic problem, and indeed not really a lot of change at > all. Amazing data. Wh

Re: [HACKERS] VS 2015 support in src/tools/msvc

On Sat, Mar 5, 2016 at 11:34 PM, Andrew Dunstan wrote: > Here is a translation into perl of the sed script, courtesy of the s2p > incarnation of psed: > The sed script appears to have been stable for a long time, so I don't think > we need to

Re: [HACKERS] WIP: Upper planner pathification

I wrote: > Robert Haas writes: >> One idea might be to run a whole bunch of queries and record all of >> the planning times, and then run them all again and compare somehow. >> Maybe the regression tests, for example. > That sounds like something we could do pretty easily, though interpreting > t

Re: [HACKERS] WIP: Upper planner pathification

Amit Kapila writes: > On Fri, Mar 4, 2016 at 11:31 PM, Tom Lane wrote: >> (BTW, I found what seemed to be a couple of pre-existing bugs of >> the same kind, eg create_mergejoin_path was different from the >> other two kinds of join as to setting parallel_degree.) > I think the reason for keeping

Re: [HACKERS] JPUG wants to have a copyright notice on the translated doc

On Sat, Mar 5, 2016 at 3:05 AM, Joshua D. Drake wrote: > On 03/04/2016 06:01 PM, Tatsuo Ishii wrote: > > Considering they are BSD licensed, I am not sure what abuses could be >>> taken? >>> >> >> I imagine kind of an extream case: a bad guy removes "Copyright >> 1996-2016 The PostgreSQL Global De

Re: [HACKERS] The plan for FDW-based sharding

On Fri, Mar 4, 2016 at 10:10 PM, Craig Ringer wrote: > On 28 February 2016 at 06:38, Kevin Grittner wrote: >> What I sketched out with the "apparent order of execution" >> ordering of the transactions (basically, commit order except >> when one SERIALIZABLE transaction needs to be dragged in fro

[HACKERS] Re: Static code checker research worth investigating (Communications of the ACM, 03/2016, Vol. 59, No. 03, p. 99)

On Sat, Mar 5, 2016 at 2:35 PM, Tom Browder wrote: >> [Removing all the other xposted lists -- don't do that!] > > Okay, sorry. I thought since the reply was pg-specific it would cut down > noise. I'm sorry I was unclear. I meant, I was removing all the others from my reply and was saying not t

[HACKERS] Re: Static code checker research worth investigating (Communications of the ACM, 03/2016, Vol. 59, No. 03, p. 99)

On Sat, Mar 5, 2016 at 7:03 AM, Greg Stark wrote: > On Sat, Mar 5, 2016 at 12:59 PM, Greg Stark wrote: >> Well. Not dealt with yet. I think it's more or less clear how to >> tackle it using macros and builtins now but there's a lot of drudgery >> work to actually rewrite all the checks. I have th

Re: [HACKERS] VS 2015 support in src/tools/msvc

On 03/05/2016 12:46 AM, Tom Lane wrote: Michael Paquier writes: On Sat, Mar 5, 2016 at 1:41 PM, Petr Jelinek wrote: I vote for just using sed considering we need flex and bison anyway. OK cool, we could go with something else than sed to generate probes.h but that seems sensible considerin

Re: [HACKERS] Freeze avoidance of very large table.

On Sat, Mar 5, 2016 at 1:25 AM, Robert Haas wrote: > On Wed, Mar 2, 2016 at 6:41 PM, Tom Lane wrote: >> Jim Nasby writes: >>> On 3/2/16 4:21 PM, Peter Geoghegan wrote: I think you should commit this. The chances of anyone other than you and Masahiko recalling that you developed this to

Re: [HACKERS] silent data loss with ext4 / all current versions

On Sat, Mar 5, 2016 at 7:47 AM, Andres Freund wrote: > On 2016-03-05 07:43:00 +0900, Michael Paquier wrote: >> On Sat, Mar 5, 2016 at 7:35 AM, Andres Freund wrote: >> > On 2016-03-04 14:51:50 +0900, Michael Paquier wrote: >> >> On Fri, Mar 4, 2016 at 4:06 AM, Andres Freund wrote: >> >> Hm. OK. I

[HACKERS] Re: Static code checker research worth investigating (Communications of the ACM, 03/2016, Vol. 59, No. 03, p. 99)

On Sat, Mar 5, 2016 at 12:59 PM, Greg Stark wrote: > Well. Not dealt with yet. I think it's more or less clear how to > tackle it using macros and builtins now but there's a lot of drudgery > work to actually rewrite all the checks. I have the reports from Xi > Wang's tool saved if anyone else wan

[HACKERS] Re: Static code checker research worth investigating (Communications of the ACM, 03/2016, Vol. 59, No. 03, p. 99)

On Sat, Mar 5, 2016 at 12:41 PM, Tomas Vondra wrote: > And it was dealt with Well. Not dealt with yet. I think it's more or less clear how to tackle it using macros and builtins now but there's a lot of drudgery work to actually rewrite all the checks. I have the reports from Xi Wang's tool saved

Re: [HACKERS] Static code checker research worth investigating (Communications of the ACM, 03/2016, Vol. 59, No. 03, p. 99)

On Sat, Mar 5, 2016 at 6:41 AM, Tomas Vondra wrote: > On Sat, 2016-03-05 at 06:24 -0600, Tom Browder wrote: >> Interesting article in latest issue of subject titled: >> >> "A Differential Approach to Undefined Behavior Detection" ... > AFAIK this is not an entirely new tool - it was published a

Re: [HACKERS] Static code checker research worth investigating (Communications of the ACM, 03/2016, Vol. 59, No. 03, p. 99)

Hi, On Sat, 2016-03-05 at 06:24 -0600, Tom Browder wrote: > Interesting article in latest issue of subject titled: > > "A Differential Approach to Undefined Behavior Detection" > > which may describe procedures not used in other static analysis programs. > > Article references the authors' we

[HACKERS] Static code checker research worth investigating (Communications of the ACM, 03/2016, Vol. 59, No. 03, p. 99)

Interesting article in latest issue of subject titled: "A Differential Approach to Undefined Behavior Detection" which may describe procedures not used in other static analysis programs. Article references the authors' website here: http://css.csail.mit.edu/stack which contains more info l

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Wed, Mar 2, 2016 at 11:05 AM, Dilip Kumar wrote: > And this latest result (no regression) is on X86 but on my local machine. > > I did not exactly saw what this new version of patch is doing different, > so I will test this version in other machines also and see the results. > I tested this o

Re: [HACKERS] WIP: Upper planner pathification

On Sat, Mar 5, 2016 at 4:51 PM, Amit Kapila wrote: > > On Fri, Mar 4, 2016 at 11:31 PM, Tom Lane wrote: > > > > OK, here is a version that I think addresses all of the recent comments: > > > > * Fixed handling of parallel-query fields in new path node types. > > (BTW, I found what seemed to be a

Re: [HACKERS] WIP: Upper planner pathification

On Fri, Mar 4, 2016 at 11:31 PM, Tom Lane wrote: > > OK, here is a version that I think addresses all of the recent comments: > > * Fixed handling of parallel-query fields in new path node types. > (BTW, I found what seemed to be a couple of pre-existing bugs of > the same kind, eg create_mergejoi