Re: Some other things about contrib/bloom and generic_xlog.c - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Some other things about contrib/bloom and generic_xlog.c
Date
Msg-id 18988.1460384946@sss.pgh.pa.us
Whole thread Raw
In response to Re: Some other things about contrib/bloom and generic_xlog.c  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Some other things about contrib/bloom and generic_xlog.c  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
Michael Paquier <michael.paquier@gmail.com> writes:
> Actually, as I look at this code for the first time, I find that
> GenericXLogFinish() is a very confusing interface. It makes no
> distinction between a page and the meta data associated to this page,
> this is controlled by a flag isNew and buffer data is saved as some
> delta. Actually, fullmage is not exactly true, this may refer to a
> page that has a hole. It seems to me that we should not have one but
> two routines: GenericXLogRegisterBuffer and
> GenericXLogRegisterBufData, similar to what the normal XLOG routines
> offer.

Hmm.  Maybe the documentation leaves something to be desired, but
I thought that the interface was reasonable if you grant that the
goal is to be easy to use rather than to have maximum performance.
The calling code only has to concern itself with making the actual
changes to the target pages, not with constructing WAL descriptions
of those changes.  Also, the fact that the changes don't have to be
made within a critical section is a bigger help than it might sound.

So I don't really have any problems with the API as such.  I tried
to improve the docs a day or two ago, but maybe that needs further
work.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: Some other things about contrib/bloom and generic_xlog.c
Next
From: nummervet nummervet
Date:
Subject: Re[2]: [HACKERS] Execute ignoring cursor?