Re: BUG #17042: Concurrent Modifications of PostgreSQL Function Can Corrupt Database - Mailing list pgsql-bugs

From Kim-Alexander Brodowski
Subject Re: BUG #17042: Concurrent Modifications of PostgreSQL Function Can Corrupt Database
Date
Msg-id 1b9d6f1c-153d-c6e6-0a1d-4fcefd2534e8@iserv.eu
Whole thread Raw
In response to Re: BUG #17042: Concurrent Modifications of PostgreSQL Function Can Corrupt Database  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On 01.06.21 23:41, Tom Lane wrote:

> This doesn't seem terribly surprising. Occasionally one session's
> foobar() will run at an instant where type foo doesn't exist, thanks
> to the other session's script having dropped the type and not yet
> recreated it.  The "cache lookup failed" messages are a bit scary,
> but they arise in situations where the type did exist a moment ago
> but now it's gone.


I'm not too concerned with what happens when our test statements are 
executed. I don't care about them at all. From the moment the issue 
occurs the database is corrupted though. No backups including the schema 
will succeed and statements involving the function will not operate 
correctly. The schema is permanently corrupted. Novice users will likely 
be unable to recover from that state without recreating the entire 
database.




pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #17042: Concurrent Modifications of PostgreSQL Function Can Corrupt Database
Next
From: PG Bug reporting form
Date:
Subject: BUG #17043: Full text search - to_tsvector treating a full stop wrong