On 09/17/2017 07:43 PM, Dmitriy Sarafannikov wrote:
[...]
It seems related to this thread? :
https://www.postgresql.org/message-id/flat/5037A9C5.4030701%40optionshouse.com#5037a9c5.4030...@optionshouse.com
And this wiki page : https://wiki.postgresql.org/wiki/Loose_indexscan
Regards,
--
Nikita Glukhov wrote:
> 0007-json_table-v02.patch:
> - JSON_TABLE using XMLTABLE infrastructure
>
> 0008-json_table-json-v02.patch:
> - JSON_TABLE support for json type
I'm confused ... why are these two patches and not a single one?
--
Álvaro Herrera
Peter Eisentraut wrote:
> On 9/14/17 10:21, Alvaro Herrera wrote:
> > BTW I added --with-ldap and --with-pam to the configure line for the
> > reports in coverage.postgresql.org and the % covered in auth.c went from
> > 24% to 18.9% (from very bad to terribly sad).
>
> You can add src/test/ldap/
On Sun, Sep 17, 2017 at 7:24 AM, Robert Haas wrote:
> Can you debug this on Monday?
>
> ...Robert
>
> Begin forwarded message:
>
> From: Andreas Seltenreich
> Date: September 16, 2017 at 6:55:46 AM EDT
> To: Robert Haas
> Cc:
Thanks Amit for the patch.
I reviewed the code changes as well as performed more testing. Patch
looks good to me.
Here is the updated patch - where added test-case clean up.
On Thu, Sep 14, 2017 at 10:02 AM, Amit Kapila
wrote:
> On Wed, Sep 13, 2017 at 5:30 PM,
On Tue, Sep 12, 2017 at 6:21 PM, Jeevan Chalke <
jeevan.cha...@enterprisedb.com> wrote:
>
>
> On Tue, Sep 12, 2017 at 3:24 PM, Rajkumar Raghuwanshi <
> rajkumar.raghuwan...@enterprisedb.com> wrote:
>
>>
>> Hi Jeevan,
>>
>> I have started testing partition-wise-aggregate and got one observation,
On Mon, Sep 18, 2017 at 3:29 PM, Andres Freund wrote:
> On 2017-09-18 07:24:43 +0100, Simon Riggs wrote:
>> On 18 September 2017 at 05:50, Andres Freund wrote:
>> > Hi,
>> >
>> > Just noticed that we're returning the underlying values for
>> >
On 2017-09-18 07:24:43 +0100, Simon Riggs wrote:
> On 18 September 2017 at 05:50, Andres Freund wrote:
> > Hi,
> >
> > Just noticed that we're returning the underlying values for
> > pg_control_recovery() without any checks:
> > postgres[14388][1]=# SELECT * FROM
On 18 September 2017 at 05:50, Andres Freund wrote:
> Hi,
>
> Just noticed that we're returning the underlying values for
> pg_control_recovery() without any checks:
> postgres[14388][1]=# SELECT * FROM pg_control_recovery();
>
From: Peter Eisentraut
> The process names shown in pg_stat_activity.backend_type as of PG10
and
> the process names used in the ps display are in some cases
gratuitously
> different, so here is a patch to make them more alike. Of course it
> could be debated in some cases which spelling was
On Mon, Sep 18, 2017 at 5:39 PM, Thomas Munro
wrote:
> Here is a patch to fix that.
Here's a better one (same code, corrected commit message).
--
Thomas Munro
http://www.enterprisedb.com
0001-Fix-uninitialized-variable-in-dshash.c.patch
Description: Binary data
101 - 111 of 111 matches
Mail list logo