| From: | Kim-Alexander Brodowski <kim(dot)brodowski(at)iserv(dot)eu> |
|---|---|
| To: | |
| Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #17042: Concurrent Modifications of PostgreSQL Function Can Corrupt Database |
| Date: | 2021-06-01 22:06:59 |
| Message-ID: | 1b9d6f1c-153d-c6e6-0a1d-4fcefd2534e8@iserv.eu |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2021-06-02 10:04:59 | BUG #17043: Full text search - to_tsvector treating a full stop wrong |
| Previous Message | Tom Lane | 2021-06-01 21:41:40 | Re: BUG #17042: Concurrent Modifications of PostgreSQL Function Can Corrupt Database |