Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Bruce Momjian <[EMAIL PROTECTED]> writes:
Can this now be marked as done?
* Modification of pg_class can happen while table in use by another
backend. Might lead to MVCC inside of syscache
>>
>> I'm not sure. Do you have any
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Can this now be marked as done?
> * Modification of pg_class can happen while table in use by another
> backend. Might lead to MVCC inside of syscache
I'm not sure. Do you have any record of what the concern was, in
detail? I don't underst
Alex Pilosov <[EMAIL PROTECTED]> writes:
> Tom, I'm not sure how (or whether) this relates to "alter table" happening
> when someone else is doing a SELECT from table.
The ALTER will wait for the SELECT to finish. That's not related to the
internal cache problem that I was worried about.
Tom Lane wrote:
>
> I just finished running the parallel regress tests with inval.c rigged
> to flush the relcache and syscache at every available opportunity,
> that is anytime we could recognize a shared-cache-inval message from
> another backend (see diff below). This setup gives a whole new u
I just finished running the parallel regress tests with inval.c rigged
to flush the relcache and syscache at every available opportunity,
that is anytime we could recognize a shared-cache-inval message from
another backend (see diff below). This setup gives a whole new universe
of meaning to the
