Julie Nishimura <juliezain@hotmail.com> 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
