Re: Lock leaking out of Transaction?

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: James Sewell <james(dot)sewell(at)jirotech(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Lock leaking out of Transaction?
Date: 2020-01-15 06:34:22
Message-ID: ea3109b1c140458aca663b0ffb6a3d262144f700.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, 2020-01-15 at 10:42 +1100, James Sewell wrote:
> I am trying to chase down a locking issue - it looks like a materialized view refresh is being
> held up by a relation lock which is held by an out of transaction session. My understanding was that
> this was not possible (see SQL output below).
>
> The locking session is making progress (I can see query_start advancing), which makes it even more confusing.
>
> Any advice?
>
> # select * from pg_locks l join pg_stat_activity a on l.pid = a.pid where relation = 1438729::regclass;
> -[ RECORD 1 ]------+---------------------------------------------------------------------------------
> locktype | relation
> database | 16428
> relation | 1438729
> mode | ShareUpdateExclusiveLock
> granted | f
> fastpath | f
> pid | 88955
> wait_event_type | Lock
> wait_event | relation
> state | active
> query | autovacuum: VACUUM supply_nodes (to prevent wraparound)
> backend_type | autovacuum worker
> -[ RECORD 2 ]------+---------------------------------------------------------------------------------
> locktype | relation
> database | 16428
> relation | 1438729
> mode | ExclusiveLock
> granted | f
> pid | 6839
> wait_event_type | Lock
> wait_event | relation
> state | active
> query | REFRESH MATERIALIZED VIEW CONCURRENTLY supply_nodes ;
> backend_type | client backend
> -[ RECORD 3 ]------+---------------------------------------------------------------------------------
> locktype | relation
> database | 16428
> relation | 1438729
> mode | ExclusiveLock
> granted | t
> pid | 65447
> application_name | PostgreSQL JDBC Driver
> wait_event_type | Client
> wait_event | ClientRead
> state | idle
> query | COMMIT
> backend_type | client backend

I cannot explain that either; could it be shared memory corruption?

What I would try is

SELECT pg_terminate_backend(65447);

and see if the session and its lock go away.

If that does not do the trick, I would restart PostgreSQL, which should get
rid of any possible memory corruption.

Then perhaps the anti-wraparoung autovacuum can succeed.
This autovacuum would also block you, but you should let it finish, since
it is an important system task.

Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2020-01-15 15:09:10 Re: Lock acquisition for partition table when setting generic plan
Previous Message yotsunaga.naoki@fujitsu.com 2020-01-15 02:58:45 Lock acquisition for partition table when setting generic plan