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: http://www.postgresql.org/mailpref/pgsql-hackers