Re: Updating FSM on recovery

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Updating FSM on recovery
Дата
Msg-id 603c8f070810290617rcdc4da4yc2cf88deae4b5ae3@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Updating FSM on recovery  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список pgsql-hackers
> Buffer ReadBuffer(Relation reln, BlockNumber blockNum);
> Buffer ReadBufferExt(Relation reln, ForkNumber forkNum, BlockNumber
> blockNum, BufferAccessStrategy strategy, ReadBufferMode mode);
> Buffer ReadBufferWithoutRelcache(RelFileNode rnode, bool isTemp, ForkNumber
> forkNum, BlockNumber blockNum, ReadBufferMode mode);
>
> Thoughts?

I'm not sure why we would abbreviate Extended to Ext when nothing else
in here is abbreviated.  Seems needlessly inconsistent.

We may also want to rethink our approach to BufferAccessStrategy a
bit.  Right now, we don't admit that
GetBufferAccessStrategy(BAS_NORMAL) just returns a NULL pointer - we
expect the caller to get that strategy and later call
FreeBufferAccessStrategy it just as if it were a real object.
Particularly in light of this API change, I think we should just give
up on that.  Otherwise, a caller that wants to specify a fork number
or ReadBufferMode has to get and free an access strategy that doesn't
amount to anything.  Perhaps it would be sufficient to do this:

#define NormalBufferAccessStrategy NULL

That way, it would be easy to grep for any place where we used this to
get around a useless pair of get/free calls if we ever need to go back
and make a normal buffer access strategy into a real object.

...Robert


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

Предыдущее
От: "Robert Haas"
Дата:
Сообщение: Re: WIP patch: convert SQL-language functions to return tuplestores
Следующее
От: Andrew Sullivan
Дата:
Сообщение: Re: PostgreSQL + Replicator developer meeting 10/28