Re: found xmin from before relfrozenxid on pg_catalog.pg_authid

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: found xmin from before relfrozenxid on pg_catalog.pg_authid
Дата
Msg-id 20180527200006.hbwa2h7nfuunmnza@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: found xmin from before relfrozenxid on pg_catalog.pg_authid  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: found xmin from before relfrozenxid on pg_catalog.pg_authid  ("Nishant, Fnu" <nishantf@amazon.com>)
Re: found xmin from before relfrozenxid on pg_catalog.pg_authid  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Hi,

On 2018-05-27 13:22:21 -0400, Tom Lane wrote:
> But I don't think there's any need for special magic here: we just
> have to accept the fact that there's a need to flush that cache
> sometimes.  In normal use it shouldn't happen often enough to be a
> performance problem.

Yea, it's not that problematic. We already remove the local init
file. I started out trying to write a version of invalidation that also
WAL logs shared inval, but that turns out to be hard to do without
breaking compatibilty.  So I think we should just always unlink the
shared one - that seems to work well.


> FWIW, I'm not on board with "memcpy the whole row".  I think the right
> thing is more like what we do in RelationReloadIndexInfo, ie copy over
> the specific fields that we expect to be mutable.

But that's what RelationReloadIndexInfo() etc do?
    relp = (Form_pg_class) GETSTRUCT(pg_class_tuple);
    memcpy(relation->rd_rel, relp, CLASS_TUPLE_SIZE);
I don't think we need to modify anything outside of rd_rel at this
point?

I've a patch that seems to work, that mostly needs some comment
polishing.

Greetings,

Andres Freund


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

Предыдущее
От: "Jonathan S. Katz"
Дата:
Сообщение: SP-GiST failing to complete SP-GiST index build
Следующее
От: Dmitry Dolgov
Дата:
Сообщение: Re: jsonb iterator not fully initialized