Re: transaction blocking on COMMIT

From: Bob Jolliffe <bobjolliffe(at)gmail(dot)com>
To: Alexey M Boltenkov <padrebolt(at)yandex(dot)ru>
Cc: Christophe Pettus <xof(at)thebuild(dot)com>, Vijaykumar Jain <vijaykumarjain(dot)github(at)gmail(dot)com>, "pgsql-performa(dot)" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: transaction blocking on COMMIT
Date: 2021-05-27 13:08:18
Message-ID: CACd=f9es=RHVWRvNgd-=nx=FgDzxqRLA5Leqjug6_t28wyJY7g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

No brtfs. We are going to try turning off synchronous_commit
temporarily to see if there are underlying I/O issues.

On Mon, 24 May 2021 at 22:59, Alexey M Boltenkov <padrebolt(at)yandex(dot)ru> wrote:
>
> On 05/24/21 19:24, Christophe Pettus wrote:
> >
> >> On May 24, 2021, at 09:22, Bob Jolliffe <bobjolliffe(at)gmail(dot)com> wrote:
> >>
> >> It is hard to say as it only happens for 30s couple of times per day.
> >> Everything does return to normal after the blocking transaction is
> >> committed. It could be a disk thing or even a network issue (the java
> >> app is on a different machine to the db). But I never saw
> >> transactions blocked in commit before so was wondering if there is any
> >> rational set of reasons why it might do that.
> > One thing you can check is to turn off synchronous_commit (understanding the possibility of "time loss" in the event of a system crash). If that mitigates the problem, the issue is likely the I/O subsystem blocking during the fsync() operation.
> >
> >
> Just a question. Is there a btrfs(with compression maybe) around? 30
> seconds is a commit(file system) timeout for btrfs. Some processes like
> btrfs cleaner/allocate/worker on top of CPU/io use?
>

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Dean Gibson (DB Administrator) 2021-05-28 03:41:14 AWS forcing PG upgrade from v9.6 a disaster
Previous Message Eugen Konkov 2021-05-27 10:37:33 Count (select 1) subquery as constant