Re: prion failed with ERROR: missing chunk number 0 for toast value 14334 in pg_toast_2619 - Mailing list pgsql-hackers
From | Justin Pryzby |
---|---|
Subject | Re: prion failed with ERROR: missing chunk number 0 for toast value 14334 in pg_toast_2619 |
Date | |
Msg-id | 20211017214315.GA4679@telsasoft.com Whole thread Raw |
In response to | Re: prion failed with ERROR: missing chunk number 0 for toast value 14334 in pg_toast_2619 (Justin Pryzby <pryzby@telsasoft.com>) |
Responses |
Re: prion failed with ERROR: missing chunk number 0 for toast value 14334 in pg_toast_2619
|
List | pgsql-hackers |
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). I notice now that Tom was referring to failures in pg_upgrade, so maybe didn't notice this part: $ grep -c BACKTRACE src/test/regress/log/postmaster.log 10 2021-10-17 16:30:42.623 CDT autovacuum worker[13490] BACKTRACE: postgres: autovacuum worker regression(errbacktrace+0x4e) [0x5650e5ea08ee] postgres: autovacuum worker regression(HeapTupleSatisfiesVisibility+0xd93) [0x5650e5a85283] postgres: autovacuum worker regression(heap_hot_search_buffer+0x2a5) [0x5650e5a7ec05] postgres: autovacuum worker regression(+0x1b573c) [0x5650e5a8073c] postgres: autovacuum worker regression(index_fetch_heap+0x5d) [0x5650e5a9345d] postgres: autovacuum worker regression(index_getnext_slot+0x5b) [0x5650e5a934fb] postgres: autovacuum worker regression(systable_getnext_ordered+0x26) [0x5650e5a92716] postgres: autovacuum worker regression(heap_fetch_toast_slice+0x33d) [0x5650e5a866ed] postgres: autovacuum worker regression(+0x162f61) [0x5650e5a2df61] postgres: autovacuum worker regression(toast_flatten_tuple+0xef) [0x5650e5a85dbf] postgres: autovacuum worker regression(+0x5b770d) [0x5650e5e8270d] postgres: autovacuum worker regression(+0x5b7d85) [0x5650e5e82d85] postgres: autovacuum worker regression(SearchCatCache3+0x1a9) [0x5650e5e83dc9] postgres: autovacuum worker regression(+0x29e4f5) [0x5650e5b694f5] postgres: autovacuum worker regression(+0x2a012e) [0x5650e5b6b12e] postgres: autovacuum worker regression(analyze_rel+0x1d1) [0x5650e5b6c851] postgres: autovacuum worker regression(vacuum+0x5c0) [0x5650e5bd4480] postgres: autovacuum worker regression(+0x40ce91) [0x5650e5cd7e91] postgres: autovacuum worker regression(+0x40df16) [0x5650e5cd8f16] postgres: autovacuum worker regression(AutoVacuumUpdateDelay+0) [0x5650e5cd9020] postgres: autovacuum worker regression(+0x41cccb) [0x5650e5ce7ccb] /lib/x86_64-linux-gnu/libpthread.so.0(+0x12890) [0x7f1dd1d26890] /lib/x86_64-linux-gnu/libc.so.6(__select+0x17) [0x7f1dd128fff7] postgres: autovacuum worker regression(+0x41d11e) [0x5650e5ce811e] postgres: autovacuum worker regression(PostmasterMain+0xd1c) [0x5650e5ce9c1c] postgres: autovacuum worker regression(main+0x220) [0x5650e5a1f4f0] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7f1dd119ab97] postgres: autovacuum worker regression(_start+0x2a) [0x5650e5a1f83a] -- Justin
pgsql-hackers by date: