From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm() |
Date: | 2023-07-02 21:54:20 |
Message-ID: | 20230702215420.mal2kg5a4kasme5j@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Hi,
On 2023-07-01 09:14:39 -0400, Andrew Dunstan wrote:
> On 2023-06-30 Fr 15:08, Tom Lane wrote:
> > Andrew Dunstan<andrew(at)dunslane(dot)net> writes:
> > > Me either. I think this might call for too much invention so I'm going
> > > to revert to plan A. The invalidation code won't be very much, and it
> > > should be a fairly rare event, so it doesn't need to be very clever.
> > The problem with rarely-executed code is that it's also hard to test.
> Your Plan B in the end proved less difficult than I thought, and certainly
> seems more robust than having to tangle with invalidations. I didn't try to
> do anything to wrap the values in a bytea, it didn't seem necessary. Here's
> a patch - it's not terribly long or invasive. I haven't tried backpatching
> it yet.
Hm. Is tying this to top-level transactions the right choice? What about
sequences like
SAVEPOINT x; ALTER TABLE ... ADD COLUMN ... DEFAULT; SELECT use_default FROM ...; ROLLBACK TO SAVEPOINT x;
SAVEPOINT y; ALTER TABLE ... ADD COLUMN ... DEFAULT; SELECT use_default FROM ...; ROLLBACK TO SAVEPOINT y;
Isn't that going to break the assumption that the key is unique within a
transaction? I think at the very least you'd need to make
Separately, will this work correctly with procedures keeping values alive
across transactions? I don't feel like I have a good grasp at how that whole
area is supposed to work...
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-07-02 21:57:03 | Re: BUG #17994: Invalidating relcache corrupts tupDesc inside ExecEvalFieldStoreDeForm() |
Previous Message | David Rowley | 2023-07-02 21:53:00 | Re: BUG #18002: Duplicate entries of row possible even after having primary key |