On Fri, Mar 10, 2017 at 6:21 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Fri, Mar 10, 2017 at 7:08 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>> On Fri, Mar 10, 2017 at 8:49 AM, Robert Haas <robertmh...@gmail.com> wrote:
>>> On Thu, Mar 9, 2017 at 9:34 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
>>>> Do we really need to set LSN on this page (or mark it dirty), if so
>>>> why?  Are you worried about restoration of FPI or something else?
>>> I haven't thought through all of the possible consequences and am a
>>> bit to tired to do so just now, but doesn't it seem rather risky to
>>> invent a whole new way of using these xlog functions?
>>> src/backend/access/transam/README describes how to do write-ahead
>>> logging properly, and neither MarkBufferDirty() nor PageSetLSN() is
>>> described as an optional step.
>> Just to salvage my point, I think this is not the first place where we
>> register buffer, but don't set lsn.  For XLOG_HEAP2_VISIBLE, we
>> register heap and vm buffers but set the LSN conditionally on heap
>> buffer.  Having said that, I see the value of your point and I am open
>> to doing it that way if you feel that is a better way.
> Right, we did that, and it seems to have worked.  But it was a scary
> exception that required a lot of thought.  Now, since we did it once,
> we could do it again, but I am not sure it is for the best.  In the
> case of vacuum, we knew that a vacuum on a large table could otherwise
> emit an FPI for every page, which would almost double the amount of
> write I/O generated by a vacuum - instead of WAL records + heap pages,
> you'd be writing FPIs + heap pages, a big increase.  Now here I think
> that the amount of write I/O that it's costing us is not so clear.
> Unless it's going to be really big, I'd rather do this in some way we
> can think is definitely safe.
> Also, if we want to avoid dirtying the primary bucket page by setting
> the LSN, IMHO the way to do that is to store the block number of the
> primary bucket page without registering the buffer, and then during
> recovery, lock that block.  That seems cleaner than hoping that we can
> take an FPI without setting the page LSN.

I was thinking that we will use REGBUF_NO_IMAGE flag as is used in
XLOG_HEAP2_VISIBLE record for heap buffer, that will avoid any extra
I/O and will make it safe as well.  I think that makes registering the
buffer safe without setting LSN for XLOG_HEAP2_VISIBLE record.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to