On Tue, Dec 12, 2017 at 3:43 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> Here are review comments for 0009
> Only full aggregation is pushed on the remote server.
>
> I think we can live with that for a while but we need to be able to push
> down
> partial aggregates to the fore
Attached patchset with all the review comments reported so far.
On Fri, Dec 1, 2017 at 6:11 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> Continuing with review of 0007.
>
> +
> +/* Copy input rels's relids to grouped rel */
> +grouped_rel->relids = input_rel->relids;
>
>
On Tue, Dec 19, 2017 at 5:52 AM, Masahiko Sawada wrote:
> On Mon, Dec 18, 2017 at 2:04 PM, Masahiko Sawada
> wrote:
>> On Sun, Dec 17, 2017 at 12:27 PM, Robert Haas wrote:
>>>
>>> I have to admit that result is surprising to me.
>>
>> I think the environment I used for performance measurement d
On 23 December 2017 at 04:00, Amit Khandekar wrote:
> On 15 December 2017 at 18:28, Robert Haas wrote:
>> -PartitionDispatch **pd,
>> -ResultRelInfo ***partitions,
>> -TupleConversionMap ***tup_conv_maps,
>> -TupleTableSlot **partition_tuple_slot,
>> -int *num_parted, int *num
On Tue, Jan 2, 2018 at 4:17 PM, Tom Lane wrote:
> baiji | .\src\backend\executor\nodeHashjoin.c(165): warning C4141:
> 'inline' : used more than once
> bowerbird | src/backend/executor/nodeHashjoin.c(165): warning C4141:
> 'inline' : used more than once
> [c:\prog\bf\root\HEAD\pgsql.build
I find myself entirely unimpressed with the results of commit dbb3d6f01.
In the first place, even among the compilers that claim to understand
that directive at all, there is a noticeable tendency to issue warnings.
I find the following in recent buildfarm "make" logs:
baiji | .\src\backend\
On Sat, Dec 16, 2017 at 08:06:05PM -0800, Noah Misch wrote:
> On Mon, Nov 06, 2017 at 12:07:52AM -0800, Noah Misch wrote:
> I now see similar trouble from multiple
> "make" processes running "make -C contrib/test_decoding install" concurrently.
> This is a risk for any directory named in an EXTRA_
On 01/02/2018 01:26 AM, Tels wrote:
Moin,
On Sat, December 30, 2017 4:25 pm, Gavin Flower wrote:
On 12/31/2017 03:07 AM, Dave Cramer wrote:
We are having a discussion on the jdbc project about dealing with
24:00:00.
https://github.com/pgjdbc/pgjdbc/pull/992#issuecomment-354507612
Dave Cramer
Hi, Ivan!
> 31 дек. 2017 г., в 22:30, Ivan Kartyshov
> написал(а):
>
> Hello, I`d like to show my implementation of SLRU file protection with
> checksums.
> .
> I would like to hear your thoughts over my patch.
As far as I can see, the patch solves problem of hardware corruption in SLRU.
T
On Mon, Jan 01, 2018 at 07:55:37PM +0900, Michael Paquier wrote:
> On Sun, Dec 31, 2017 at 09:52:27PM -0800, Noah Misch wrote:
> > Since now() is transaction_timestamp(), $recovery_time precedes or equals
> > $lsn3, and this didn't close the race. Using clock_timestamp() here would
> > work, as do
On 16 December 2017 at 03:09, Robert Haas wrote:
> started another review pass over the main patch, so here are
> some comments about that.
I am yet to address all the comments, but meanwhile, below are some
specific points ...
> + if (!partrel)
> + {
> + /*
> + * We locked all the partitions a
On 12/31/2017 06:48 PM, Andrew Dunstan wrote:
>
> Here is a new version of the patch. It separates the missing values
> constructs and logic from the default values constructs and logic. The
> missing values now sit alongside the default values in tupleConstr. In
> some places the separation make
On 1 January 2018 at 19:22, Beena Emerson wrote:
> I think you are testing without asserts
Yeah, I was indeed. Oops.
> The following assert fails: src/backend/optimizer/plan/setrefs.c :
> set_plan_refs: ln 921
> Assert(splan->plan.qual == NIL);
> Append node now has runtime partition quals.
>
>
Moin,
On Sun, December 31, 2017 12:50 pm, Tom Lane wrote:
> Peter Eisentraut writes:
>> select timestamp '2017-12-30 24:00:00';
>> returns
>> 2017-12-31 00:00:00
>> which makes some sense.
>
>> I don't know why we accept that and not '24:00:01' and beyond, but it's
>> probably historical.
>
> We
Moin,
On Sat, December 30, 2017 4:25 pm, Gavin Flower wrote:
> On 12/31/2017 03:07 AM, Dave Cramer wrote:
>> We are having a discussion on the jdbc project about dealing with
>> 24:00:00.
>>
>> https://github.com/pgjdbc/pgjdbc/pull/992#issuecomment-354507612
>>
>> Dave Cramer
>
> In Dublin (I was
On Sun, Dec 31, 2017 at 09:52:27PM -0800, Noah Misch wrote:
> Since now() is transaction_timestamp(), $recovery_time precedes or equals
> $lsn3, and this didn't close the race. Using clock_timestamp() here would
> work, as does using separate transactions like recovery-test-fixes.patch did.
> I'll
On Thu, Dec 28, 2017 at 11:08 AM, Masahiko Sawada wrote:
>
>> (1)
>> Why don't you use the existing global variable MyXactFlags instead of the
>> new TransactionDidWrite? Or, how about using XactLastRecEnd != 0 to
>> determine the transaction did any writes? When the transaction only
>> modif
17 matches
Mail list logo
