On Tue, Apr 1, 2014 at 6:31 AM, Bruce Momjian wrote:
> I reviewed this patch and you are correct that we are not handling
> socket() and accept() returns properly on Windows. We were doing it
> properly in most place in the backend, but your patch fixes the
> remaining places:
>
>
> http
Alexander Korotkov writes:
> Next revision of patch is attached. Changes are so:
> 1) Notion "penalty" is used instead of "size".
> 2) We try to reduce total penalty to WISH_TRGM_PENALTY, but restriction is
> MAX_TRGM_COUNT total trigrams count.
> 3) Penalties are assigned to particular color trig
Heikki Linnakangas wrote:
> I'm surprised none of the existing regression tests caught that.
> Apparently none of them create a GIN index with enough duplicate
> keys that it would create a posting tree. I added one.
Perhaps the --enable-coverage option to configure, and related make
targets, cou
I have released version 4.12 of the buildfarm client.
In addition to numerous bug fixes, it has the following:
* the global option branches_to_build can now be "HEADPLUSLATESTn' for
any single digit n
* there is a new module TestCollateLinuxUTF8
* there is a new module TestDecoding which
I had a look at extending the MSVC build system to support the
test_decoding module. Unfortunately, it requires use of --extra-install
which isn't supported on non-make systems. I'm not going to support that
now - it's a fairly ugly wart but addressing it would take far more time
than I have
On Fri, Apr 4, 2014 at 4:29 PM, Greg Stark wrote:
> 1) Would it make more sense to use a floating point instead of an integer? I
> saw a need for a function like this when I was looking into doing GPU sorts.
> But GPUs expect floating point values.
There is no reason to assume that the normalized
On 04/05/2014 08:08 PM, Tom Lane wrote:
I tried the test case given in
http://www.postgresql.org/message-id/dafad644f268ce1503e1b8b682aae38a.squir...@webmail.xs4all.nl
on HEAD. It asserted here:
...
#5 0x0046b92b in createPostingTree (index=0x7f1348ae31e0,
items=0x7f13343bb048, nit
"Erik Rijkers" writes:
> On Fri, March 28, 2014 09:31, Heikki Linnakangas wrote:
>> So thanks to the fast scan patch, I don't think this patch is worth
>> pursuing anymore. Unless there are some other test case where this patch
>> helps, but the fast scan patch doesn't.
> FWIW, for me the differe
I tried the test case given in
http://www.postgresql.org/message-id/dafad644f268ce1503e1b8b682aae38a.squir...@webmail.xs4all.nl
on HEAD. It asserted here:
#2 0x0077b419 in ExceptionalCondition (
conditionName=, errorType=,
fileName=, lineNumber=)
at assert.c:54
#3 0x000
Amit Kapila writes:
> [ set_guc_backend_params_v2.patch ]
Committed with minor cosmetic adjustments.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-h
Michael Paquier writes:
> On Tue, Feb 18, 2014 at 7:22 AM, Andres Freund wrote:
>> Unless I miss something this possibly allows column definition to slip
>> by that shouldn't because normally all fdw column definitions are passed
>> through transformColumnDefinition() which does some checks, but
Andres Freund writes:
> On 2014-02-27 19:14:13 -0500, Tom Lane wrote:
>> I looked at the postmaster log for the ongoing issue on narwhal
>> (to wit, that the contrib/dblink test dies the moment it tries
>> to do anything dblink-y), and looky here what the postmaster
>> has logged:
> One interesti
Amit Kapila writes:
> Are you concerned about the case when user passes event_source name
> in command line at the time of start:
> pg_ctl start -o "-c event_source=PG9.4" -D
Right.
> If my understanding is right about your concern, then I think it will consider
> the above case even when passe
Hi all,
2014-04-03 9:04 GMT+02:00 Hai Qian :
> Hi Maxence,
>
> We are very glad that you are enthusiastic about MADlib.Your proposal looks
> very nice. The algorithms that you proposed will be very useful, and can
> serve as a good start. After learning about the C++ abstraction layer and
> testi
On 2014-02-27 19:14:13 -0500, Tom Lane wrote:
> I looked at the postmaster log for the ongoing issue on narwhal
> (to wit, that the contrib/dblink test dies the moment it tries
> to do anything dblink-y), and looky here what the postmaster
> has logged:
One interesting bit about this is that it se
On 2014-04-03 14:49:54 -0400, Andrew Dunstan wrote:
> I've been kind of hoping that someone would step up on both these items, but
> the trail seems to have gone cold.
>
> I'm going to put out the new buildfarm release with the new module to run
> test_decoding check. But of course It won't have M
On 5 April 2014 08:38, Dean Rasheed wrote:
> [snip] releasing it in this state feels a little half-baked
> to me.
>
I regret writing that almost as soon as I sent it. The last of those
queries is now over 10 times faster than HEAD, which is certainly
worthwhile. What bugs me is that there is so m
On 4 April 2014 11:56, Florian Pflug wrote:
>
>> On 04.04.2014, at 09:40, Dean Rasheed wrote:
>>
>> I'm not sure how much additional work is required to sort this out,
>> but to me it looks more realistic to target 9.5 than 9.4, so at this
>> point I tend to think that the patch ought to be marke
18 matches
Mail list logo
