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
