Re: [HACKERS] [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring.

2016-02-12 Thread Amit Kapila
On Fri, Feb 12, 2016 at 2:03 PM, Pavel Stehule wrote: > > > There will be necessary more changes than this. Orafce has some parts >> based on lw locks. I am able to compile it without any issue. But the lock >> mechanism is broken now - so impact on extensions will be

Re: [HACKERS] custom function for converting human readable sizes to bytes

2016-02-12 Thread Heikki Linnakangas
On 12/02/16 10:19, Dean Rasheed wrote: On 12 February 2016 at 06:25, Pavel Stehule wrote: Thank you for review and other work This seems like a reasonable first patch for me as a committer, so I'll take it unless anyone else was planning to do so. Great! You'll

Re: [HACKERS] [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring.

2016-02-12 Thread Pavel Stehule
There will be necessary more changes than this. Orafce has some parts based > on lw locks. I am able to compile it without any issue. But the lock > mechanism is broken now - so impact on extensions will be higher. Have to > do some research. > if somebody would to use it for testing

Re: [HACKERS] [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring.

2016-02-12 Thread Pavel Stehule
2016-02-10 17:21 GMT+01:00 Robert Haas : > On Wed, Feb 10, 2016 at 11:08 AM, Heikki Linnakangas > wrote: > > On 10/02/16 17:12, Robert Haas wrote: > >> Code cleanup in the wake of recent LWLock refactoring. > >> > >> As of commit

Re: [HACKERS] custom function for converting human readable sizes to bytes

2016-02-12 Thread Dean Rasheed
On 12 February 2016 at 06:25, Pavel Stehule wrote: > Thank you for review and other work > This seems like a reasonable first patch for me as a committer, so I'll take it unless anyone else was planning to do so. Regards, Dean -- Sent via pgsql-hackers mailing list

Re: [HACKERS] GinPageIs* don't actually return a boolean

2016-02-12 Thread Yury Zhuravlev
Yury Zhuravlev wrote: Robert Haas wrote: So, is it being pulled in indirectly by some other #include? I can double-check it tomorrow. I've found who include stdbool.h and think it is inevitable for MSVC2013 and MSVC2015. In port/win32.h we inlcude process.h. In process.h included

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

2016-02-12 Thread Etsuro Fujita
Hi Rushabh and Thom, Thanks for the review! On 2016/02/10 22:37, Thom Brown wrote: On 10 February 2016 at 08:00, Rushabh Lathia wrote: Fujita-san, I am attaching update version of the patch, which added the documentation update. Thanks for updating the patch!

Re: [HACKERS] GinPageIs* don't actually return a boolean

2016-02-12 Thread Robert Haas
On Thu, Feb 11, 2016 at 9:30 PM, Michael Paquier wrote: > On Fri, Feb 12, 2016 at 3:45 AM, Tom Lane wrote: >> Andres Freund writes: >>> On 2016-02-11 13:37:17 -0500, Tom Lane wrote: Absolutely; they don't work safely for

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

2016-02-12 Thread Robert Haas
On Fri, Feb 12, 2016 at 7:19 AM, Etsuro Fujita wrote: > I think that displaying target lists would be confusing for users. Here is > an example: > > EXPLAIN (verbose, costs off) > DELETE FROM rem1; -- can be pushed down > QUERY PLAN >

Re: [HACKERS] Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby

2016-02-12 Thread Michael Paquier
On Thu, Feb 11, 2016 at 5:46 PM, Michael Paquier wrote: > On Thu, Feb 11, 2016 at 5:20 PM, Andres Freund wrote: >> On 2016-02-11 09:25:30 +0530, Amit Kapila wrote: >>> On Wed, Feb 10, 2016 at 1:42 PM, Michael Paquier >>>

[HACKERS] Small PATCH: check of 2 Perl modules

2016-02-12 Thread Eugene Kazakov
TAP-tests need two Perl modules: Test::More and IPC::Run. The patch adds checking of modules in configure.in and configure. Eugene Kazakov, Postgres Professional diff --git a/configure b/configure index 1903815..da6ed4b 100755 --- a/configure +++ b/configure @@ -15554,6 +15554,8 @@ done if

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

2016-02-12 Thread Etsuro Fujita
Hi Robert, Thanks for the review! On 2016/02/11 5:43, Robert Haas wrote: On Wed, Feb 10, 2016 at 3:00 AM, Rushabh Lathia wrote: Fujita-san, I am attaching update version of the patch, which added the documentation update. Once we finalize this, I feel good with the

Re: [HACKERS] Re: [COMMITTERS] pgsql: Add some isolation tests for deadlock detection and resolution.

2016-02-12 Thread Robert Haas
On Thu, Feb 11, 2016 at 11:34 PM, Tom Lane wrote: > We're not out of the woods on this :-( ... jaguarundi, which is the first > of the CLOBBER_CACHE_ALWAYS animals to run these tests, didn't like them > at all. I think I fixed the deadlock-soft-2 failure, but its take on >

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

2016-02-12 Thread Robert Haas
On Thu, Feb 11, 2016 at 11:03 PM, Amit Kapila wrote: > Attached patch changes the name of some of the existing tranches > as suggested by you upthread. Committed. Woohoo! -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company --

Re: [HACKERS] [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring.

2016-02-12 Thread Pavel Stehule
2016-02-12 14:10 GMT+01:00 Robert Haas : > On Fri, Feb 12, 2016 at 3:33 AM, Pavel Stehule > wrote: > >> There will be necessary more changes than this. Orafce has some parts > >> based on lw locks. I am able to compile it without any issue. But the

Re: [HACKERS] [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring.

2016-02-12 Thread Pavel Stehule
2016-02-12 10:37 GMT+01:00 Amit Kapila : > On Fri, Feb 12, 2016 at 2:03 PM, Pavel Stehule > wrote: > >> >> >> There will be necessary more changes than this. Orafce has some parts >>> based on lw locks. I am able to compile it without any issue.

Re: [HACKERS] [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring.

2016-02-12 Thread Robert Haas
On Fri, Feb 12, 2016 at 3:33 AM, Pavel Stehule wrote: >> There will be necessary more changes than this. Orafce has some parts >> based on lw locks. I am able to compile it without any issue. But the lock >> mechanism is broken now - so impact on extensions will be

Re: [HACKERS] GinPageIs* don't actually return a boolean

2016-02-12 Thread Robert Haas
On Fri, Feb 12, 2016 at 9:39 AM, Tom Lane wrote: > Robert Haas writes: >> On Fri, Feb 12, 2016 at 8:48 AM, Andres Freund wrote: >>> E.g. if you include stdbool.h [ ginStepRight breaks ] > >> Ah-ha. OK, now I get it. So then I

Re: [HACKERS] [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring.

2016-02-12 Thread Pavel Stehule
2016-02-12 15:43 GMT+01:00 Robert Haas : > On Fri, Feb 12, 2016 at 8:16 AM, Pavel Stehule > wrote: > >> That's very strange. It looks to me like you did exactly the right > >> thing. Can you provide any details on how it fails? > > > > Looks like

Re: [HACKERS] GinPageIs* don't actually return a boolean

2016-02-12 Thread Yury Zhuravlev
Tom Lane wrote: Well, the thing that is scaring me here is allowing a platform-specific definition of "bool" to be adopted. You say that something strange. bool from stdbool.h is C99 standart. A different behavior would be regarded as a compiler error. -- Yury Zhuravlev Postgres Professional:

Re: [HACKERS] GinPageIs* don't actually return a boolean

2016-02-12 Thread Dmitry Ivanov
> OK, that seems reasonable from here. What I'm still fuzzy about is > why including stdbool.h causes a failure. Is it because it defines a > type called "bool" that clashes with ours? That seems like the > obvious explanation, but then how does that not cause the compiler to > just straight-up

Re: [HACKERS] GinPageIs* don't actually return a boolean

2016-02-12 Thread Andres Freund
On 2016-02-12 07:59:06 -0500, Robert Haas wrote: > OK, that seems reasonable from here. What I'm still fuzzy about is > why including stdbool.h causes a failure. Is it because it defines a > type called "bool" that clashes with ours? That seems like the > obvious explanation, but then how does

Re: [HACKERS] Patch: fix lock contention for HASHHDR.mutex

2016-02-12 Thread Robert Haas
On Thu, Feb 11, 2016 at 3:26 PM, Robert Haas wrote: > On Thu, Feb 11, 2016 at 9:53 AM, Robert Haas wrote: >> The fact that InitLocks() doesn't do this has been discussed before >> and there's no consensus on changing it. It is, at any rate, a >>

Re: [HACKERS] GinPageIs* don't actually return a boolean

2016-02-12 Thread Tom Lane
Robert Haas writes: > On Fri, Feb 12, 2016 at 8:48 AM, Andres Freund wrote: >> E.g. if you include stdbool.h [ ginStepRight breaks ] > Ah-ha. OK, now I get it. So then I agree we should back-patch this > at least as far as 9.3 where MSVC 2013 became

Re: CustomScan in a larger structure (RE: [HACKERS] CustomScan support on readfuncs.c)

2016-02-12 Thread Robert Haas
On Thu, Feb 11, 2016 at 7:06 PM, Kouhei Kaigai wrote: >> -Original Message- >> From: pgsql-hackers-ow...@postgresql.org >> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas >> Sent: Thursday, February 11, 2016 1:26 PM >> To: Kaigai Kouhei(海外 浩平) >>

Re: CustomScan in a larger structure (RE: [HACKERS] CustomScan support on readfuncs.c)

2016-02-12 Thread Andres Freund
Hi, On 2016-02-10 23:26:20 -0500, Robert Haas wrote: > I think the part about whacking around the FDW API is a little more > potentially objectionable to others, so I want to hold off doing that > unless a few more people chime in with +1. Perhaps we could start a > new thread to talk about

Re: CustomScan in a larger structure (RE: [HACKERS] CustomScan support on readfuncs.c)

2016-02-12 Thread Robert Haas
On Fri, Feb 12, 2016 at 9:56 AM, Andres Freund wrote: > On 2016-02-10 23:26:20 -0500, Robert Haas wrote: >> I think the part about whacking around the FDW API is a little more >> potentially objectionable to others, so I want to hold off doing that >> unless a few more people

Re: [HACKERS] GinPageIs* don't actually return a boolean

2016-02-12 Thread Robert Haas
On Fri, Feb 12, 2016 at 8:48 AM, Andres Freund wrote: > On 2016-02-12 07:59:06 -0500, Robert Haas wrote: >> OK, that seems reasonable from here. What I'm still fuzzy about is >> why including stdbool.h causes a failure. Is it because it defines a >> type called "bool" that

Re: [HACKERS] Incorrect formula for SysV IPC parameters

2016-02-12 Thread Fujii Masao
On Fri, Feb 5, 2016 at 2:17 PM, Kyotaro HORIGUCHI wrote: > At Thu, 4 Feb 2016 21:43:04 +0900, Fujii Masao wrote > in >> On Wed, Feb 3, 2016 at 12:51 PM, Kyotaro HORIGUCHI

Re: [HACKERS] [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring.

2016-02-12 Thread Robert Haas
On Fri, Feb 12, 2016 at 8:16 AM, Pavel Stehule wrote: >> That's very strange. It looks to me like you did exactly the right >> thing. Can you provide any details on how it fails? > > Looks like some race conditions is there - but I didn't tested it deeper Well, OK, so

Re: [HACKERS] GinPageIs* don't actually return a boolean

2016-02-12 Thread Andres Freund
On 2016-02-12 09:39:20 -0500, Tom Lane wrote: > Robert Haas writes: > > On Fri, Feb 12, 2016 at 8:48 AM, Andres Freund wrote: > >> E.g. if you include stdbool.h [ ginStepRight breaks ] > > > Ah-ha. OK, now I get it. So then I agree we should

Re: [HACKERS] GinPageIs* don't actually return a boolean

2016-02-12 Thread Tom Lane
Robert Haas writes: > On Fri, Feb 12, 2016 at 9:39 AM, Tom Lane wrote: >> Um, no, that does not follow. The unanswered question here is why, >> when we *have not* included stdbool.h and *have* typedef'd bool as >> just plain "char", we would get C99

[HACKERS] pg_basebackup vs WAL fetching

2016-02-12 Thread Magnus Hagander
Right now, pg_basebackup can only use replication slots with WAL streaming. It's intended, I believe, to be used when you use pg_basebackup to set up a new replica, to close the gap before starting a replica (ref http://www.postgresql.org/message-id/flat/555dd2b2.7020...@gmx.net). A bit down that

Re: [HACKERS] extend pgbench expressions with functions

2016-02-12 Thread Robert Haas
On Fri, Feb 12, 2016 at 5:06 AM, Fabien COELHO wrote: > I think that this option is too much bother for the small internal purpose > at hand. Yeah, I'm really frustrated with this whole thread. There's been a huge amount of discussion on this patch, but I don't really feel

Re: [HACKERS] extend pgbench expressions with functions

2016-02-12 Thread Fabien COELHO
Hello Michaël, Using a pointer to the tail of the list would make the code simple, and save a couple of lines. I did that, see v27 attached. Note that it does not save any lines, because the reverse function is removed, but then you need another type to keep the head & tail, the link type

Re: [HACKERS] GinPageIs* don't actually return a boolean

2016-02-12 Thread Tom Lane
Andres Freund writes: > On February 12, 2016 5:29:44 PM GMT+01:00, Tom Lane > wrote: >> We should standardize on the "((var & FLAG) != 0)" >> pattern, which works reliably in all cases. > That's what the second version of my patch, and I presume

Re: [HACKERS] GinPageIs* don't actually return a boolean

2016-02-12 Thread Yury Zhuravlev
Andres Freund wrote: Did you read what I wrote? Read. That's not correct for char booleans, because the can have different bits set. Current code support this behavior. But to shoot his leg becomes easier. != 0 much better of course. Thanks. -- Yury Zhuravlev Postgres Professional:

Re: [HACKERS] [PATCH v4] GSSAPI encryption support

2016-02-12 Thread David Steele
Hi Robbie, On 2/10/16 4:06 PM, Robbie Harwood wrote: > Hello friends, > > For your consideration, here is a new version of GSSAPI encryption > support. For those who prefer, it's also available on my github: >

Re: [HACKERS] Code of Conduct plan

2016-02-12 Thread Tom Lane
Josh Berkus wrote: > 1. The Core Team will appoint an exploration committee which will look > at various proposals (including the one drafted on pgsql-general) for > CoCs and discuss them. To follow up on this ... The Core Team are pleased to announce that Stacey Haysler has

Re: [HACKERS] GinPageIs* don't actually return a boolean

2016-02-12 Thread Yury Zhuravlev
Andres Freund wrote: Unless I am missing something major, that doesn't seem to achieve all that much. A cast to a char based bool wouldn't normalize this to 0 or 1. So you're still not guaranteed to be able to do somebool == anotherbool when either are set based on such a macro. In C99

Re: [HACKERS] GinPageIs* don't actually return a boolean

2016-02-12 Thread Andres Freund
On February 12, 2016 5:40:29 PM GMT+01:00, Yury Zhuravlev wrote: >Andres Freund wrote: >> Unless I am missing something major, that doesn't seem to >> achieve all that much. A cast to a char based bool wouldn't >> normalize this to 0 or 1. So you're still not

Re: [HACKERS] Seg fault in pgbench

2016-02-12 Thread Alvaro Herrera
Jeff Janes wrote: > If I give pgbench an empty file, I get a segfault. > > $ touch empty.sql > $ src/bin/pgbench/pgbench -T 60 -f empty.sql > starting vacuum...end. > Segmentation fault (core dumped) > > This has been since this commit: > > commit 8bea3d2219844887e170471f223ba100b3c17571 >

[HACKERS] Seg fault in pgbench

2016-02-12 Thread Jeff Janes
If I give pgbench an empty file, I get a segfault. $ touch empty.sql $ src/bin/pgbench/pgbench -T 60 -f empty.sql starting vacuum...end. Segmentation fault (core dumped) This has been since this commit: commit 8bea3d2219844887e170471f223ba100b3c17571 Author: Alvaro Herrera

Re: [HACKERS] Clock with Adaptive Replacement

2016-02-12 Thread Konstantin Knizhnik
Thank you very much for response. I am not sure that CART can significantly improve PostgreSQL performance - I just want to know opinion of community about CAR/CART and other possible alternative to GCLOCK algorithm. Looks like it CAR really provides better cache hit ratio and so at some

Re: [HACKERS] Patch: fix lock contention for HASHHDR.mutex

2016-02-12 Thread Aleksander Alekseev
Hello, Robert > It also strikes me that it's probably quite likely that slock_t > mutex[NUM_FREELISTS] is a poor way to lay out this data in memory. > For example, on a system where slock_t is just one byte, most likely > all of those mutexes are going to be in the same cache line, which > means

Re: [HACKERS] GinPageIs* don't actually return a boolean

2016-02-12 Thread Robert Haas
On Fri, Feb 12, 2016 at 9:47 AM, Tom Lane wrote: > Robert Haas writes: >> On Fri, Feb 12, 2016 at 9:39 AM, Tom Lane wrote: >>> Um, no, that does not follow. The unanswered question here is why, >>> when we *have not* included

Re: [HACKERS] Clock with Adaptive Replacement

2016-02-12 Thread Robert Haas
On Thu, Feb 11, 2016 at 4:02 PM, Konstantin Knizhnik wrote: > What do you think about improving cache replacement clock-sweep algorithm in > PostgreSQL with adaptive version proposed in this article: > > http://www-cs.stanford.edu/~sbansal/pubs/fast04.pdf > > Are

Re: [HACKERS] GinPageIs* don't actually return a boolean

2016-02-12 Thread Tom Lane
Teodor Sigaev writes: > One more option for patch: > #define GinPageIsLeaf(page)((bool)(GinPageGetOpaque(page)->flags & > GIN_LEAF)) I think that's a seriously bad coding pattern to adopt, because it would work for some people but not others if the flag bit is to the left

Re: [HACKERS] GinPageIs* don't actually return a boolean

2016-02-12 Thread Andres Freund
On February 12, 2016 5:15:59 PM GMT+01:00, Teodor Sigaev wrote: >One more option for patch: > >#define GinPageIsLeaf(page)((bool)(GinPageGetOpaque(page)->flags & >GIN_LEAF)) > >Seems it will work on any platform with built-in bool. But I don't know >will it >work with

Re: [HACKERS] GinPageIs* don't actually return a boolean

2016-02-12 Thread Teodor Sigaev
One more option for patch: #define GinPageIsLeaf(page)((bool)(GinPageGetOpaque(page)->flags & GIN_LEAF)) Seems it will work on any platform with built-in bool. But I don't know will it work with 'typedef char bool' if high bit will be set. That's true, but it doesn't really seem like a

Re: [HACKERS] GinPageIs* don't actually return a boolean

2016-02-12 Thread Andres Freund
On 2016-02-12 09:47:47 -0500, Tom Lane wrote: > Robert Haas writes: > > On Fri, Feb 12, 2016 at 9:39 AM, Tom Lane wrote: > >> Um, no, that does not follow. The unanswered question here is why, > >> when we *have not* included stdbool.h and *have*

Re: CustomScan in a larger structure (RE: [HACKERS] CustomScan support on readfuncs.c)

2016-02-12 Thread Kohei KaiGai
2016-02-13 0:11 GMT+09:00 Robert Haas : > On Fri, Feb 12, 2016 at 9:56 AM, Andres Freund wrote: >> On 2016-02-10 23:26:20 -0500, Robert Haas wrote: >>> I think the part about whacking around the FDW API is a little more >>> potentially objectionable to

[HACKERS] Crash with old Windows on new CPU

2016-02-12 Thread Christian Ullrich
Hello, I just found a compatibility issue when I was migrating an elderly VM to a new host. The VM is running Windows Server 2008 SP2, and it has the EDB build of PostgreSQL 9.4.5 on it. (9.4.6 behaves the same.) It is also not dependent on running in a VM; it would fail on the hardware as

Re: [HACKERS] [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring.

2016-02-12 Thread Pavel Stehule
2016-02-12 15:46 GMT+01:00 Pavel Stehule : > > > 2016-02-12 15:43 GMT+01:00 Robert Haas : > >> On Fri, Feb 12, 2016 at 8:16 AM, Pavel Stehule >> wrote: >> >> That's very strange. It looks to me like you did exactly the

Re: [HACKERS] GinPageIs* don't actually return a boolean

2016-02-12 Thread Andres Freund
On February 12, 2016 5:29:44 PM GMT+01:00, Tom Lane wrote: > We should standardize on the "((var & FLAG) != 0)" >pattern, which works reliably in all cases. That's what the second version of my patch, and I presume Michael's updated one as well, does. I think the only open

Re: [HACKERS] Fuzzy substring searching with the pg_trgm extension

2016-02-12 Thread Teodor Sigaev
On Thu, Feb 11, 2016 at 9:56 AM, Teodor Sigaev wrote: 1 - sml_limit to similarity_limit. sml_threshold is difficult to write I think, similarity_limit is more simple. It seems to me that threshold is right word by meaning. sml_threshold is my choice. Why abbreviate it like

Re: [HACKERS] Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby

2016-02-12 Thread Andres Freund
On 2016-02-12 12:37:35 -0500, Robert Haas wrote: > On Mon, Feb 8, 2016 at 4:18 AM, Andres Freund wrote: > > I'm not really a fan. I'd rather change existing callers to add a > > 'flags' bitmask argument. Right now there can't really be XLogInserts() > > in extension code, so

Re: [HACKERS] WIP: SCRAM authentication

2016-02-12 Thread David Steele
Hi Michael and Heikki, On 11/16/15 8:53 AM, Michael Paquier wrote: > On Sat, Sep 5, 2015 at 9:31 AM, Bruce Momjian wrote: >> On Fri, Sep 4, 2015 at 04:51:33PM -0400, Stephen Frost wrote: Coming in late, but can you explain how multiple passwords allow for easier automated credential

Re: [HACKERS] [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring.

2016-02-12 Thread Pavel Stehule
2016-02-12 17:35 GMT+01:00 Pavel Stehule : > > > 2016-02-12 15:46 GMT+01:00 Pavel Stehule : > >> >> >> 2016-02-12 15:43 GMT+01:00 Robert Haas : >> >>> On Fri, Feb 12, 2016 at 8:16 AM, Pavel Stehule

Re: [HACKERS] Fuzzy substring searching with the pg_trgm extension

2016-02-12 Thread Robert Haas
On Thu, Feb 11, 2016 at 9:56 AM, Teodor Sigaev wrote: >> 1 - sml_limit to similarity_limit. sml_threshold is difficult to write I >> think, >> similarity_limit is more simple. > > It seems to me that threshold is right word by meaning. sml_threshold is my > choice. Why

Re: [HACKERS] ALTER ROLE SET/RESET for multiple options

2016-02-12 Thread Payal Singh
The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: tested, passed Spec compliant: tested, failed Documentation:not tested When running gmake installcheck for regression tests, 2 tests

Re: [HACKERS] Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby

2016-02-12 Thread Robert Haas
On Mon, Feb 8, 2016 at 4:18 AM, Andres Freund wrote: > I'm not really a fan. I'd rather change existing callers to add a > 'flags' bitmask argument. Right now there can't really be XLogInserts() > in extension code, so that's pretty ok to change. Yeah, but to what benefit?

Re: [HACKERS] Re: [COMMITTERS] pgsql: Add some isolation tests for deadlock detection and resolution.

2016-02-12 Thread Tom Lane
Robert Haas writes: > On Thu, Feb 11, 2016 at 11:34 PM, Tom Lane wrote: >> The problem here is that when the deadlock detector kills s8's >> transaction, s7a8 is also left free to proceed, so there is a race >> condition as to which query completion

[HACKERS] Compilation warning on 9.5

2016-02-12 Thread Vicky Vergara
Hello: I am a pgRouting developer. In my CmakeLists.txt I use this flags: set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=gnu99 -fPIC -O2 -g -Wall -Wconversion -pedantic -fmax-errors=10 -Wmissing-prototypes -frounding-math") set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++0x -fPIC -O2 -g

Re: [HACKERS] Compilation warning on 9.5

2016-02-12 Thread Tom Lane
Vicky Vergara writes: > I wonder if -std=gnu99 is the correct standard to include postgres.h etc. in > 9.5 > because that standard (and all the flags I am using to generate pgrouting > code without warnings) > catches the following catches warnings of type

Re: [HACKERS] proposal: schema PL session variables

2016-02-12 Thread Pavel Stehule
2016-02-12 22:41 GMT+01:00 Jim Nasby : > On 2/12/16 2:58 PM, Pavel Stehule wrote: > >> I think that's probably true, but this also shows why we need to consider >> different PLs too. As it stands right now, the only way to access a >> variable outside of plpgsql would be

Re: [HACKERS] ALTER ROLE SET/RESET for multiple options

2016-02-12 Thread Robert Haas
On Fri, Feb 12, 2016 at 1:35 PM, Payal Singh wrote: > The feature seems to work as described, but is it necessary to enclose > multiple GUC settings in a parenthesis? This seems a deviation from the usual > syntax of altering multiple settings separated with comma. Well, note

Re: [HACKERS] Seg fault in pgbench

2016-02-12 Thread Fabien COELHO
If I give pgbench an empty file, I get a segfault. $ touch empty.sql $ src/bin/pgbench/pgbench -T 60 -f empty.sql starting vacuum...end. Segmentation fault (core dumped) Oops, shame on me:-( I should have tested this one, especially as I tested it for other changes in pgbench... Thanks

Re: [HACKERS] Way to check whether a particular block is on the shared_buffer?

2016-02-12 Thread Robert Haas
On Thu, Feb 11, 2016 at 9:05 PM, Kouhei Kaigai wrote: > Hmm. In my experience, it is often not a productive discussion whether > a feature is niche or commodity. So, let me change the viewpoint. > > We may utilize OS-level locking mechanism here. > > Even though it depends

Re: [HACKERS] [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring.

2016-02-12 Thread Robert Haas
On Sat, Feb 13, 2016 at 12:20 AM, Pavel Stehule wrote: >> Hmm. So orafce is actually benefiting from the 3-lwlock slop that was >> built into the old system: if one of those original 3 locks was >> as-yet-unclaimed, orafce grabs it when it initializes. The new system >>

Re: [HACKERS] [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring.

2016-02-12 Thread Pavel Stehule
2016-02-13 4:52 GMT+01:00 Robert Haas : > On Fri, Feb 12, 2016 at 1:08 PM, Pavel Stehule > wrote: > >> I got a error > >> > >> ERROR: XX000: requested tranche is not registered > >> LOCATION: GetNamedLWLockTranche, lwlock.c:602 > >> > >> Because

Re: [HACKERS] Support for N synchronous standby servers - take 2

2016-02-12 Thread Robert Haas
On Thu, Feb 11, 2016 at 5:40 PM, Michael Paquier wrote: > On Fri, Feb 12, 2016 at 2:56 AM, Robert Haas wrote: >> On Fri, Feb 5, 2016 at 3:36 AM, Michael Paquier >> wrote: >>> So, here are some thoughts to make that

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

2016-02-12 Thread Robert Haas
On Fri, Feb 12, 2016 at 12:55 AM, Amit Kapila wrote: > Very Good Catch. I think if we want to address this we can detect > the non-group leader transactions that tries to update the different > CLOG page (different from group-leader) after acquiring > CLogControlLock and

Re: [HACKERS] Parallel Aggregate

2016-02-12 Thread Robert Haas
On Sun, Feb 7, 2016 at 8:21 PM, Haribabu Kommi wrote:future. > Here I attached updated patch with the corrections. So, what about the main patch, for parallel aggregation itself? I'm reluctant to spend too much time massaging combine functions if we don't have the

Re: [HACKERS] Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby

2016-02-12 Thread Michael Paquier
On Sat, Feb 13, 2016 at 1:01 PM, Robert Haas wrote: > On Fri, Feb 12, 2016 at 12:56 PM, Andres Freund wrote: >> On 2016-02-12 12:37:35 -0500, Robert Haas wrote: >>> On Mon, Feb 8, 2016 at 4:18 AM, Andres Freund wrote: >>> > I'm not

Re: [HACKERS] [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring.

2016-02-12 Thread Pavel Stehule
2016-02-13 6:32 GMT+01:00 Robert Haas : > On Sat, Feb 13, 2016 at 12:20 AM, Pavel Stehule > wrote: > >> Hmm. So orafce is actually benefiting from the 3-lwlock slop that was > >> built into the old system: if one of those original 3 locks was > >>

Re: [HACKERS] Crash with old Windows on new CPU

2016-02-12 Thread Christian Ullrich
* Robert Haas wrote: On Fri, Feb 12, 2016 at 7:26 PM, Christian Ullrich wrote: startup_hacks(), I think. Proposed patch attached. Thanks for the report and patch. Regrettably I haven't the Windows knowledge to have any idea whether it's right or wrong, but hopefully

Re: [HACKERS] extend pgbench expressions with functions

2016-02-12 Thread Fabien COELHO
Hello Robert, For example, I just realized that this patch allows values to be either a double or an integer and extends the operators to handle double values. But variables can still only be integers. Indeed. [...] at least flatten everything to string rather than integer so that you can

Re: [HACKERS] Small PATCH: check of 2 Perl modules

2016-02-12 Thread Robert Haas
On Fri, Feb 12, 2016 at 8:20 AM, Eugene Kazakov wrote: > TAP-tests need two Perl modules: Test::More and IPC::Run. > > The patch adds checking of modules in configure.in and configure. Why would we want that? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com

Re: [HACKERS] proposal: schema PL session variables

2016-02-12 Thread Jim Nasby
On 2/10/16 1:29 PM, Pavel Stehule wrote: I got off list mail with little bit different syntax proposal CREATE VARIABLE xxx DEFAULT [ PRIVATE ] I am thinking so more SQL natural is form: CREATE [ PRIVATE ] VARIABLE xxx ... There should not be only variables, there can be tables, views,

Re: [HACKERS] Seg fault in pgbench

2016-02-12 Thread Jeff Janes
On Fri, Feb 12, 2016 at 12:22 PM, Alvaro Herrera wrote: > Jeff Janes wrote: >> If I give pgbench an empty file, I get a segfault. >> >> $ touch empty.sql >> $ src/bin/pgbench/pgbench -T 60 -f empty.sql >> starting vacuum...end. >> Segmentation fault (core dumped) > > I

Re: NextXID format change (was Re: [HACKERS] exposing pg_controldata and pg_config as functions)

2016-02-12 Thread Joe Conway
On 02/11/2016 04:59 PM, Michael Paquier wrote: > On Fri, Feb 12, 2016 at 9:18 AM, Bruce Momjian wrote: >> No, that is not an improvement --- see my previous comment: >> >>> We could get more sophisticated by checking the catalog version number >>> where the format was changed,

Re: [HACKERS] proposal: schema PL session variables

2016-02-12 Thread Jim Nasby
On 2/12/16 2:58 PM, Pavel Stehule wrote: So I think adding something like this needs to at least address *how* SQL level access would work, *when* it's eventually implemented. I understand - and I agree. small note: Private variables should not be executed from any SQL, because SQL

Re: [HACKERS] Re: [COMMITTERS] pgsql: Add some isolation tests for deadlock detection and resolution.

2016-02-12 Thread Robert Haas
On Fri, Feb 12, 2016 at 4:59 PM, Tom Lane wrote: > I wrote: >> Instead, what I propose we do about this is to change isolationtester >> so that once it's decided that a given step is blocked, it no longer >> issues the is-it-waiting query for that step; it just assumes that

Re: [HACKERS] Re: [COMMITTERS] pgsql: Add some isolation tests for deadlock detection and resolution.

2016-02-12 Thread Andres Freund
On 2016-02-12 13:16:54 -0500, Tom Lane wrote: > Investigation showed that there are a couple of reasons. One, > isolationtester's is-it-waiting query takes an insane amount of > time under CLOBBER_CACHE_ALWAYS --- over half a second on my > reasonably new server. I wonder if we shouldn't just

Re: [HACKERS] Re: [COMMITTERS] pgsql: Add some isolation tests for deadlock detection and resolution.

2016-02-12 Thread Tom Lane
I wrote: > Instead, what I propose we do about this is to change isolationtester > so that once it's decided that a given step is blocked, it no longer > issues the is-it-waiting query for that step; it just assumes that the > step should be treated as blocked. So all we need do for "backlogged"

Re: [HACKERS] Seg fault in pgbench

2016-02-12 Thread Alvaro Herrera
Jeff Janes wrote: > If I give pgbench an empty file, I get a segfault. > > $ touch empty.sql > $ src/bin/pgbench/pgbench -T 60 -f empty.sql > starting vacuum...end. > Segmentation fault (core dumped) I fixed this by checking whether the first command is NULL; originally this case was handled by

Re: [HACKERS] proposal: schema PL session variables

2016-02-12 Thread Pavel Stehule
Hi >> SQL access to variables needs a) change in SQL parser (with difficult >> discussion about syntax) or b) generic get/set functions. @b can be used >> in other PL in first iteration. >> >> I afraid to open pandora box and I would to hold the scope of this patch >> too small what is possible

[HACKERS] innocuous: pgbench does FD_ISSET on invalid socket

2016-02-12 Thread Alvaro Herrera
I noticed that pgbench calls FD_ISSET on a socket returned by PQsocket() without first checking that it's not invalid. I don't think there's a real problem here because the socket was already checked a few lines above, but I think applying the same coding pattern to both places is cleaner. Any

Re: NextXID format change (was Re: [HACKERS] exposing pg_controldata and pg_config as functions)

2016-02-12 Thread Bruce Momjian
On Thu, Feb 11, 2016 at 07:18:46PM -0500, Bruce Momjian wrote: > No, that is not an improvement --- see my previous comment: > > > We could get more sophisticated by checking the catalog version number > > where the format was changed, but that doesn't seem worth it, and is > > overly complex

Re: [HACKERS] Re: [COMMITTERS] pgsql: Add some isolation tests for deadlock detection and resolution.

2016-02-12 Thread Robert Haas
On Fri, Feb 12, 2016 at 6:22 PM, Andres Freund wrote: > On 2016-02-12 13:16:54 -0500, Tom Lane wrote: >> Investigation showed that there are a couple of reasons. One, >> isolationtester's is-it-waiting query takes an insane amount of >> time under CLOBBER_CACHE_ALWAYS ---

Re: [HACKERS] Crash with old Windows on new CPU

2016-02-12 Thread Christian Ullrich
* Christian Ullrich wrote: Backends (and possibly other processes) crash at the slightest provocation, such as "SELECT * FROM pg_stat_activity;" or VACUUM. The log says either "exception 0xC005" (segfault) or "exception 0xC01D" (illegal instruction). The interesting reason: The old

Re: [HACKERS] Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby

2016-02-12 Thread Robert Haas
On Fri, Feb 12, 2016 at 12:56 PM, Andres Freund wrote: > On 2016-02-12 12:37:35 -0500, Robert Haas wrote: >> On Mon, Feb 8, 2016 at 4:18 AM, Andres Freund wrote: >> > I'm not really a fan. I'd rather change existing callers to add a >> > 'flags' bitmask

Re: [HACKERS] Re: [COMMITTERS] pgsql: Add some isolation tests for deadlock detection and resolution.

2016-02-12 Thread Tom Lane
Robert Haas writes: > On Fri, Feb 12, 2016 at 4:59 PM, Tom Lane wrote: >> The fundamental problem I fear is that isolationtester is designed around >> the assumption that only its own actions (query issuances) change the >> state of the database.

Re: [HACKERS] Crash with old Windows on new CPU

2016-02-12 Thread Robert Haas
On Fri, Feb 12, 2016 at 7:26 PM, Christian Ullrich wrote: > * Christian Ullrich wrote: >> Backends (and possibly other processes) crash at the slightest >> provocation, such as "SELECT * FROM pg_stat_activity;" or VACUUM. The >> log says either "exception 0xC005"

Re: [HACKERS] [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring.

2016-02-12 Thread Robert Haas
On Fri, Feb 12, 2016 at 1:08 PM, Pavel Stehule wrote: >> I got a error >> >> ERROR: XX000: requested tranche is not registered >> LOCATION: GetNamedLWLockTranche, lwlock.c:602 >> >> Because the session initialization doesn't finish, then Orafce doesn't >> work > > I am

Re: NextXID format change (was Re: [HACKERS] exposing pg_controldata and pg_config as functions)

2016-02-12 Thread Michael Paquier
On Sat, Feb 13, 2016 at 7:54 AM, Bruce Momjian wrote: > On Thu, Feb 11, 2016 at 07:18:46PM -0500, Bruce Momjian wrote: >> No, that is not an improvement --- see my previous comment: >> >> > We could get more sophisticated by checking the catalog version number >> > where the

Re: [HACKERS] Re: [COMMITTERS] pgsql: Add some isolation tests for deadlock detection and resolution.

2016-02-12 Thread Tom Lane
Robert Haas writes: > On Fri, Feb 12, 2016 at 6:22 PM, Andres Freund wrote: >> I wonder if we shouldn't just expose a 'which pid is process X waiting >> for' API, implemented serverside. That's generally really useful, and >> looks like it's actually