On Sat, Jul 8, 2017 at 9:06 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Sat, Jul 8, 2017 at 8:52 AM, Robert Haas <robertmh...@gmail.com> wrote: >> On Thu, Jul 6, 2017 at 5:54 AM, Kyotaro HORIGUCHI >> <horiguchi.kyot...@lab.ntt.co.jp> wrote: >>> Check for INIT_FORKNUM appears both accompanied and not >>> accompanied by check for RELPER.._UNLOGGED, so I'm not sure which >>> is the convention here. >> >> Checking only for INIT_FORKNUM seems logical to me. Also checking for >> RELPERSISTENCE_UNLOGGED just makes the code longer to no benefit. I >> guess Amit copied the test from ATExecSetTablespace, which does it as >> he did, but it seems unnecessarily long-winded. >> > > Okay. If you and Michael feel the check that way is better, I will > change and submit the patch. >
Changed as per suggestion. >>> By the way the comment of the function ReadBufferWithoutRelcache >>> has the following sentense. >>> >>> | * NB: At present, this function may only be used on permanent relations, >>> which >>> | * is OK, because we only use it during XLOG replay. If in the future we >>> | * want to use it on temporary or unlogged relations, we could pass >>> additional >>> | * parameters. >>> >>> and does >>> >>> | return ReadBuffer_common(smgr, RELPERSISTENCE_PERMANENT, forkNum, >>> blockNum, >>> mode, strategy, >>> &hit); >>> >>> This surely works since BufferAlloc recognizes INIT_FORK. But >>> some adjustment may be needed around here. >> >> Yeah, it should probably mention that the init fork of an unlogged >> relation is also OK. >> > > I think we should do that as a separate patch (I can write the same as > well) because that is not new behavior introduced by this patch, but > let me know if you think that we should add such a comment in this > patch itself. > Attached a separate patch to adjust the comment atop ReadBufferWithoutRelcache. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
fix_unlogged_hash_index_issue_v2.patch
Description: Binary data
fix_comment_atop_ReadBufferWithoutRelcache_v1.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
