Re: Request to share information regarding deadlock in postgresql-8.1.18
От | John R Pierce |
---|---|
Тема | Re: Request to share information regarding deadlock in postgresql-8.1.18 |
Дата | |
Msg-id | fe76139a-bbe9-3b6b-ffff-84c6683c7fa2@hogranch.com обсуждение исходный текст |
Ответ на | Re: Request to share information regarding deadlock in postgresql-8.1.18 (Yogesh Sharma <Yogesh1.Sharma@nectechnologies.in>) |
Список | pgsql-general |
On 11/13/2016 11:52 PM, Yogesh Sharma wrote:
you can look those relation numbers up in the pg_catalog to see what they are. you can see what the processes are in pg_stat_activity.Currently machine is not available. Please suggest if any other approach to identify the same.
without access to the system thats generating the error, there's nothing you can learn.
>THis has nothing to do with the growing WAL logs... something is blocking checkpoints if a single WAL file keeps >growing, are you using some form of wal archiving, is that working correctly ? could something >be preventing checkpoints? what are the related checkpoint and WAL settings?Many WAL files are generated in pg_xlog directory. I don’t know how I can check checkpoint and WAL settings? By default setting of postgresql.conf is used.
I just noticed, you're talking about postgresql 8.1.18? thats an unsupported and obsolete version from 2009.
A standalone postgres installation that hasn't been configured for WAL archiving will normally only generate up to 2*CHECKPOINT_SEGMENTS + 1 wal files of 16MB each (assuming all defaults, thats 7 files). The obsolete 8.1 documentation on this is here, https://www.postgresql.org/docs/8.1/static/wal-configuration.html
If you've configured wal archiving, AND this isn't working correctly, WAL files can stack up indefinitely. See https://www.postgresql.org/docs/8.1/static/backup-online.html
-- john r pierce, recycling bits in santa cruz
В списке pgsql-general по дате отправления: