On Tue, 16 Jul 2019 at 22:56, Andres Freund wrote:
>
> Hi,
>
> On 2019-07-12 14:53:21 +0530, tushar wrote:
> > On 07/10/2019 05:12 PM, Amit Khandekar wrote:
> > > All right. Will do that in the next patch set. For now, I have quickly
> > > done the below changes in a single patch again (attached),
Hi,
On 2019-07-16 19:35:39 -0700, Andres Freund wrote:
> Hi,
>
> On 2019-07-10 17:24:41 -0700, Andres Freund wrote:
> > Not yet sure what's actually going on, but there's something odd with
> > debug information afaict:
> >
> > objdump -W spits out warnings for a few files, all static libraries:
On Thu, Jul 11, 2019 at 5:00 PM Jeevan Chalke <
jeevan.cha...@enterprisedb.com> wrote:
> Hi Anastasia,
>
> On Wed, Jul 10, 2019 at 11:47 PM Anastasia Lubennikova <
> a.lubennik...@postgrespro.ru> wrote:
>
>> 23.04.2019 14:08, Anastasia Lubennikova wrote:
>> > I'm volunteering to write a draft patc
Thanks Tom.
That sounds good to me.
On Wed, Jul 17, 2019 at 10:17 AM Tom Lane wrote:
> vignesh C writes:
> > I'm able to get the same behaviour in centos as well.
> > Should we do anything to handle this in Postgres or any documentation
> > required?
>
> It already is documented:
>
> PSQL_P
On Wed, Jul 17, 2019 at 9:27 AM Thomas Munro wrote:
>
> On Wed, Jul 17, 2019 at 3:44 PM Dilip Kumar wrote:
> > Right, actually I got that point. But, I was thinking that we are
> > wasting one logno from undo log addressing space no?. Instead, if we
> > can keep it attached to the slot and some
On Wed, 2019-07-17 at 10:38 +0900, Michael Paquier wrote:
> +
> +Note that while WAL will be flushed with this setting,
> +pg_receivewal never applies it, so
> + must not be set to
> +remote_apply if
> pg_receivewal
> +is the only synchronous standby.
On Wed, Jul 17, 2019 at 7:30 AM Gareth Palmer
wrote:
> Attached is a patch that adds the option of using SET clause to specify
> the columns and values in an INSERT statement in the same manner as that
> of an UPDATE statement.
>
Cool! Thanks for working on this, I'd love to see the syntax in P
On Tue, Jul 16, 2019 at 9:44 PM Robert Haas wrote:
>
> On Tue, Jul 16, 2019 at 12:32 AM Amit Kapila wrote:
> > The idea is that the queues can get full, but not rollback hash table.
> > In the case where the error queue gets full, we mark the entry as
> > Invalid in the hash table and later when
Find attached updated patches which also work against old servers.
1) avoid ::regnamespace; 2) don't PQgetvalue() fields which don't exist and
then crash.
>From 16b31dc1e4142ed6d0f5f7ed6d65c6184f546a3c Mon Sep 17 00:00:00 2001
From: Justin Pryzby
Date: Tue, 30 Apr 2019 19:05:53 -0500
Subject: [P
On Wed, Jul 17, 2019 at 3:53 AM Andres Freund wrote:
> On 2019-07-15 12:26:21 -0400, Robert Haas wrote:
Responding again with some more details.
> >
> > But, my understanding of the current design being implemented is that
> > there is a hard limit on the number of transactions that can be
> > p
On Tue, Jul 16, 2019 at 9:52 PM Robert Haas wrote:
>
> On Tue, Jul 16, 2019 at 7:13 AM Amit Kapila wrote:
> > > I also strongly suspect it is altogether wrong to do
> > > this before CommitSubTransaction sets s->state to TRANS_COMMIT; what
> > > if a subxact callback throws an error?
> >
> > Are
>__
>From: Daniel Westermann (DWE)
>Sent: Monday, July 15, 2019 13:01
>To: pgsql-hack...@postgresql.org
>Subject: Documentation fix for adding a column with a default value
>
>Hi,
>
>the tip in the "Adding a column" section is not true anymore since PostgreSQL
>
On Wed, 17 Jul 2019 at 15:42, Daniel Westermann (DWE) <
daniel.westerm...@dbi-services.com> wrote:
> >__
> >From: Daniel Westermann (DWE)
> >Sent: Monday, July 15, 2019 13:01
> >To: pgsql-hack...@postgresql.org
> >Subject: Documentation fix for adding a column w
101 - 113 of 113 matches
Mail list logo
