Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oCFn5-0004VB-D7 for pgsql-hackers@arkaria.postgresql.org; Fri, 15 Jul 2022 07:31:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oCFn3-0007L5-7s for pgsql-hackers@arkaria.postgresql.org; Fri, 15 Jul 2022 07:31:09 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oCFn2-0007C6-SE for pgsql-hackers@lists.postgresql.org; Fri, 15 Jul 2022 07:31:08 +0000 Received: from mail-pj1-x102f.google.com ([2607:f8b0:4864:20::102f]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oCFmz-0001Sq-0s for pgsql-hackers@postgresql.org; Fri, 15 Jul 2022 07:31:07 +0000 Received: by mail-pj1-x102f.google.com with SMTP id o5-20020a17090a3d4500b001ef76490983so5339830pjf.2 for ; Fri, 15 Jul 2022 00:31:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:message-id:to:cc:subject:from:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=UbMZtqunbW9omTRrT469NRwTdddzDO87CYbLlL3dHO4=; b=bPNrNvm6/3Cp/hdGZn+M0fXRlBJH4sVT75HOeAfMXiKtDxW0g8bhOBLth9pkXTcie4 c05Yww/7m0i4A0XVPFcyuinw5Byt/+WkcLB2W6oEBNGGoea8nXW9Z7hCaV1f+NE/noRn D3FAB+EquCx4je02nQvubWx08UZk3hU1NOakp0ZQNpehDiynyWsTSZN86d0AMEJLd88Z L+CqFysumAqnpjrVdSgnXUp/zZ/5upb3cFkwErMq6d+OFyXh40FiVEw3PBP2zw34iA9z zLFuhZPYBcgKKs2f7nVgiYZB077VyigqmtrfJgIH1Z8FIxcl6lh1ZDApIzpUWcWKGmCM UC3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:message-id:to:cc:subject:from:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=UbMZtqunbW9omTRrT469NRwTdddzDO87CYbLlL3dHO4=; b=2lJOujIFFaXWDJNlDoyx9IqogaDnzRSoGJFE9/mUu1nCxxXjHcVtyep+IlMBXMtfPI b3s9ugQcssDI/X+eT3XxrEXN5YkjuOYfxij/Uf08vlMMPIZkbyGrxH//InbgaWKoDOzm EIXvfnLBjqfa7vgyqwwcGRrHX1aKW3VfAvxQHdxdzBsL7Zg/pqnv8EcI1pfWC1JPAeH8 4m4oGz76ypPxEXxIzWyghz/fu6Yt3Hx/S8Qb48vOut8cpS8joqoIPFB76MPadyqDSKzb Jg3IEwShl8wdxC0P8kh3Dn6BF5zSRjzGn79EuItUi3DVBTZaJU6efYMnoT2JNduguaH4 KnZg== X-Gm-Message-State: AJIora+Y8tzi5fWSAJo23d/COuRgI5vsIeeg1r+CP2m9vBPti3FUvpMy v7cKBaCBmrTrG+fOMLiZEEAIfWCZaog= X-Google-Smtp-Source: AGRyM1sEhWYZTsaP+y7+CVwpuUuA6KxyKKq3SvBS2tWQohXedDHvDZBrRztWm+r0E1dMqSoCgu2OOA== X-Received: by 2002:a17:902:cf4a:b0:16c:1b21:a3ae with SMTP id e10-20020a170902cf4a00b0016c1b21a3aemr12642728plg.38.1657870263442; Fri, 15 Jul 2022 00:31:03 -0700 (PDT) Received: from localhost (KD036014041111.ppp-bb.dion.ne.jp. [36.14.41.111]) by smtp.gmail.com with ESMTPSA id w9-20020aa79a09000000b0052b36de51cdsm993443pfj.111.2022.07.15.00.31.00 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Fri, 15 Jul 2022 00:31:02 -0700 (PDT) Date: Fri, 15 Jul 2022 16:30:59 +0900 (JST) Message-Id: <20220715.163059.337322153376727951.horikyota.ntt@gmail.com> To: alvherre@alvh.no-ip.org Cc: dilipbalaut@gmail.com, robertmhaas@gmail.com, michael@paquier.xyz, rjuju123@gmail.com, pgsql-hackers@postgresql.org Subject: Re: standby recovery fails (tablespace related) (tentative patch and discussion) From: Kyotaro Horiguchi In-Reply-To: <20220714214740.drhmvdx2aseqgvvb@alvherre.pgsql> References: <20220713164345.j3n67rc45rpa4vop@alvherre.pgsql> <20220714214740.drhmvdx2aseqgvvb@alvherre.pgsql> User-Agent: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk At Thu, 14 Jul 2022 23:47:40 +0200, Alvaro Herrera wrote in > Here's a couple of fixups. 0001 is the same as before. In 0002 I think Thanks! + if (!S_ISLNK(st.st_mode)) + #else + if (!pgwin32_is_junction(path)) + #endif + elog(ignore_invalid_pages ? WARNING : PANIC, + "real directory found in pg_tblspc directory: %s", de->d_name); A regular file with an oid-name also causes this error. Doesn't something like "unexpected non-(sym)link entry..." work? > CheckTablespaceDirectory ends up easier to read if we split out the test > for validity of the link. Looking at that again, I think we don't need > to piggyback on ignore_invalid_pages, which is already a stretch, so > let's not -- instead we can use allow_in_place_tablespaces if users need > a workaround. So that's 0003 (this bit needs more than zero docs, > however.) The result of 0003 looks good. 0002: +is_path_tslink(const char *path) What the "ts" of tslink stands for? If it stands for tablespace, the function is not specific for table spaces. We already have + errmsg("could not stat file \"%s\": %m", path)); I'm not sure we need such correctness, but what is failing there is lstat. I found similar codes in two places in backend and one place in frontend. So couldn't it be moved to /common and have a more generic name? - dir = AllocateDir(tblspc_path); - while ((de = ReadDir(dir, tblspc_path)) != NULL) + dir = AllocateDir("pg_tblspc"); + while ((de = ReadDir(dir, "pg_tblspc")) != NULL) xlog.c uses the macro XLOGDIR. Why don't we define TBLSPCDIR? - for (p = de->d_name; *p && isdigit(*p); p++); - if (*p) + if (strspn(de->d_name, "0123456789") != strlen(de->d_name)) continue; The pattern "strspn != strlen" looks kind of remote, or somewhat pedantic.. + char path[MAXPGPATH + 10]; .. - snprintf(path, MAXPGPATH, "%s/%s", tblspc_path, de->d_name); + snprintf(path, sizeof(path), "pg_tblspc/%s", de->d_name); I don't think we need the extra 10 bytes. A bit paranoic, but we can check the return value to confirm the d_name is fully stored in the buffer. > 0004 is straightforward: let's check for bad directories before logging > about consistent state. I was about to write a comment to do this when looking 0001. > After all this, I'm not sure what to think of dbase_redo. At line 3102, > is the directory supposed to exist or not? I'm confused as to what is > the expected state at that point. I rewrote this, but now I think my > rewrite continues to be confusing, so I'll have to think more about it. I'm not sure l3102 exactly points, but haven't we chosen to create everything required to keep recovery going, whether it is supposed to exist or not? > Another aspect are the tests. Robert described a scenario where the > previously committed version of this patch created trouble. Do we have > a test case to cover that problematic case? I think we should strive to > cover it, if possible. I counldn't recall that clearly and failed to dig out from the thread, but doesn't the "creating everything needed" strategy naturally save that case? We could add that test, but it seems to me a little cumbersome to confirm the test correctly detect that case.. regards. -- Kyotaro Horiguchi NTT Open Source Software Center