Il 04/10/19 18:28, Alvaro Herrera ha scritto:
I wonder if it would work to just clear that multixact with
SELECT ... WHERE ctid='(3160,31)' FOR UPDATE
select ...what? :-) Sorry but it's totally beyond my knowledge and my
control.... after resolving the issue i'll surely go and search docs to
understand what we've done....
If this was in my hands, I would scan the WAL looking for the place that
last touched this page (and the latest FPI for this page, also). It
might have an explanation of what went on. Maybe use the page's LSN
(from pageinspect's page_header()) as starting point for the WAL
location that modified the page. I hope you have a WAL archive that
goes back to well before the previous checkpoint.
One thing I forgot to report is that this cluster is just upgraded from
a 9.1 that was crashing at least once a day (in many cases the upgrade
itself resolved the issue)
here's the log line
2019-10-03 15:11:52 CEST LOG: server process (PID 18668) was terminated
by exception 0xC0000005
In this case probably the access violation was due to a data corruption.
These are customer machines that are really badly kept and NTFS issues
are not that rare, so I won't bother investigating what's happened but
just make the customer up & running again.
Thanks for your time
Moreno
