Date: Sun, 17 Oct 2021 23:21:28 -0500
From: Justin Pryzby <pryzby@telsasoft.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>,
	pgsql-hackers <pgsql-hackers@postgresql.org>,
	Andres Freund <andres@anarazel.de>
Subject: Re: prion failed with ERROR: missing chunk number 0 for toast value
 14334 in pg_toast_2619
Message-ID: <20211018042128.GB4679@telsasoft.com>
References: <f03ea04a-9b77-e371-9ab9-182cb35db1f9@iki.fi>
 <2472976.1621117273@sss.pgh.pa.us>
 <2591376.1621196582@sss.pgh.pa.us>
 <20210815144455.GQ10479@telsasoft.com>
 <20211017214315.GA4679@telsasoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20211017214315.GA4679@telsasoft.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: 
 <https://www.postgresql.org/message-id/20211018042128.GB4679%40telsasoft.com>
Precedence: bulk

On Sun, Oct 17, 2021 at 04:43:15PM -0500, Justin Pryzby wrote:
> On Sun, Aug 15, 2021 at 09:44:55AM -0500, Justin Pryzby wrote:
> > On Sun, May 16, 2021 at 04:23:02PM -0400, Tom Lane wrote:
> > > 1. Fix FullXidRelativeTo to be a little less trusting.  It'd
> > > probably be sane to make it return FirstNormalTransactionId
> > > when it'd otherwise produce a wrapped-around FullXid, but is
> > > there any situation where we'd want it to throw an error instead?
> > > 
> > > 2. Change pg_resetwal to not do the above.  It's not entirely
> > > apparent to me what business it has trying to force
> > > autovacuum-for-wraparound anyway, but if it does need to do that,
> > > can we devise a less klugy method?
> > > 
> > > It also seems like some assertions in procarray.c would be a
> > > good idea.  With the attached patch, we get through core
> > > regression just fine, but the pg_upgrade test fails immediately
> > > after the "Resetting WAL archives" step.
> > 
> > #2 is done as of 74cf7d46a.
> > 
> > Is there a plan to include Tom's procarray assertions ?
> 
> I'm confused about the state of this patch/thread.
> 
> make check causes autovacuum crashes (but then the regression tests succeed
> anyway).

Sorry, I was confused here.  autovacuum is not crashing as I said; the
BACKTRACE lines from the LOG added by Tom's debugging patch:

+       if (trace_toast_visibility)
+               ereport(LOG,
+                               errmsg("HeapTupleSatisfiesToast: xmin %u t_infomask 0x%04x",
+                                          HeapTupleHeaderGetXmin(tuple),
+                                          tuple->t_infomask),
+                               debug_query_string ? 0 : errbacktrace());


2021-10-17 22:56:57.066 CDT autovacuum worker[19601] LOG:  HeapTupleSatisfiesToast: xmin 2 t_infomask 0x0b02
2021-10-17 22:56:57.066 CDT autovacuum worker[19601] BACKTRACE:  
...

I see that the pg_statistic problem can still occur on v14.  I still don't have
a recipe to reproduce it, though, other than running VACUUM FULL in a loop.
Can I provide anything useful to debug it? xmin, infomask, core, and
log_autovacuum_min_duration=0 ??

-- 
Justin