Re: Failures in constraints regression test, "read only 0 of 8192 bytes"

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: Failures in constraints regression test, "read only 0 of 8192 bytes"
Дата
Msg-id CA+hUKGL0dBL-+0_GoN9H_9s0Fx3iOQu28D7Y5o=W0QyP2+s8iQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Failures in constraints regression test, "read only 0 of 8192 bytes"  (Thomas Munro <thomas.munro@gmail.com>)
Ответы Re: Failures in constraints regression test, "read only 0 of 8192 bytes"  (Heikki Linnakangas <hlinnaka@iki.fi>)
Список pgsql-hackers
On Sun, Mar 10, 2024 at 6:48 PM Thomas Munro <thomas.munro@gmail.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?



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: Failures in constraints regression test, "read only 0 of 8192 bytes"
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Combine headerscheck and cpluspluscheck scripts