public inbox for [email protected]help / color / mirror / Atom feed
[PATCH v7 05/13] Update BitmapAdjustPrefetchIterator parameter type to BlockNumber 20+ messages / 4 participants [nested] [flat]
* [PATCH v7 05/13] Update BitmapAdjustPrefetchIterator parameter type to BlockNumber @ 2024-02-13 00:04 Melanie Plageman <[email protected]> 0 siblings, 0 replies; 20+ messages in thread From: Melanie Plageman @ 2024-02-13 00:04 UTC (permalink / raw) BitmapAdjustPrefetchIterator() only used the blockno member of the passed in TBMIterateResult to ensure that the prefetch iterator and regular iterator stay in sync. Pass it the BlockNumber only. This will allow us to move away from using the TBMIterateResult outside of table AM specific code. --- src/backend/executor/nodeBitmapHeapscan.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/backend/executor/nodeBitmapHeapscan.c b/src/backend/executor/nodeBitmapHeapscan.c index dc8c312cafb..a6b98fa12a1 100644 --- a/src/backend/executor/nodeBitmapHeapscan.c +++ b/src/backend/executor/nodeBitmapHeapscan.c @@ -52,7 +52,7 @@ static TupleTableSlot *BitmapHeapNext(BitmapHeapScanState *node); static inline void BitmapDoneInitializingSharedState(ParallelBitmapHeapState *pstate); static inline void BitmapAdjustPrefetchIterator(BitmapHeapScanState *node, - TBMIterateResult *tbmres); + BlockNumber blockno); static inline void BitmapAdjustPrefetchTarget(BitmapHeapScanState *node); static inline void BitmapPrefetch(BitmapHeapScanState *node, TableScanDesc scan); @@ -230,7 +230,7 @@ BitmapHeapNext(BitmapHeapScanState *node) break; } - BitmapAdjustPrefetchIterator(node, tbmres); + BitmapAdjustPrefetchIterator(node, tbmres->blockno); valid = table_scan_bitmap_next_block(scan, tbmres); @@ -341,7 +341,7 @@ BitmapDoneInitializingSharedState(ParallelBitmapHeapState *pstate) */ static inline void BitmapAdjustPrefetchIterator(BitmapHeapScanState *node, - TBMIterateResult *tbmres) + BlockNumber blockno) { #ifdef USE_PREFETCH ParallelBitmapHeapState *pstate = node->pstate; @@ -360,7 +360,7 @@ BitmapAdjustPrefetchIterator(BitmapHeapScanState *node, /* Do not let the prefetch iterator get behind the main one */ TBMIterateResult *tbmpre = tbm_iterate(prefetch_iterator); - if (tbmpre == NULL || tbmpre->blockno != tbmres->blockno) + if (tbmpre == NULL || tbmpre->blockno != blockno) elog(ERROR, "prefetch and main iterators are out of sync"); } return; -- 2.40.1 --kqqpqghcwbcc3dt5 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v7-0006-table_scan_bitmap_next_block-returns-lossy-or-exa.patch" ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: BF mamba failure @ 2024-11-15 04:45 Michael Paquier <[email protected]> 0 siblings, 1 reply; 20+ messages in thread From: Michael Paquier @ 2024-11-15 04:45 UTC (permalink / raw) To: Bertrand Drouvot <[email protected]>; +Cc: Kouber Saparev <[email protected]>; [email protected] On Thu, Nov 14, 2024 at 10:07:41AM +0000, Bertrand Drouvot wrote: > === 1 > > Maybe use "generation" instead of generation in the comments (where it's not done, > some comments do it already). I've tweaked things to be more consistency, and applied that down to 15. > === 2 > > We could think about adding a test. That should be doable with replication slots > or custom pgstats kinds and probably injection points. But I'm not sure that's > worth it, as the code in the patch looks "simple" enough. Thoughts? The tricky part is that this path involves a backend shutdown. We should be able to do something with a wait before the dshash_find() in pgstat_release_entry_ref() with a BackgroundPsql object that gets stopped, but I'm not sure if we can guarantee a lookup of pg_stat_activity at this stage. Let me see.. -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: BF mamba failure @ 2025-08-04 10:00 Kouber Saparev <[email protected]> parent: Michael Paquier <[email protected]> 0 siblings, 1 reply; 20+ messages in thread From: Kouber Saparev @ 2025-08-04 10:00 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Bertrand Drouvot <[email protected]>; [email protected] We just had the same sudden replica shutdown, this time with version 17.3. 2025-08-02 22:10:02.229 UTC,,,473966,,67b3d76c.73b6e,14,,2025-02-18 00:42:20 UTC,8111/0,0,FATAL,XX000,"trying to drop stats entry already dropped: kind=relation dboid=16420 objoid=4169049057 refcount=1",,,,,"WAL redo at 6337E/9FF275E8 for Transaction/COMMIT: 2025-08-02 22:10:02.163756+00; dropped stats: 2/16420/4169049057 2/16420/4169049056 2/16420/4169049053 2/16420/4169049071 2/16420/4169049070 2/16420/4169049068 2/16420/4169049064 2/16420/4169049154 2/16420/4169049153 2/16420/4169049152 2/16420/4169049149; inval msgs: catcache 80 c atcache 79 catcache 80 catcache 79 catcache 55 catcache 54 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 55 catcache 54 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 55 catcache 54 catcache 7 catcache 6 catcache 7 catcache 6 catcache 32 cat cache 55 catcache 54 catcache 55 catcache 54 catcache 55 catcache 54 catcache 32 catcache 7 catcache 6 catcache 7 catcache 6 catcache 55 catcache 54 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 55 catcache 54 catcache 80 catcache 79 catcache 80 catcache 79 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 55 catcache 54 catcache 80 catcache 79 catcache 80 catcache 79 catcache 55 catcache 54 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 55 catcache 54 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 ca tcache 6 catcache 55 catcache 54 catcache 7 catcache 6 catcache 7 catcache 6 catcache 32 catcache 55 catcache 54 catcache 55 catcache 54 catcache 55 catcache 54 catcache 55 catcache 54 catcache 7 catcache 6 catcache 32 catcache 55 catcache 54 catcache 55 catcache 54 cat cache 32 catcache 7 catcache 6 catcache 55 catcache 54 catcache 32 catcache 7 catcache 6 catcache 7 catcache 6 catcache 55 catcache 54 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 cat cache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 55 catcache 54 catcache 80 catcache 79 catcache 80 catcache 79 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 cat cache 7 catcache 6 catcache 7 catcache 6 catcache 55 catcache 54 catcache 80 catcache 79 catcache 80 catcache 79 catcache 55 catcache 54 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 c atcache 7 catcache 6 catcache 7 catcache 6 catcache 55 catcache 54 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catca che 55 catcache 54 catcache 7 catcache 6 catcache 7 catcache 6 catcache 32 catcache 55 catcache 54 catcache 55 catcache 54 catcache 55 catcache 54 catcache 55 catcache 54 catcache 7 catcache 6 catcache 32 catcache 55 catcache 54 catcache 55 catcache 54 catcache 32 catca che 7 catcache 6 catcache 55 catcache 54 catcache 32 catcache 7 catcache 6 catcache 7 catcache 6 catcache 55 catcache 54 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcac he 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 55 catcache 54 catcache 80 catcache 79 catcache 80 catcache 79 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcac he 6 catcache 7 catcache 6 catcache 55 catcache 54 snapshot 2608 relcache 4169049053 snapshot 1214 relcache 4169049056 relcache 4169049057 relcache 4169049056 snapshot 2608 relcache 4169049056 relcache 4169049057 relcache 4169049053 snapshot 2608 relcache 4169049057 rel cache 4169049056 snapshot 2608 relcache 4169049056 snapshot 2608 snapshot 2608 snapshot 2608 relcache 4169049053 snapshot 2608 snapshot 1214 snapshot 2608 relcache 4169049064 snapshot 1214 relcache 4169049068 relcache 4169049070 relcache 4169049068 snapshot 2608 relcach e 4169049068 relcache 4169049070 relcache 4169049064 snapshot 2608 relcache 4169049071 relcache 4169049064 snapshot 2608 relcache 4169049064 relcache 4169049071 relcache 4169049071 relcache 4169049064 snapshot 2608 relcache 4169049070 relcache 4169049068 snapshot 2608 r elcache 4169049068 snapshot 2608 snapshot 2608 snapshot 2608 relcache 4169049064 snapshot 2608 snapshot 1214 snapshot 2608 relcache 4169049149 snapshot 1214 relcache 4169049152 relcache 4169049153 relcache 4169049152 snapshot 2608 relcache 4169049152 relcache 4169049153 relcache 4169049149 snapshot 2608 relcache 4169049154 relcache 4169049149 snapshot 2608 relcache 4169049149 relcache 4169049154 relcache 4169049154 relcache 4169049149 snapshot 2608 relcache 4169049153 relcache 4169049152 snapshot 2608 relcache 4169049152 snapshot 2608 snapshot 2608 snapshot 2608 relcache 4169049149 snapshot 2608 snapshot 1214",,,,"","startup",,0 2025-08-02 22:10:02.389 UTC,,,473962,,67b3d76b.73b6a,27,,2025-02-18 00:42:19 UTC,,0,LOG,00000,"startup process (PID 473966) exited with exit code 1",,,,,,,,,"","postmaster",,0 2025-08-02 22:10:02.389 UTC,,,473962,,67b3d76b.73b6a,28,,2025-02-18 00:42:19 UTC,,0,LOG,00000,"terminating any other active server processes",,,,,,,,,"","postmaster",,0 2025-08-02 22:10:02.516 UTC,,,473962,,67b3d76b.73b6a,29,,2025-02-18 00:42:19 UTC,,0,LOG,00000,"shutting down due to startup process failure",,,,,,,,,"","postmaster",,0 2025-08-02 22:10:02.563 UTC,,,473962,,67b3d76b.73b6a,30,,2025-02-18 00:42:19 UTC,,0,LOG,00000,"database system is shut down",,,,,,,,,"","postmaster",,0 На пт, 15.11.2024 г. в 6:45 Michael Paquier <[email protected]> написа: > On Thu, Nov 14, 2024 at 10:07:41AM +0000, Bertrand Drouvot wrote: > > === 1 > > > > Maybe use "generation" instead of generation in the comments (where it's > not done, > > some comments do it already). > > I've tweaked things to be more consistency, and applied that down to 15. > > > === 2 > > > > We could think about adding a test. That should be doable with > replication slots > > or custom pgstats kinds and probably injection points. But I'm not sure > that's > > worth it, as the code in the patch looks "simple" enough. Thoughts? > > The tricky part is that this path involves a backend shutdown. We > should be able to do something with a wait before the dshash_find() in > pgstat_release_entry_ref() with a BackgroundPsql object that gets > stopped, but I'm not sure if we can guarantee a lookup of > pg_stat_activity at this stage. Let me see.. > -- > Michael > ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: BF mamba failure @ 2025-08-06 23:18 Michael Paquier <[email protected]> parent: Kouber Saparev <[email protected]> 0 siblings, 2 replies; 20+ messages in thread From: Michael Paquier @ 2025-08-06 23:18 UTC (permalink / raw) To: Kouber Saparev <[email protected]>; +Cc: Bertrand Drouvot <[email protected]>; [email protected] On Mon, Aug 04, 2025 at 01:00:35PM +0300, Kouber Saparev wrote: > We just had the same sudden replica shutdown, this time with version 17.3. > > 2025-08-02 22:10:02.229 UTC,,,473966,,67b3d76c.73b6e,14,,2025-02-18 > 00:42:20 UTC,8111/0,0,FATAL,XX000,"trying to drop stats entry already > dropped: kind=relation dboid=16420 objoid=4169049057 refcount=1",,,,,"WAL > redo at 6337E/9FF275E8 for Transaction/COMMIT: 2025-08-02 You are close to wraparound for this relation. Is that vanilla streaming replication with heap? -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: BF mamba failure @ 2025-08-07 05:28 Bertrand Drouvot <[email protected]> parent: Michael Paquier <[email protected]> 1 sibling, 1 reply; 20+ messages in thread From: Bertrand Drouvot @ 2025-08-07 05:28 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Kouber Saparev <[email protected]>; [email protected] Hi, On Thu, Aug 07, 2025 at 08:18:26AM +0900, Michael Paquier wrote: > On Mon, Aug 04, 2025 at 01:00:35PM +0300, Kouber Saparev wrote: > > We just had the same sudden replica shutdown, this time with version 17.3. > > > > 2025-08-02 22:10:02.229 UTC,,,473966,,67b3d76c.73b6e,14,,2025-02-18 > > 00:42:20 UTC,8111/0,0,FATAL,XX000,"trying to drop stats entry already > > dropped: kind=relation dboid=16420 objoid=4169049057 refcount=1",,,,,"WAL > > redo at 6337E/9FF275E8 for Transaction/COMMIT: 2025-08-02 > > You are close to wraparound for this relation. Is that vanilla > streaming replication with heap? I was wondering about adding the "generation" (introduced in 818119afccd3) to the above error log message, thoughts? Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: BF mamba failure @ 2025-08-07 07:17 Michael Paquier <[email protected]> parent: Bertrand Drouvot <[email protected]> 0 siblings, 1 reply; 20+ messages in thread From: Michael Paquier @ 2025-08-07 07:17 UTC (permalink / raw) To: Bertrand Drouvot <[email protected]>; +Cc: Kouber Saparev <[email protected]>; [email protected] On Thu, Aug 07, 2025 at 05:28:17AM +0000, Bertrand Drouvot wrote: > On Thu, Aug 07, 2025 at 08:18:26AM +0900, Michael Paquier wrote: >> On Mon, Aug 04, 2025 at 01:00:35PM +0300, Kouber Saparev wrote: >> You are close to wraparound for this relation. Is that vanilla >> streaming replication with heap? > > I was wondering about adding the "generation" (introduced in 818119afccd3) to > the above error log message, thoughts? Yes, that could prove to be useful when debugging such issues. We do not have a lot of information here. -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: BF mamba failure @ 2025-08-07 08:35 Bertrand Drouvot <[email protected]> parent: Michael Paquier <[email protected]> 0 siblings, 1 reply; 20+ messages in thread From: Bertrand Drouvot @ 2025-08-07 08:35 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Kouber Saparev <[email protected]>; [email protected] Hi, On Thu, Aug 07, 2025 at 04:17:29PM +0900, Michael Paquier wrote: > On Thu, Aug 07, 2025 at 05:28:17AM +0000, Bertrand Drouvot wrote: > > On Thu, Aug 07, 2025 at 08:18:26AM +0900, Michael Paquier wrote: > >> On Mon, Aug 04, 2025 at 01:00:35PM +0300, Kouber Saparev wrote: > >> You are close to wraparound for this relation. Is that vanilla > >> streaming replication with heap? > > > > I was wondering about adding the "generation" (introduced in 818119afccd3) to > > the above error log message, thoughts? > > Yes, that could prove to be useful when debugging such issues. We do > not have a lot of information here. Yes, done in the attached. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: BF mamba failure @ 2025-08-08 00:09 Michael Paquier <[email protected]> parent: Bertrand Drouvot <[email protected]> 0 siblings, 0 replies; 20+ messages in thread From: Michael Paquier @ 2025-08-08 00:09 UTC (permalink / raw) To: Bertrand Drouvot <[email protected]>; +Cc: Kouber Saparev <[email protected]>; [email protected] On Thu, Aug 07, 2025 at 08:35:17AM +0000, Bertrand Drouvot wrote: > On Thu, Aug 07, 2025 at 04:17:29PM +0900, Michael Paquier wrote: >> Yes, that could prove to be useful when debugging such issues. We do >> not have a lot of information here. > > Yes, done in the attached. Thanks. With the next minor release happening next week, done that now so as we will able to gather more information from the field. -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: BF mamba failure @ 2025-08-08 09:04 Kouber Saparev <[email protected]> parent: Michael Paquier <[email protected]> 1 sibling, 1 reply; 20+ messages in thread From: Kouber Saparev @ 2025-08-08 09:04 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Bertrand Drouvot <[email protected]>; [email protected] Indeed, nothing exotic about our replication. As for the object 4169049057, I am not able to find it anywhere in the catalogs. Perhaps it was something that was dropped in the meantime. На чт, 7.08.2025 г. в 2:18 Michael Paquier <[email protected]> написа: > On Mon, Aug 04, 2025 at 01:00:35PM +0300, Kouber Saparev wrote: > > We just had the same sudden replica shutdown, this time with version > 17.3. > > > > 2025-08-02 22:10:02.229 UTC,,,473966,,67b3d76c.73b6e,14,,2025-02-18 > > 00:42:20 UTC,8111/0,0,FATAL,XX000,"trying to drop stats entry already > > dropped: kind=relation dboid=16420 objoid=4169049057 refcount=1",,,,,"WAL > > redo at 6337E/9FF275E8 for Transaction/COMMIT: 2025-08-02 > > You are close to wraparound for this relation. Is that vanilla > streaming replication with heap? > -- > Michael > ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: BF mamba failure @ 2025-09-09 13:07 Kouber Saparev <[email protected]> parent: Kouber Saparev <[email protected]> 0 siblings, 1 reply; 20+ messages in thread From: Kouber Saparev @ 2025-09-09 13:07 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Bertrand Drouvot <[email protected]>; [email protected] Yet again one of our replicas died. Should I file a bug report or something, what should we do in order to prevent it? Restart the database every month/week or so?... 2025-09-09 12:08:10.688 UTC,,,1510554,,67b3d8bc.170c9a,337,,2025-02-18 00:47:56 UTC,8111/0,0,FATAL,XX000,"trying to drop stats entry already dropped: kind=relation dboid=16420 objoid=767325170 refcount=2" ,,,,,"WAL redo at 66E4F/74A0F210 for Transaction/COMMIT: 2025-09-09 12:08:10.657171+00; dropped stats: 2/16420/767325174 2/16420/767325173 2/16420/767325170 2/16420/767325192 2/16420/767325191 2/16420/767 325189 2/16420/767325186 2/16420/767325198 2/16420/767325197 2/16420/767325196 2/16420/767325193; inval msgs: catcache 80 catcache 79 catcache 80 catcache 79 catcache 55 catcache 54 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 55 catcache 54 catcache 7 catcache 6 catc ache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 55 catcache 54 catcache 7 catcache 6 catcache 7 catcache 6 catcache 32 catcache 55 catcache 54 catcache 55 catcache 54 catcache 55 catcache 54 catcache 32 catcache 7 catcache 6 catcache 7 catcache 6 catcache 55 catcache 54 catc ache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 5 5 catcache 54 catcache 80 catcache 79 catcache 80 catcache 79 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 55 catcache 54 catcache 80 catcache 79 catcache 80 catcache 79 catcache 55 catcache 54 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 55 catcache 54 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 c atcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 55 catcache 54 catcache 7 catcache 6 catcache 7 catcache 6 catcache 32 catc ache 55 catcache 54 catcache 55 catcache 54 catcache 55 catcache 54 catcache 55 catcache 54 catcache 7 catcache 6 catcache 32 catcache 55 catcache 54 catcache 55 catcache 54 catcache 32 catcache 7 catcach e 6 catcache 55 catcache 54 catcache 32 catcache 7 catcache 6 catcache 7 catcache 6 catcache 55 catcache 54 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 55 catcache 54 catcache 80 catcache 79 catcache 80 catcache 79 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 55 catcache 54 catcache 80 catcache 79 catcache 8 0 catcache 79 catcache 55 catcache 54 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 c atcache 6 catcache 55 catcache 54 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catca che 6 catcache 7 catcache 6 catcache 55 catcache 54 catcache 7 catcache 6 catcache 7 catcache 6 catcache 32 catcache 55 catcache 54 catcache 55 catcache 54 catcache 55 catcache 54 catcache 55 catcache 54 catcache 7 catcache 6 catcache 32 catcache 55 catcache 54 catcache 55 catcache 54 catcache 32 catcache 7 catcache 6 catcache 55 catcache 54 catcache 32 catcache 7 catcache 6 catcache 7 catcache 6 catcache 55 catcache 54 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 c atcache 6 catcache 55 catcache 54 catcache 80 catcache 79 catcache 80 catcache 79 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 c atcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 55 catcache 54 snapshot 2608 relcache 767325170 snapshot 1214 relcache 767325173 relcache 767325174 relcache 767325173 snapshot 2608 relcache 767325173 relcache 767325174 relcache 767325170 snapshot 2608 relcache 767325174 relcache 767325173 snapshot 2608 relcache 767325173 snapshot 2608 snapshot 2608 snapshot 2608 relcache 767325170 snapshot 2608 snapshot 1214 snapshot 2608 relcache 767325186 snapshot 1214 relcache 767325189 relcache 767325191 relcache 767325189 snapshot 2608 relcache 767325189 relcache 767325191 relcache 767325186 snapshot 2 608 relcache 767325192 relcache 767325186 snapshot 2608 relcache 767325186 relcache 767325192 relcache 767325192 relcache 767325186 snapshot 2608 relcache 767325191 relcache 767325189 snapshot 2608 relcac he 767325189 snapshot 2608 snapshot 2608 snapshot 2608 relcache 767325186 snapshot 2608 snapshot 1214 snapshot 2608 relcache 767325193 snapshot 1214 relcache 767325196 relcache 767325197 relcache 76732519 6 snapshot 2608 relcache 767325196 relcache 767325197 relcache 767325193 snapshot 2608 relcache 767325198 relcache 767325193 snapshot 2608 relcache 767325193 relcache 767325198 relcache 767325198 relcache 767325193 snapshot 2608 relcache 767325197 relcache 767325196 snapshot 2608 relcache 767325196 snapshot 2608 snapshot 2608 snapshot 2608 relcache 767325193 snapshot 2608 snapshot 1214",,,,"","startup",,0 На пт, 8.08.2025 г. в 12:04 Kouber Saparev <[email protected]> написа: > Indeed, nothing exotic about our replication. > > As for the object 4169049057, I am not able to find it anywhere in the > catalogs. Perhaps it was something that was dropped in the meantime. > > На чт, 7.08.2025 г. в 2:18 Michael Paquier <[email protected]> написа: > >> On Mon, Aug 04, 2025 at 01:00:35PM +0300, Kouber Saparev wrote: >> > We just had the same sudden replica shutdown, this time with version >> 17.3. >> > >> > 2025-08-02 22:10:02.229 UTC,,,473966,,67b3d76c.73b6e,14,,2025-02-18 >> > 00:42:20 UTC,8111/0,0,FATAL,XX000,"trying to drop stats entry already >> > dropped: kind=relation dboid=16420 objoid=4169049057 >> refcount=1",,,,,"WAL >> > redo at 6337E/9FF275E8 for Transaction/COMMIT: 2025-08-02 >> >> You are close to wraparound for this relation. Is that vanilla >> streaming replication with heap? >> -- >> Michael >> > ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: BF mamba failure @ 2025-09-10 23:28 Michael Paquier <[email protected]> parent: Kouber Saparev <[email protected]> 0 siblings, 1 reply; 20+ messages in thread From: Michael Paquier @ 2025-09-10 23:28 UTC (permalink / raw) To: Kouber Saparev <[email protected]>; +Cc: Bertrand Drouvot <[email protected]>; [email protected] On Tue, Sep 09, 2025 at 04:07:45PM +0300, Kouber Saparev wrote: > Yet again one of our replicas died. Should I file a bug report or > something, what should we do in order to prevent it? Restart the database > every month/week or so?... I don't think we need another bug to report the same problem. We are aware that this may be an issue and that it is hard to track, the problem is to find room to be able to investigate it, at this stage. I may be able to come back to it soon-ishly, looking at how to trigger any race condition. The difficulty is to think how the current code is able to reach this state, because we have a race condition at hand in standbys. As a start, are these failures only in the startup process? Has the startup process reached a consistent state when the problem happens because the replay code is too eager at removing the stats entries? Has it not reached a consistent state. These could be useful hints to extract a reproducible test case, looking for common patterns. I'll ask around if I have seen cases like that in the user pool I have an access to. -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: BF mamba failure @ 2025-09-11 13:35 Kouber Saparev <[email protected]> parent: Michael Paquier <[email protected]> 0 siblings, 1 reply; 20+ messages in thread From: Kouber Saparev @ 2025-09-11 13:35 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Bertrand Drouvot <[email protected]>; [email protected] На чт, 11.09.2025 г. в 2:28 Michael Paquier <[email protected]> написа: > As a start, are these failures only in the startup process? Has the > startup process reached a consistent state when the problem happens > because the replay code is too eager at removing the stats entries? > Has it not reached a consistent state. These could be useful hints to > extract a reproducible test case, looking for common patterns. > The pattern is the same, although I am not 100% sure that the same replica is having this - it is a cascaded streaming replica, i.e. a replica of another replica. Once we had this in October 2024, with version 15.4, then in August 2025 with 17.3, and now in September again (17.3). The database is working for month(s) perfectly fine in a heavy production workload (lots of WALs etc.), and then all of a sudden it shuts down. Thanks for the feedback, and let me know if I could provide any additional info. -- Kouber ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: BF mamba failure @ 2025-09-12 00:37 Michael Paquier <[email protected]> parent: Kouber Saparev <[email protected]> 0 siblings, 1 reply; 20+ messages in thread From: Michael Paquier @ 2025-09-12 00:37 UTC (permalink / raw) To: Kouber Saparev <[email protected]>; +Cc: Bertrand Drouvot <[email protected]>; [email protected] On Thu, Sep 11, 2025 at 04:35:01PM +0300, Kouber Saparev wrote: > The pattern is the same, although I am not 100% sure that the same replica > is having this - it is a cascaded streaming replica, i.e. a replica of > another replica. Once we had this in October 2024, with version 15.4, then > in August 2025 with 17.3, and now in September again (17.3). The database > is working for month(s) perfectly fine in a heavy production workload (lots > of WALs etc.), and then all of a sudden it shuts down. The shutdown is caused by the startup process choking on redo. FWIW > Thanks for the feedback, and let me know if I could provide any additional > info. Okay, the bit about the cascading standby is a useful piece of information. Do you have some data about the relation reported in the error message this is choking on based on its OID? Is this actively used in read-only workloads, with the relation looked at in the cascading standby? Is hot_standby_feedback enabled in the cascading standby? With which process has this cascading standby been created? Does the workload of the primary involve a high consumption of OIDs for relations, say many temporary tables? Another thing that may help is the WAL record history. Are you for example seeing attempts to drop twice the same pgstats entry in WAL records? Perhaps the origin of the problem is in this area. A refcount of 2 is relevant, of course. I have looked a bit around but nothing has popped up here, so as far as I know you seem to be the only one impacted by that. 1d6a03ea4146 and dc5f9054186a are in 17.3, so perhaps something is still off with the drop when applied to cascading standbys. A vital piece of information may also be with "generation", which would show up in the error report thanks to bdda6ba30cbe, and that's included in 17.6. A first thing would be to update to 17.6 and see how things go for these cascading setups. If it takes a couple of weeks to have one report, we have a hunt that may take a few months at least, except if somebody is able to find out the race condition here, me or someone else. -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: BF mamba failure @ 2025-09-16 11:45 Kouber Saparev <[email protected]> parent: Michael Paquier <[email protected]> 0 siblings, 1 reply; 20+ messages in thread From: Kouber Saparev @ 2025-09-16 11:45 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Bertrand Drouvot <[email protected]>; [email protected] На пт, 12.09.2025 г. в 3:37 Michael Paquier <[email protected]> написа: > Okay, the bit about the cascading standby is a useful piece of > information. Do you have some data about the relation reported in the > error message this is choking on based on its OID? Is this actively > used in read-only workloads, with the relation looked at in the > cascading standby? This objoid=767325170 is non-existent, nor was it present in the previous shutdown (objoid=4169049057). So I guess it is something quasi-temporary that has been dropped afterwards. > Is hot_standby_feedback enabled in the cascading > standby? Yes, hot_standby_feedback = on. > With which process has this cascading standby been created? > Does the workload of the primary involve a high consumption of OIDs > for relations, say many temporary tables? > Yes, we have around 150 entries added and deleted per second in pg_class, and around 800 in pg_attribute. So something is actively creating and dropping tables all the time. > > Another thing that may help is the WAL record history. Are you for > example seeing attempts to drop twice the same pgstats entry in WAL > records? Perhaps the origin of the problem is in this area. A > refcount of 2 is relevant, of course. > How could we dig into this, i.e. inspecting such attempts in the WAL records? > > I have looked a bit around but nothing has popped up here, so as far > as I know you seem to be the only one impacted by that. > > 1d6a03ea4146 and dc5f9054186a are in 17.3, so perhaps something is > still off with the drop when applied to cascading standbys. A vital > piece of information may also be with "generation", which would show > up in the error report thanks to bdda6ba30cbe, and that's included in > 17.6. A first thing would be to update to 17.6 and see how things > go for these cascading setups. If it takes a couple of weeks to have > one report, we have a hunt that may take a few months at least, except > if somebody is able to find out the race condition here, me or someone > else. > > Is it enough to upgrade the replicas or we need to upgrade the primary as well? -- Kouber ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: BF mamba failure @ 2025-09-17 03:32 Michael Paquier <[email protected]> parent: Kouber Saparev <[email protected]> 0 siblings, 1 reply; 20+ messages in thread From: Michael Paquier @ 2025-09-17 03:32 UTC (permalink / raw) To: Kouber Saparev <[email protected]>; +Cc: Bertrand Drouvot <[email protected]>; [email protected] On Tue, Sep 16, 2025 at 02:45:03PM +0300, Kouber Saparev wrote: > На пт, 12.09.2025 г. в 3:37 Michael Paquier <[email protected]> написа: >> With which process has this cascading standby been created? >> Does the workload of the primary involve a high consumption of OIDs >> for relations, say many temporary tables? > > Yes, we have around 150 entries added and deleted per second in pg_class, > and around 800 in pg_attribute. So something is actively creating and > dropping tables all the time. The number of relations would most likely matter, I doubt that pg_attribute contributes a lot in the frictions. One of the test scenarios I am running is exactly that: a bunch of CREATE/DROP tables running concurrently with backends in a cascading standby accessing them, while tweaking the OID generated in the control file to force wraparounds. I am failing to re-create your problem, for now at least. > > Another thing that may help is the WAL record history. Are you for > > example seeing attempts to drop twice the same pgstats entry in WAL > > records? Perhaps the origin of the problem is in this area. A > > refcount of 2 is relevant, of course. > > > > How could we dig into this, i.e. inspecting such attempts in the WAL > records? Yeah, with pg_walinspect or pg_waldump, but I doubt that you retain enough WAL history to be able to ping at something specific. One pattern I am looking for is duplicated drops initiated from the WAL records, when wraparound hits, or at least if there's a window small enough that two WAL records are generated and attempt to generate the same entry drop. That's just an assumption at this stage. > Is it enough to upgrade the replicas or we need to upgrade the primary as > well? That would be both. There are always reasons to update to the latest minor version of Postgres. See the release notes for a bunch of them, that's usually convincing enough especially with CVEs addressed. :) -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: BF mamba failure @ 2026-07-07 10:13 Kouber Saparev <[email protected]> parent: Michael Paquier <[email protected]> 0 siblings, 1 reply; 20+ messages in thread From: Kouber Saparev @ 2026-07-07 10:13 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Bertrand Drouvot <[email protected]>; [email protected] We had this issue again, the database just stopped - PostgreSQL 17.6. FATAL,XX000,"trying to drop stats entry already dropped: kind=relation dboid=16420 objoid=3885511363 refcount=1 generation=0" There is no such object present in the database. Do you think the issue might be fixed in PostgreSQL 18.4?... Or PostgreSQL 19 eventually? На ср, 17.09.2025 г. в 6:33 Michael Paquier <[email protected]> написа: > On Tue, Sep 16, 2025 at 02:45:03PM +0300, Kouber Saparev wrote: > > На пт, 12.09.2025 г. в 3:37 Michael Paquier <[email protected]> > написа: > >> With which process has this cascading standby been created? > >> Does the workload of the primary involve a high consumption of OIDs > >> for relations, say many temporary tables? > > > > Yes, we have around 150 entries added and deleted per second in pg_class, > > and around 800 in pg_attribute. So something is actively creating and > > dropping tables all the time. > > The number of relations would most likely matter, I doubt that > pg_attribute contributes a lot in the frictions. One of the test > scenarios I am running is exactly that: a bunch of CREATE/DROP tables > running concurrently with backends in a cascading standby accessing > them, while tweaking the OID generated in the control file to force > wraparounds. I am failing to re-create your problem, for now at > least. > > > > Another thing that may help is the WAL record history. Are you for > > > example seeing attempts to drop twice the same pgstats entry in WAL > > > records? Perhaps the origin of the problem is in this area. A > > > refcount of 2 is relevant, of course. > > > > > > > How could we dig into this, i.e. inspecting such attempts in the WAL > > records? > > Yeah, with pg_walinspect or pg_waldump, but I doubt that you retain > enough WAL history to be able to ping at something specific. One > pattern I am looking for is duplicated drops initiated from the WAL > records, when wraparound hits, or at least if there's a window small > enough that two WAL records are generated and attempt to generate the > same entry drop. That's just an assumption at this stage. > > > > Is it enough to upgrade the replicas or we need to upgrade the primary as > > well? > > That would be both. There are always reasons to update to the latest > minor version of Postgres. See the release notes for a bunch of them, > that's usually convincing enough especially with CVEs addressed. :) > -- > Michael > ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: BF mamba failure @ 2026-07-07 23:59 Michael Paquier <[email protected]> parent: Kouber Saparev <[email protected]> 0 siblings, 1 reply; 20+ messages in thread From: Michael Paquier @ 2026-07-07 23:59 UTC (permalink / raw) To: Kouber Saparev <[email protected]>; +Cc: Bertrand Drouvot <[email protected]>; [email protected] On Tue, Jul 07, 2026 at 01:13:59PM +0300, Kouber Saparev wrote: > We had this issue again, the database just stopped - PostgreSQL 17.6. > > FATAL,XX000,"trying to drop stats entry already dropped: kind=relation > dboid=16420 objoid=3885511363 refcount=1 generation=0" > > There is no such object present in the database. > > Do you think the issue might be fixed in PostgreSQL 18.4?... Or PostgreSQL > 19 eventually? Well, honestly, hard to say. That's a case where a reproducible scenario would be useful, as it seems to ve very workload dependent in terms of handling of the relation entries.. (Aka I have not dug in details how to do that.) As one example, the buildfarm seems to be quite silent, but it would help if we need something like a wraparound for better reproducibility. -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: BF mamba failure @ 2026-07-08 10:53 Bertrand Drouvot <[email protected]> parent: Michael Paquier <[email protected]> 0 siblings, 1 reply; 20+ messages in thread From: Bertrand Drouvot @ 2026-07-08 10:53 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Kouber Saparev <[email protected]>; [email protected] Hi, On Wed, Jul 08, 2026 at 08:59:35AM +0900, Michael Paquier wrote: > On Tue, Jul 07, 2026 at 01:13:59PM +0300, Kouber Saparev wrote: > > We had this issue again, the database just stopped - PostgreSQL 17.6. > > > > FATAL,XX000,"trying to drop stats entry already dropped: kind=relation > > dboid=16420 objoid=3885511363 refcount=1 generation=0" > > > > There is no such object present in the database. > > > > Do you think the issue might be fixed in PostgreSQL 18.4?... Or PostgreSQL > > 19 eventually? > > Well, honestly, hard to say. That's a case where a reproducible > scenario would be useful, as it seems to ve very workload dependent in > terms of handling of the relation entries.. (Aka I have not dug in > details how to do that.) > > As one example, the buildfarm seems to be quite silent, but it would > help if we need something like a wraparound for better > reproducibility. So given that Kouber said that "we have around 150 entries added and deleted per second in pg_class, and around 800 in pg_attribute. So something is actively creating and dropping tables all the time.", OID reused is likely the culprit ( doable in months at this rate). To try to simulate an OID reuse, I created an extension to manually set the next OID and was able to reproduce the issue on 17.6, that way: Primary: create table popo (a int); Standby: select count(*) from popo; (keep this session open) Primary: SELECT oid FROM pg_class WHERE relname = 'popo'; (17044 here) Primary: drop table popo; Primary: checkpoint; Primary: vacuum; Primary: SELECT set_next_oid(17044::oid); Primary: create table popo2 (a int); Primary: SELECT oid FROM pg_class WHERE relname = 'popo2'; (verify it reused 17044) Primary: drop table popo2; Produces: 2026-07-08 10:30:22.566 UTC [2096038] FATAL: trying to drop stats entry already dropped: kind=relation dboid=5 objoid=17044 refcount=1 generation=0 So, the standby backend holds a local reference to the pgstat entry. When the first DROP is replayed on the standby, the entry is marked dropped=true and refcount goes from 2 to 1 so it can't be freed. Then when the second DROP (for popo2, same OID) is replayed, pgstat_drop_entry_internal() finds the entry with dropped=true and errors out. The good news is that it does not reproduce on the 17 STABLE branch, I guess it's due to 850b9218c8e being backpatched to stable branches. So a fix will be in the next minor versions. Michael, I wonder if that would make sense to add this "set_next_oid" kind of thing to a contrib module to test this kind of OID reuse issue. Same idea as xid_wraparound. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: BF mamba failure @ 2026-07-08 22:45 Michael Paquier <[email protected]> parent: Bertrand Drouvot <[email protected]> 0 siblings, 1 reply; 20+ messages in thread From: Michael Paquier @ 2026-07-08 22:45 UTC (permalink / raw) To: Bertrand Drouvot <[email protected]>; +Cc: Kouber Saparev <[email protected]>; [email protected] On Wed, Jul 08, 2026 at 10:53:47AM +0000, Bertrand Drouvot wrote: > So given that Kouber said that "we have around 150 entries added and deleted > per second in pg_class, and around 800 in pg_attribute. So something is actively > creating and dropping tables all the time.", OID reused is likely the culprit ( > doable in months at this rate). That would mean keeping around a session on the standby for long time. With a connection pooler, why not. > The good news is that it does not reproduce on the 17 STABLE branch, I guess it's > due to 850b9218c8e being backpatched to stable branches. So a fix will be in the > next minor versions. Due to the decision of using missing_ok=true in the end-of-transaction drops, that could indeed help. I'd be curious to hear back after the next minor release. If I have nothing more to do, I'll take it. > Michael, I wonder if that would make sense to add this "set_next_oid" kind of > thing to a contrib module to test this kind of OID reuse issue. Same idea as > xid_wraparound. That's probably larger than just the OIDs. Maybe something that's able to do what pg_resetwal does for the control file could be useful. Publishing another footgun sounds a bit annoying, but we also have stuff like pg_surgery, that serve a similar purpose to shortcut the backend. -- Michael Attachments: [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc) download ^ permalink raw reply [nested|flat] 20+ messages in thread
* Re: BF mamba failure @ 2026-07-09 04:34 Bertrand Drouvot <[email protected]> parent: Michael Paquier <[email protected]> 0 siblings, 0 replies; 20+ messages in thread From: Bertrand Drouvot @ 2026-07-09 04:34 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Kouber Saparev <[email protected]>; [email protected] Hi, On Thu, Jul 09, 2026 at 07:45:54AM +0900, Michael Paquier wrote: > On Wed, Jul 08, 2026 at 10:53:47AM +0000, Bertrand Drouvot wrote: > Due to the decision of using missing_ok=true in the end-of-transaction > drops, that could indeed help. I'd be curious to hear back after the > next minor release. Yeah, Kouber do you think you could upgrade to 17.11 or 18.5? (current schedule is August 13th, 2026 ([1])). > > Michael, I wonder if that would make sense to add this "set_next_oid" kind of > > thing to a contrib module to test this kind of OID reuse issue. Same idea as > > xid_wraparound. > > That's probably larger than just the OIDs. Maybe something that's > able to do what pg_resetwal does for the control file could be useful. > Publishing another footgun sounds a bit annoying, but we also have > stuff like pg_surgery, that serve a similar purpose to shortcut the > backend. Yeah. In addition to the OIDs I could think about the mxid (but I think they would be better suited in xid_wraparound). The others look way more difficult (if doable) to do outside pg_resetwal. So I'd be tempted to just add an oid_wraparound one and we could add this test case too. Thoughts? [1]: https://www.postgresql.org/developer/roadmap/ Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com ^ permalink raw reply [nested|flat] 20+ messages in thread
end of thread, other threads:[~2026-07-09 04:34 UTC | newest] Thread overview: 20+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-02-13 00:04 [PATCH v7 05/13] Update BitmapAdjustPrefetchIterator parameter type to BlockNumber Melanie Plageman <[email protected]> 2024-11-15 04:45 Re: BF mamba failure Michael Paquier <[email protected]> 2025-08-04 10:00 ` Re: BF mamba failure Kouber Saparev <[email protected]> 2025-08-06 23:18 ` Re: BF mamba failure Michael Paquier <[email protected]> 2025-08-07 05:28 ` Re: BF mamba failure Bertrand Drouvot <[email protected]> 2025-08-07 07:17 ` Re: BF mamba failure Michael Paquier <[email protected]> 2025-08-07 08:35 ` Re: BF mamba failure Bertrand Drouvot <[email protected]> 2025-08-08 00:09 ` Re: BF mamba failure Michael Paquier <[email protected]> 2025-08-08 09:04 ` Re: BF mamba failure Kouber Saparev <[email protected]> 2025-09-09 13:07 ` Re: BF mamba failure Kouber Saparev <[email protected]> 2025-09-10 23:28 ` Re: BF mamba failure Michael Paquier <[email protected]> 2025-09-11 13:35 ` Re: BF mamba failure Kouber Saparev <[email protected]> 2025-09-12 00:37 ` Re: BF mamba failure Michael Paquier <[email protected]> 2025-09-16 11:45 ` Re: BF mamba failure Kouber Saparev <[email protected]> 2025-09-17 03:32 ` Re: BF mamba failure Michael Paquier <[email protected]> 2026-07-07 10:13 ` Re: BF mamba failure Kouber Saparev <[email protected]> 2026-07-07 23:59 ` Re: BF mamba failure Michael Paquier <[email protected]> 2026-07-08 10:53 ` Re: BF mamba failure Bertrand Drouvot <[email protected]> 2026-07-08 22:45 ` Re: BF mamba failure Michael Paquier <[email protected]> 2026-07-09 04:34 ` Re: BF mamba failure Bertrand Drouvot <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox