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 fo
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
* 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
someone who knows Wind
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
> >> as-yet-unclaimed, orafce grabs it when it initia
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 that you can say:
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
>> hasn't got that slop, and
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 really a fan. I'd rather change existing callers to add a
>>> >
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 to call a plpgsql function
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 the session initialization doesn't finish, then O
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 infrastructure to use them.
Th
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
The Enterprise PostgreSQL Com
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 on filesystem implementa
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 then mark these transacti
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 more user-friendly. I think
>>> that the critical issue here is to properly flatt
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 argument. Right now there can't really be X
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 starting to understand - t
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" (segfault) or "exception
>> 0x
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. Trying to use it to test deadlock detection is
>>
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 going to be less complicated than that
>> quer
* 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 host
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 --- over half a second on my
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 format was changed, bu
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 exp
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 beca
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 the
>> step should be t
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, but that doesn't see
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 fixed this by checking wheth
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"
>
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 ha
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 ob
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
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 c
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,
functio
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 conversions on some postgresql
> incl
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 -Wconvers
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 are
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 will get back to
>> isolationtester first.
>>
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
>>> wrote:
>>> >> That's very strange. It looks to me like you did exactly the right
>>> >> thing.
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 rot
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 that's pretty ok to ch
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 that? Nobody's go
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 that? N
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? You're just turning a
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
wor
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
Date: Wed Jan 27 02
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
> Autho
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:
> https://github.com/frozencemetery/postgres/commit/c92275b6605d7929cda5551de47a4c60aab7
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: http:/
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 Michael's updated
> one as well, does. I think t
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 guaranteed to be
>> able to do som
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 accepted
our invitat
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 cas
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 question is how far t
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 right
>> >> thing. Can you provide any details on how it fails?
>> >
>> > Lo
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 'typedef char bool' if
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 of the
rightmost by
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
we
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
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 there some well known drawback
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 others, so I want to hold off doing that
>>>
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 stdbool.h and *have* typedef'd bool as
>>> just plain "char", we woul
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 y
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* typedef'd bool as
> >> just plain "char", we woul
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:
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 chime in with +1. Pe
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 like
it's converging t
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 that
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 bool behavior.
> http://www.postgresql.org/me
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 back-patch this
> > at least as far as 9.3 where MSV
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 some race conditions is there - but I didn't tes
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 I'm totally willing to wor
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 agree we should back-patch this
>> at least as far as 9.3 where MSVC
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 a supported platform,
Um, no, that does not
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(海外 浩平)
>> Cc: Andres Freund; Ami
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
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
>> separate issue. I'll go through the rest of this
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
>> wrote:
>> > Hello, I found that the formulas to calculate SEMMNI and SEMMNS
>> > are incorrect in 9.2 and later.
>> >
>>
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 clashes with ours? Tha
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 th
> 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 e
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
>>> wrote:
>>> >
>>> > On Wed, Feb 10, 2016 at 5:00 PM, Amit Kapila
>>> wrote:
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
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
> lock
> >> mechanism is broken now - so impact
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 higher. Have to do
>> some resea
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
--
Sent via pgsql-hackers mai
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. But the lock
>>> mechanism is broken now - so impac
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 testing bits that aren't in the
rightmost byte of a flag word, fo
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
> -
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
> deadlock-hard is:
>
> *
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 patch and think that we
co
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!
Once we finalize this, I feel
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 corecrt_
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
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 higher. Have to
>> do some r
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 want to copy-edit the commen
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
https://gith
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 (pgsql-hackers@postgresql.o
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 c1772ad9225641c921545b35c84ee478c326b95e, there's no
> >> longer an
98 matches
Mail list logo
