Re: Refactoring log_newpage

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Refactoring log_newpage
Дата
Msg-id 4F2A5BBF.7020900@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Refactoring log_newpage  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
On 02.02.2012 11:35, Simon Riggs wrote:
> On Thu, Feb 2, 2012 at 7:26 AM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com>  wrote:
>
>> Well, you can obviously check the catalogs for that, but you must be
>> assuming that you don't have access to the catalogs or this would be a
>> non-issue.
>>
>> You can also identify the kind of page by looking at the special area of the
>> stored page. See:
>> http://archives.postgresql.org/pgsql-hackers/2007-04/msg00392.php
>
> How does that work with different forks?

You have the fork number explicitly in the newpage record already.

> I think its very ugly to mark all sorts of different pages as if they
> were heap pages when they clearly aren't. I don't recall anything so
> ugly being allowed anywhere else in the system. Why is it *needed*
> here?

It's not needed. Beauty is in the eye of the beholder, but I don't find 
it all that ugly, and the comment in log_newpage explains it well.

I don't see much value in adding a new field to the record. Any tools 
that read the WAL format will need to be taught about that change. Not a 
huge issue, but I also don't see much gain. On the whole I'd be inclined 
to just leave it all alone, but whatever.

I don't think it's a good idea to rename XLOG_HEAP_NEWPAGE to 
XLOG_NEWPAGE. The WAL record is still part of the heapam rmgr, even if 
it's used by other access methods, too.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


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

Предыдущее
От: Dean Rasheed
Дата:
Сообщение: Re: Index-only scan performance regression
Следующее
От: Abhijit Menon-Sen
Дата:
Сообщение: Re: JSON for PG 9.2