Antonin Houska <[email protected]> wrote:
> Nevertheless, on a closer look I concluded that the problem is not related to
> OOM. Rather, *any* ERROR that happens during cache invalidation can cause
> this. Attached here is cache_inval_failure.diff that reproduces the problem
> reliably:
>
> postgres=# CREATE TABLE t1(i int PRIMARY KEY); CLUSTER t1 USING t1_pkey; DROP
> TABLE t1;
> CREATE TABLE
> ERROR: failure during cache invalidation
> ERROR: attempted to delete invisible tuple
>
> (The Assert(ItemIdIsNormal(lp)) IMO fires only if VACUUM manages to reset the
> item pointer before heap_delete() gets called. With autovacuum=off, I get only
> the "failure during cache invalidation" error.)
>
> So I think we need to make sure that ERROR during cache invalidation becomes
> FATAL.
Maybe something like this?
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
diff --git a/src/backend/utils/cache/inval.c b/src/backend/utils/cache/inval.c
index 30048e153e5..97456e8888d 100644
--- a/src/backend/utils/cache/inval.c
+++ b/src/backend/utils/cache/inval.c
@@ -574,8 +574,15 @@ static void
ProcessInvalidationMessages(InvalidationMsgsGroup *group,
void (*func) (SharedInvalidationMessage *msg))
{
+ bool ExitOnAnyErrorSave = ExitOnAnyError;
+
+ /*
+ * Failure to invalidate cache is serious enough for the backend to exit.
+ */
+ ExitOnAnyError = true;
ProcessMessageSubGroup(group, CatCacheMsgs, func(msg));
ProcessMessageSubGroup(group, RelCacheMsgs, func(msg));
+ ExitOnAnyError = ExitOnAnyErrorSave;
}
/*
