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 1qJKQZ-0004QN-MP for pgsql-hackers@arkaria.postgresql.org; Tue, 11 Jul 2023 20:57:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1qJKQY-0001cg-BX for pgsql-hackers@arkaria.postgresql.org; Tue, 11 Jul 2023 20:57:42 +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 1qJKQX-0001cX-Sy for pgsql-hackers@lists.postgresql.org; Tue, 11 Jul 2023 20:57:42 +0000 Received: from mail-oa1-x29.google.com ([2001:4860:4864:20::29]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qJKQS-003KO8-In for pgsql-hackers@postgresql.org; Tue, 11 Jul 2023 20:57:40 +0000 Received: by mail-oa1-x29.google.com with SMTP id 586e51a60fabf-1b056276889so5052818fac.2 for ; Tue, 11 Jul 2023 13:57:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neon-tech.20221208.gappssmtp.com; s=20221208; t=1689109055; x=1691701055; h=in-reply-to:references:subject:from:to:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=0wVyDqNz9sgVd7mirwGI6ufe7Zu0+0kWCQ9pmyWMhGU=; b=MxB2wrMxD/c/sF28cqZ55XgGQ9QOMOCV7CTy7ZIAuAiyJlbQGAlOv8Q0yjtYREhi8i dbCEnlAlMLAbzGgCyDBAamjSR10VEDrp84G/Kb8pULdnghxLFdDFeWFk+srVzJt1B53A BiY0Tfb8Xx9k1lPxIuWij0smz3JgPQo84uaQy58a3PomACSxkMwO+EPhdzc9ErZ2f3Y3 ybX/ChjZGKMOmxnlkqTfNB014YB1GeSFUj0JmCNJdUk/P2Z2qgJjiQ74AbO+o16pYvKv R0tQrePkiR9sUdtWRHeRArYGaZyXmVyceIUfmM7iH5tmSHrbeYEsAiaqd7Vfqw9mDItJ C2fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689109055; x=1691701055; h=in-reply-to:references:subject:from:to:message-id:date :content-transfer-encoding:mime-version:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=0wVyDqNz9sgVd7mirwGI6ufe7Zu0+0kWCQ9pmyWMhGU=; b=HcALtVLupMLGXeQyHGcTwuXTUeCJ4B/uWrvw6S4W1srKWka3vHywiz0PKGUQayyXyE heRvWxCdl8Ad+YAxD7lKXfk7/gZHeWp96puIxDNKBqP9Q5bxmKYYhyiZSpIewzC3aEAj a7jAjg9P0aI5jDL4z3WMq9vlqA8GIsnswGuriJFQgaou2U70JkJctr0481eZ3npIHpaI xYblCXXwYS8Ofs9R3hKtz1UiO3VI1YBCGNsLx+IMqUsSoxl3zBwB5XEf+qOES0LNbHAV DzMDKZe/Lx4eFxOObPFfPel72sU1rJlAdVKxWpfOuOIAc9XiAz5GbXrwoERuWr0+flNZ NGWw== X-Gm-Message-State: ABy/qLaHM8NPLo/Ru6cCD4Ubu21grKpLauLlZ+uGKjbUbUs+dndzDzZ+ qlpk1l12t/Cn0vva8iYl4hug8EihpMWPfYVFi7Stow== X-Google-Smtp-Source: APBJJlGPMiY9AVu6ySttMefqWZaWZl9eEGrgs3rbKAFxJTfKbUk/2Yb6hOvTeE2QsGavxuYN73eG7w== X-Received: by 2002:a05:6870:63a0:b0:1b7:5ee5:65dc with SMTP id t32-20020a05687063a000b001b75ee565dcmr2501153oap.39.1689109055664; Tue, 11 Jul 2023 13:57:35 -0700 (PDT) Received: from localhost ([2607:fb90:f280:130d:3996:e070:71ee:42fb]) by smtp.gmail.com with ESMTPSA id e13-20020a0568301e4d00b006b87f593877sm1285720otj.37.2023.07.11.13.57.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 11 Jul 2023 13:57:35 -0700 (PDT) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Tue, 11 Jul 2023 15:57:34 -0500 Message-Id: To: "Matthias van de Meent" , "PostgreSQL Hackers" From: "Tristan Partin" Subject: Re: Extensible storage manager API - SMGR hook Redux X-Mailer: aerc 0.15.2-84-g9a3ccd9a95db References: In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > Subject: [PATCH v1 1/2] Expose f_smgr to extensions for manual implementa= tion From what I can see, all the md* APIs that were exposed in md.h can now be made static in md.c. The only other references to those APIs were in smgr.c. > Subject: [PATCH v1 2/2] Prototype: Allow tablespaces to specify which SMG= R > they use > -typedef uint8 SMgrId; > +/* > + * volatile ID of the smgr. Across various configurations IDs may vary, > + * true identity is the name of each smgr. > + */ > +typedef int SMgrId; >=20 > -#define MaxSMgrId UINT8_MAX > +#define MaxSMgrId INT_MAX In a future revision of this patch, seems worthwhile to just start as int instead of a uint8 to avoid this song and dance. Maybe int8 instead of int? > +static SMgrId recent_smgrid =3D -1; You could use InvalidSmgrId here. > +void smgrvalidatetspopts(const char *smgrname, List *opts) > +{ > + SMgrId smgrid =3D get_smgr_by_name(smgrname, false); > + > + smgrsw[smgrid].smgr_validate_tspopts(opts); > +} > + > +void smgrcreatetsp(const char *smgrname, Oid tsp, List *opts, bool isred= o) > +{ > + SMgrId smgrid =3D get_smgr_by_name(smgrname, false); > + > + smgrsw[smgrid].smgr_create_tsp(tsp, opts, isredo); > +} > + > +void smgrdroptsp(const char *smgrname, Oid tsp, bool isredo) > +{ > + SMgrId smgrid =3D get_smgr_by_name(smgrname, false); > + > + smgrsw[smgrid].smgr_drop_tsp(tsp, isredo); > +} Do you not need to check if smgrid is the InvalidSmgrId? I didn't see any other validation anywhere. > + char *smgr; > + List *smgropts; /* list of DefElem nodes */ smgrname would probably work better alongside tablespacename in that struct. > @@ -221,7 +229,7 @@ mdexists(SMgrRelation reln, ForkNumber forknum) > if (!InRecovery) > mdclose(reln, forknum); >=20 > - return (mdopenfork(reln, forknum, EXTENSION_RETURN_NULL) !=3D NUL= L); > + return (mdopenfork(mdreln, forknum, EXTENSION_RETURN_NULL) !=3D N= ULL); > } Was this a victim of a bad rebase? Seems like it belongs in the previous patch. > +void mddroptsp(Oid tsp, bool isredo) > +{ > + > +} Some functions in this file have the return type on the previous line. This is a pretty slick patchset. Excited to read more dicussion and how it evolves. --=20 Tristan Partin Neon (https://neon.tech)