Thread: Health checks after machine crash?
Hi, v8.4 (Yes, it's archaic. Upgrade plan is in progress.) What queries should I run against the catalog tables to see whether or not the cluster is healthy after reboot? Thanks -- Angular momentum makes the world go 'round.
Ron <ronljohnsonjr@gmail.com> writes: > Hi, > > v8.4 (Yes, it's archaic. Upgrade plan is in progress.) Please do! :-) > What queries should I run against the catalog tables to see whether or > not the cluster is healthy after reboot? Is the cluster confi'd to be at risk of corruption after crash.. such as full_page_write=off, fsync=off? Do your logs show any obvious sign of corruption, bad blocks etc? You may have little to worry about since Pg is very crash tolerant even old versions 8.4 and prior. I'd try vacuum and analyze whole cluster plus dumpall >/dev/null and check for errors there too. Any sort of corruption likely to cause application problems likely to show up in so doing. HTH > Thanks -- Jerry Sievers Postgres DBA/Development Consulting e: postgres.consulting@comcast.net p: 312.241.7800
On 04/23/2018 12:58 PM, Jerry Sievers wrote: > Ron <ronljohnsonjr@gmail.com> writes: > >> Hi, >> >> v8.4 (Yes, it's archaic. Upgrade plan is in progress.) > Please do! :-) > >> What queries should I run against the catalog tables to see whether or >> not the cluster is healthy after reboot? > Is the cluster confi'd to be at risk of corruption after crash.. such as > full_page_write=off, fsync=off? #full_page_writes = on fsync = on > Do your logs show any obvious sign of corruption, bad blocks etc? Nothing I've notived. > You may have little to worry about since Pg is very crash tolerant even > old versions 8.4 and prior. > > I'd try vacuum and analyze whole cluster plus dumpall >/dev/null and > check for errors there too. Any sort of corruption likely to cause > application problems likely to show up in so doing. Will do. -- Angular momentum makes the world go 'round.