From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
Cc: | Ronan Dunklau <ronan(dot)dunklau(at)aiven(dot)io>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Subject: | Re: Failures in constraints regression test, "read only 0 of 8192 bytes" |
Date: | 2024-03-10 06:23:35 |
Message-ID: | CA+hUKGL0dBL-+0_GoN9H_9s0Fx3iOQu28D7Y5o=W0QyP2+s8iQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Mar 10, 2024 at 6:48 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> I won't be surprised if the answer is: if you're holding a reference,
> you have to get a pin (referring to bulk_write.c).
Ahhh, on second thoughts, I take that back, I think the original
theory still actually works just fine. It's just that somewhere in
our refactoring of that commit, when we were vacillating between
different semantics for 'destroy' and 'release', I think we made a
mistake: in RelationCacheInvalidate() I think we should now call
smgrreleaseall(), not smgrdestroyall(). That satisfies the
requirements for sinval queue overflow: we close md.c segments (and
most importantly virtual file descriptors), so our lack of sinval
records can't hurt us, we'll reopen all files as required. That's
what CLOBBER_CACHE_ALWAYS is effectively testing (and more). But the
smgr pointer remains valid, and retains only its "identity", eg hash
table key, and that's also fine. It won't be destroyed until after
the end of the transaction. Which was the point, and it allows things
like bulk_write.c (and streaming_read.c) to hold an smgr reference.
Right?
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2024-03-10 09:03:00 | Re: Combine headerscheck and cpluspluscheck scripts |
Previous Message | Thomas Munro | 2024-03-10 05:48:22 | Re: Failures in constraints regression test, "read only 0 of 8192 bytes" |