Julie Nishimura
<juliezain@xxxxxxxxxxx> writes:
> PostgreSQL 9.6.2 on x86_64-pc-linux-gnu
> It seems like we have one process running since
8/19. Is it any repercussion if we kill it?
> postgres=# select * from pg_stat_activity where pid
= '18986';
> -[ RECORD 1
]----+-------------------------------------------------------------------------
> datid | 2342921
> datname | symphony_middleware
> pid | 18986
> usesysid | 10
> usename | postgres
> application_name |
> client_addr |
> client_hostname |
> client_port |
> backend_start | 2019-08-19 02:00:59.683198+00
> xact_start | 2019-08-19 02:03:54.191741+00
> query_start | 2019-08-19 02:03:54.191741+00
> state_change | 2019-08-19 02:03:54.191742+00
> wait_event_type | BufferPin
> wait_event | BufferPin
> state | active
> backend_xid |
> backend_xmin | 1075730757
> query | autovacuum: VACUUM ANALYZE
public.resource_build (to prevent wraparound)
Since this is an anti-wraparound vacuum, autovacuum is
just going to
launch another one pretty soon if you kill this one.
Assuming that
the buffer pin blockage is real and not some kind of
broken shared
memory state, the new one will hang up at the same
spot. You'd be
better advised to find out what's pinning that buffer
and kill that.
Admittedly this is easier said than done, since there's
not much
infrastructure for seeing what's happening at that
level. But you
could look for transactions that are at least as old as
this one and
have some kind of lock on that table (according to
pg_locks).
If there are no such transactions, then the
corrupt-shared-memory
hypothesis becomes likely, and a postmaster restart is
indicated.
BTW, you really ought to be running something newer than
9.6.2.
regards, tom lane
