On 2019-Oct-04, Moreno Andreo wrote:
> Il 04/10/19 17:30, Alvaro Herrera ha scritto:
> > On 2019-Oct-04, Moreno Andreo wrote:
> >
> > > select * from heap_page_items(get_raw_page('tablename',3159));
> > > select * from heap_page_items(get_raw_page('tablename',3160));
> > >
> > > and so on for about 5 or 6 pages.
> > Please paste the output of that for pages 3159 and 3160, as well as the
> > output of pg_controldata.
> >
> Thanks Alvaro,
> you can find attached the data you requested
Hmm, so it is tuple (3160,31) that's giving you grief -- it has xmax=12800
t_infomask=0x1103 (HEAP_XMAX_IS_MULTI | HEAP_XMIN_COMMITTED | others)
Which is weird, since it has none of the locking bits.
... and also the valid range of multixacts as of the last checkpoint was:
> NextMultiXactId dell'ultimo checkpoint: 366
> oldestMultiXID dell'ultimo checkpoint: 365
so the value 12800 is certainly not in range there.
I wonder if it would work to just clear that multixact with
SELECT ... WHERE ctid='(3160,31)' FOR UPDATE
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.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
