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 1pbcTM-0008Cq-Cq for pgsql-hackers@arkaria.postgresql.org; Mon, 13 Mar 2023 07:19:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pbcTK-0007eL-Bj for pgsql-hackers@arkaria.postgresql.org; Mon, 13 Mar 2023 07:19:54 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pbcTK-0007eC-0Q for pgsql-hackers@lists.postgresql.org; Mon, 13 Mar 2023 07:19:54 +0000 Received: from mail-oa1-x29.google.com ([2001:4860:4864:20::29]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pbcTH-0003hE-NN for pgsql-hackers@lists.postgresql.org; Mon, 13 Mar 2023 07:19:53 +0000 Received: by mail-oa1-x29.google.com with SMTP id 586e51a60fabf-17671fb717cso12766973fac.8 for ; Mon, 13 Mar 2023 00:19:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678691989; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=KDcQk0VY1iQoUnG5f8fJmAXIuO0CThesjozIoheGens=; b=pK9seAieqIlW66u/Zi3zkluLNszQ61ylneGEZwBIqSfV1l6B7o71bEgLWSK/t68u5t t4qFGFsNdblSi/r07xfFJ7+WjxIIlbW3EeFuVh5DtdQPB+EA5RJ7AfOa7a5xCL+m3ak/ 3RNPvS4D/dhjxX8sPJDNqSUwyJ5DvcDsMmtYMv5z69gFPW49yQ11YsA4QffGYDTiV1BO xk6rauF3HG92jc/J3wkb7XQ5wuzjPjyQgqYFEv57mmSn5JLWtUh0G3O4PwIqR0GGKZrz u9Fg+e3aQI8AxjVp4hHqnl8bF0Aj8uRhVeEvPKjo7UE+L72liUPllssmXuJdZAEP7c7f kMYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678691989; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KDcQk0VY1iQoUnG5f8fJmAXIuO0CThesjozIoheGens=; b=xw3pvskimHNhuzpaJvIIKGF4Ys14xXys6zdX/enKXHlWzV25OaujnnF1GZjHlOjaBH KoEf1XF/agq2rZ8jJBch5/p1WSeJdE0adqkm3y7ugJz19U70/dOIO8VQ/G9/os9ZW+8E /FIkS84fKFSsDlzQu7l5wjqYgphHN3vZgSAP1r9okZkegaLhjM+7OuxsJT9KQi3fwxjK uyWj/GP3Ydv0yTatLW+6h7Nfjz2g2G2svGWUvjkCpjuhVCTVSrCPpcFwMzx92THTozn9 uUYvJvXEtdlIGzZr9kcrqAchDngo1AV6XRq8z5Ch6EFSXX8Dz6Y0ZyQmwRGCTX/SNwh1 h5Ww== X-Gm-Message-State: AO0yUKWC5CyKzVwicnjpU0jLAJJpHnE1WZ0G4DVxVv2sgVc+ORtjmMAT JLdLm/dASSfawF3B+jTksc+MGGv1djBTNBAROus= X-Google-Smtp-Source: AK7set9w5Z5FUPgLsRt7Ocdzl2K8zltEq5Pm0aAY/ulRVJcrD7c1v05Al4WAxXrZR0PbPGIUA1DhrKfkI61Ag1y7bQk= X-Received: by 2002:a05:6870:13d9:b0:177:8c4d:1ecd with SMTP id 25-20020a05687013d900b001778c4d1ecdmr2210398oat.10.1678691989493; Mon, 13 Mar 2023 00:19:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: vignesh C Date: Mon, 13 Mar 2023 12:49:10 +0530 Message-ID: Subject: Re: Add macros for ReorderBufferTXN toptxn To: Peter Smith Cc: PostgreSQL Hackers Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, 10 Mar 2023 at 04:36, Peter Smith wrote: > > Hi, > > During a recent code review, I was confused multiple times by the > toptxn member of ReorderBufferTXN, which is defined only for > sub-transactions. > > e.g. txn->toptxn member == NULL means the txn is a top level txn. > e.g. txn->toptxn member != NULL means the txn is not a top level txn > > It makes sense if you squint and read it slowly enough, but IMO it's > too easy to accidentally misinterpret the meaning when reading code > that uses this member. > > ~ > > Such code can be made easier to read just by introducing some simple macros: > > #define isa_toptxn(rbtxn) (rbtxn->toptxn == NULL) > #define isa_subtxn(rbtxn) (rbtxn->toptxn != NULL) > #define get_toptxn(rbtxn) (isa_subtxn(rbtxn) ? rbtxn->toptxn : rbtxn) > > ~ > > PSA a small patch that does this. > > (Tests OK using make check-world) > > Thoughts? Few comments: 1) Can we move the macros along with the other macros present in this file, just above this structure, similar to the macros added for txn_flags: /* Toplevel transaction for this subxact (NULL for top-level). */ +#define isa_toptxn(rbtxn) (rbtxn->toptxn == NULL) +#define isa_subtxn(rbtxn) (rbtxn->toptxn != NULL) +#define get_toptxn(rbtxn) (isa_subtxn(rbtxn) ? rbtxn->toptxn : rbtxn) 2) The macro name can be changed to rbtxn_is_toptxn, rbtxn_is_subtxn and rbtxn_get_toptxn to keep it consistent with others: /* Toplevel transaction for this subxact (NULL for top-level). */ +#define isa_toptxn(rbtxn) (rbtxn->toptxn == NULL) +#define isa_subtxn(rbtxn) (rbtxn->toptxn != NULL) +#define get_toptxn(rbtxn) (isa_subtxn(rbtxn) ? rbtxn->toptxn : rbtxn) 3) We could add separate comments for each of the macros: /* Toplevel transaction for this subxact (NULL for top-level). */ +#define isa_toptxn(rbtxn) (rbtxn->toptxn == NULL) +#define isa_subtxn(rbtxn) (rbtxn->toptxn != NULL) +#define get_toptxn(rbtxn) (isa_subtxn(rbtxn) ? rbtxn->toptxn : rbtxn) 4) We check if txn->toptxn is not null twice here both in if condition and in the assignment, we could retain the assignment operation as earlier to remove the 2nd check: - if (txn->toptxn) - txn = txn->toptxn; + if (isa_subtxn(txn)) + txn = get_toptxn(txn); We could avoid one check again by: + if (isa_subtxn(txn)) + txn = txn->toptxn; Regards, Vignesh