On 2018-07-10 16:59:07 +0900, Michael Paquier wrote:
> On Tue, Jul 10, 2018 at 12:26:30AM -0700, Andres Freund wrote:
> > Why is the ReplicationSlotRelease() needed here? Souldn't the error
> > handling code do so automatically?
>
> Oh, indeed. I didn't know that PostgresMain was doing some
On Tue, Jul 10, 2018 at 12:26 AM Fujii Masao wrote:
> On Sun, Jul 8, 2018 at 11:48 AM, Haribabu Kommi
> wrote:
> >
> > On Fri, Jul 6, 2018 at 3:22 AM Fujii Masao
> wrote:
> >>
> >> On Wed, Jul 4, 2018 at 7:12 PM, Haribabu Kommi <
> kommi.harib...@gmail.com>
> >> wrote:
> >> >
> >> > Update
Hello Ildar,
I have a question about failover_timeout parameter.
Which would be better: implementing the parameter to retry at waiting time
or controlling the connection retry on the application side?
Also, I have no idea if the amount of random access by hostorder parameter will
have a good
On Tue, Jul 10, 2018 at 12:26:30AM -0700, Andres Freund wrote:
> Why is the ReplicationSlotRelease() needed here? Souldn't the error
> handling code do so automatically?
Oh, indeed. I didn't know that PostgresMain was doing some cleanup
here. There is a second place where this can be removed,
Hi,
On 2018-07-10 09:54:28 +0900, Michael Paquier wrote:
> > > Also, ERRCODE_FEATURE_NOT_SUPPORTED doesn't quite seem right. How about
> > > ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE?
> >
> > +1 to both of Andres' suggestions.
>
> Those indeed sound better. What do you think of the attached?
Hi,
On 2018-07-10 07:05:12 +, Jamison, Kirk wrote:
> Hello hackers,
>
> Recently, the problem on improving performance of multiple drop/truncate
> tables in a single transaction with large shared_buffers (as shown below) was
> solved by commit b416691.
> BEGIN;
>
Hello hackers,
Recently, the problem on improving performance of multiple drop/truncate tables
in a single transaction with large shared_buffers (as shown below) was solved
by commit b416691.
BEGIN;
truncate tbl001;
...
truncate tbl050;
Hi,
Le 09/07/2018 à 22:10, David Rowley a écrit :
> On 10 July 2018 at 00:47, Christophe Courtois
> wrote:
> (Christophe reports 2x performance regression with PG11 when using
> 1 partitions)
> Thanks for the report. Can you supply your test case when shows this
> regression?
> Please, can
Thank you for the notice.
At Mon, 9 Jul 2018 12:30:22 +0300, Arthur Zakirov
wrote in <20180709093021.GA9309@zakirov.localdomain>
> Hello,
>
> On Mon, Jul 09, 2018 at 06:07:24PM +0900, Kyotaro HORIGUCHI wrote:
> > The new version v4 is changed in the following points.
> >
> > - Don't renumber
On Thu, Jul 05, 2018 at 01:42:20AM +0900, Fujii Masao wrote:
> TBH, I have no numbers measured by the test.
> One question about your test is; how did you measure the *recovery time*
> of DROP DATABASE? Since it's *recovery* performance, basically it's not easy
> to measure that.
It would be
101 - 110 of 110 matches
Mail list logo