Re: CompactCheckpointerRequestQueue versus pad bytes

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: CompactCheckpointerRequestQueue versus pad bytes
Дата
Msg-id 9744.1342455371@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: CompactCheckpointerRequestQueue versus pad bytes  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: CompactCheckpointerRequestQueue versus pad bytes  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Jul 16, 2012 at 11:57 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> BTW, I'd be a lot happier about assuming that bare RelFileNode contains
>> no padding, because that's at least got all the fields the same type.
>> So that brings us back to the question of why this code is supporting
>> fsync requests for local relations in the first place.  Couldn't we have
>> it ignore those, and then only ship RelFileNode to the checkpointer?

> That's an awfully good point.  I think that was just sloppy coding on
> my part (cf commit debcec7dc31a992703911a9953e299c8d730c778).  +1 for
> changing it as you suggest.

OK, so I think the current proposal is:

1. Document that RelFileNode must not contain padding.

2. Change the fsync forwarding code to ignore backend-local relations,
and include only RelFileNode not RelFileNodeBackend in requests.

3. Zero the checkpointer requests[] array at shmem init time, so as
to ensure consistency of any pad bytes elsewhere in the request structs.

I will see about making this happen.  Since the fsync queue compaction
code got back-patched awhile ago, we need to back-patch the relevant
parts of this too.
        regards, tom lane


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [PERFORM] DELETE vs TRUNCATE explanation
Следующее
От: Robert Haas
Дата:
Сообщение: Re: CompactCheckpointerRequestQueue versus pad bytes