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

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

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

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

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

[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

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.

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 >

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 >

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

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

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

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:

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

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

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

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

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,

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,

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 >

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

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,

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

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

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

[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

[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

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

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

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

[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

[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

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

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'

[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

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

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

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