On 2019-Oct-04, Moreno Andreo wrote:
> 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....
This should do it:
SELECT * FROM the_broken_table WHERE <what I said above>
But of course I make no promise of it working or even having any effect
at all ...
> 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.
Hmm, well, it does sound like corrupted data, and if we suspect that
that's the case then there's not much we can do other than clearing the
page and moving on.
That exception code is STATUS_ACCESS_VIOLATION. Old Postgres bugs caused
that, many are fixed in current versions I think.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services