Re: Some other things about contrib/bloom and generic_xlog.c

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Teodor Sigaev <teodor(at)sigaev(dot)ru>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Some other things about contrib/bloom and generic_xlog.c
Date: 2016-04-11 14:29:06
Message-ID: 18988.1460384946@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Paquier <michael(dot)paquier(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message nummervet nummervet 2016-04-11 14:31:19 Re[2]: [HACKERS] Execute ignoring cursor?
Previous Message Alexander Korotkov 2016-04-11 14:23:03 Re: Some other things about contrib/bloom and generic_xlog.c