On Thu, Mar 9, 2017 at 11:15 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Mar 9, 2017 at 10:23 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: >> Right, if we use XLogReadBufferForRedoExtended() instead of >> XLogReadBufferExtended()/LockBufferForCleanup during relay routine, >> then it will restore FPI when required and can serve our purpose of >> acquiring clean up lock on primary bucket page. Yet another way could >> be to store some information like block number, relfilenode, forknum >> (maybe we can get away with some less info) of primary bucket in the >> fixed part of each of these records and then using that read the page >> and then take a cleanup lock. Now, as in most cases, this buffer >> needs to be registered only in cases when there are multiple overflow >> pages, I think having fixed information might hurt in some cases. > > Just because the WAL record gets larger? I think you could arrange to > record the data only in the cases where it is needed, but I'm also not > sure it would matter that much anyway. Off-hand, it seems better than > having to mark the primary bucket page dirty (because you have to set > the LSN) every time any page in the chain is modified. >
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? -- 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
