Em sex., 15 de mai. de 2020 às 18:53, Alvaro Herrera <
alvhe...@2ndquadrant.com> escreveu:
> On 2020-Apr-10, Masahiko Sawada wrote:
>
> > Okay. I think only adding the check would also help with reducing the
> > likelihood. How about the changes for the current HEAD I've attached?
>
> Pushed this
Em sex., 15 de mai. de 2020 às 18:53, Alvaro Herrera <
alvhe...@2ndquadrant.com> escreveu:
> On 2020-Apr-10, Masahiko Sawada wrote:
>
> > Okay. I think only adding the check would also help with reducing the
> > likelihood. How about the changes for the current HEAD I've attached?
>
> Pushed this
On 2020-Apr-10, Masahiko Sawada wrote:
> Okay. I think only adding the check would also help with reducing the
> likelihood. How about the changes for the current HEAD I've attached?
Pushed this to all branches. (Branches 12 and older obviously needed an
adjustment.) Thanks!
> Related to this
On Thu, Apr 9, 2020 at 10:08 PM Peter Geoghegan wrote:
>
> On Thu, Apr 9, 2020 at 6:47 PM James Coleman wrote:
> > I believe the write pattern to this table likely looks like:
> > - INSERT
> > - UPDATE
> > - DELETE
> > for every row. But tomorrow I can do some more digging if needed.
>
> The pg_s
At Fri, 10 Apr 2020 12:32:31 +0900, Masahiko Sawada
wrote in
> On Fri, 10 Apr 2020 at 04:05, Peter Geoghegan wrote:
> >
> > On Wed, Apr 8, 2020 at 10:56 PM Masahiko Sawada
> > wrote:
> > > Here is the reproducer:
> >
> > What version of Postgres did you notice the actual customer issue on?
> >
On Fri, 10 Apr 2020 at 04:05, Peter Geoghegan wrote:
>
> On Wed, Apr 8, 2020 at 10:56 PM Masahiko Sawada
> wrote:
> > Here is the reproducer:
>
> What version of Postgres did you notice the actual customer issue on?
> I ask because I wonder if the work on B-Tree indexes in Postgres 12
> affects t
On Thu, Apr 9, 2020 at 6:47 PM James Coleman wrote:
> I believe the write pattern to this table likely looks like:
> - INSERT
> - UPDATE
> - DELETE
> for every row. But tomorrow I can do some more digging if needed.
The pg_stats.null_frac for the column/index might be interesting here. I
believe
On Thu, Apr 9, 2020 at 8:32 PM Peter Geoghegan wrote:
>
> On Thu, Apr 9, 2020 at 5:25 PM Peter Geoghegan wrote:
> > Was this a low cardinality index in the way I describe? If it was,
> > then we can hope (and maybe even verify) that the Postgres 12 work
> > noticeably ameliorates the problem.
>
>
On Thu, Apr 9, 2020 at 5:25 PM Peter Geoghegan wrote:
> Was this a low cardinality index in the way I describe? If it was,
> then we can hope (and maybe even verify) that the Postgres 12 work
> noticeably ameliorates the problem.
What I really meant was an index where hundreds or even thousands o
On Thu, Apr 9, 2020 at 1:37 PM James Coleman wrote:
> We saw the issue on our PG11 clusters. The specific index we noticed
> in the wal dump (I don't think we confirmed if there were others) as
> one on a `created_at` column, to give you an idea of cardinality.
You tend to get a lot of problems w
On Thu, Apr 9, 2020 at 3:05 PM Peter Geoghegan wrote:
>
> On Wed, Apr 8, 2020 at 10:56 PM Masahiko Sawada
> wrote:
> > Here is the reproducer:
>
> What version of Postgres did you notice the actual customer issue on?
> I ask because I wonder if the work on B-Tree indexes in Postgres 12
> affects
On Wed, Apr 8, 2020 at 10:56 PM Masahiko Sawada
wrote:
> Here is the reproducer:
What version of Postgres did you notice the actual customer issue on?
I ask because I wonder if the work on B-Tree indexes in Postgres 12
affects the precise behavior you get here with real world workloads.
It probab
On 2020-Apr-09, Masahiko Sawada wrote:
> The inner test in the comment "found the item" never tests the item
> for being dead. So maybe we can add !ItemIdIsDead(iid) to that
> condition. But there still is a race condition of recording multiple
> FPIs can happen. Maybe a better solution is to chan
13 matches
Mail list logo
