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 1mkkbo-0005ay-FI for pgsql-hackers@arkaria.postgresql.org; Wed, 10 Nov 2021 10:13:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mkkbn-0002MR-8c for pgsql-hackers@arkaria.postgresql.org; Wed, 10 Nov 2021 10:13:35 +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 1mkkbm-0002MH-To for pgsql-hackers@lists.postgresql.org; Wed, 10 Nov 2021 10:13:34 +0000 Received: from mail-wr1-x434.google.com ([2a00:1450:4864:20::434]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mkkbk-0003aM-Ji for pgsql-hackers@lists.postgresql.org; Wed, 10 Nov 2021 10:13:33 +0000 Received: by mail-wr1-x434.google.com with SMTP id b12so3067258wrh.4 for ; Wed, 10 Nov 2021 02:13:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=11InovzJjWlRlVe5tcFNQubYjU4cN+15XyGRLQ255Fw=; b=Q79z/fWl6Meh8U1a/owJ7gQxHqLVnDXVeOjEmtnICYyEWWrkJXV0tULAK7ENDgjTOc K4cNBdSZLgDVGTznWuHaYe5+oytJvskcsn/XU7pONphhbagN2fBo7qHPPvJQRZwEvHX3 /6hpEjle59sW67XATQzl2IXEayx0l2ekhWFTaGZ5TDn5qaDW90iQCUk25jrDp9xKhMpt sRlf549VAk6TushetYxnCSAGL7KTXBO5KBqM5szNfCil1b+B9Hg82Ctp/wmGvGFcw1LH gq3mI+ngSomyIIdPXFzaDAYkcQVeSIkB2itDeYhJmFz8LP/ZHpRxpFePlQxU2hPK0PPG rBog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=11InovzJjWlRlVe5tcFNQubYjU4cN+15XyGRLQ255Fw=; b=BXJBFe8vcZ+s/NI/vKn3YnYTtU8vtMEu/KPa7JQffrgaZQQIlDyrcM9pq7wP4Bp2JW rkiTAFN/dhy0V0eRaPTGXtITLn5ED3D5RlefHccl+PPqyo6z0zeI2LFAwxMExl2cmq2H LeCv9fZT1vZZvSCBNwo1oWbX4RLR6qPNjjJLay23DAfXGKDfJ3jDbZ/NbC81+JhLMP55 W3V3AX0gUUk0WpvmpLTjeo4oe72q3jZWGqKOeHpoVtbpjA0tfKdMz7m2lftPGQCX6tTu YUC0LK/BmIkPZZehDSPPjGt36lTZIxiLW4soSxHh9AN8RMHxjfHIzeGLMIWwSVFdpwbp mU+A== X-Gm-Message-State: AOAM533+JZmu8vwVK2wTGD2Q1qu+DNgD+IECs7uXyDfIToRiUgweA5/H 8TL/26SC20mtJa6gt6bR2UXgiQ1zC/XNhXvelj8= X-Google-Smtp-Source: ABdhPJx2UfyqO2g2562D4TYbhCmVZHS4vzK9QanFIQRvGDcegE9jeTLTth2AD5Pi7LfUQ/2PF2YMvNL73Ttb8UEReA4= X-Received: by 2002:a5d:4989:: with SMTP id r9mr18598397wrq.14.1636539211202; Wed, 10 Nov 2021 02:13:31 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: vignesh C Date: Wed, 10 Nov 2021 15:43:20 +0530 Message-ID: Subject: Re: Failed transaction statistics to measure the logical replication progress To: "osumi.takamichi@fujitsu.com" Cc: Greg Nancarrow , Masahiko Sawada , Amit Kapila , "houzj.fnst@fujitsu.com" , "pgsql-hackers@lists.postgresql.org" Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Nov 9, 2021 at 5:05 PM osumi.takamichi@fujitsu.com wrote: > Yes. I've rebased and updated the patch, paying attention to this point. > Attached the updated version. Thanks for the updated patch, few comments: 1) you could rename PgStat_StatSubWorkerPreparedXact to PgStat_SW_PreparedXactKey or a simpler name which includes key and similarly change PgStat_StatSubWorkerPreparedXactSize to PgStat_SW_PreparedXactEntry +/* prepared transaction */ +typedef struct PgStat_StatSubWorkerPreparedXact +{ + Oid subid; + char gid[GIDSIZE]; +} PgStat_StatSubWorkerPreparedXact; + +typedef struct PgStat_StatSubWorkerPreparedXactSize +{ + PgStat_StatSubWorkerPreparedXact key; /* hash key */ + + Oid subid; + char gid[GIDSIZE]; + PgStat_Counter xact_size; +} PgStat_StatSubWorkerPreparedXactSize; + 2) You can change prepared_size to sw_prepared_xact_entry or prepared_xact_entry since it is a hash entry with few fields + if (subWorkerPreparedXactSizeHash) + { + PgStat_StatSubWorkerPreparedXactSize *prepared_size; + + hash_seq_init(&hstat, subWorkerPreparedXactSizeHash); + while((prepared_size = (PgStat_StatSubWorkerPreparedXactSize *) hash_seq_search(&hstat)) != NULL) + { + fputc('P', fpout); + rc = fwrite(prepared_size, sizeof(PgStat_StatSubWorkerPreparedXactSize), 1, fpout); + (void) rc; /* we'll check for error with ferror */ + } 3) This need to be indented - w.relid, - w.command, - w.xid, - w.error_count, - w.error_message, - w.last_error_time + w.commit_count, + w.commit_bytes, + w.error_count, + w.error_bytes, + w.abort_count, + w.abort_bytes, + w.last_error_relid, + w.last_error_command, + w.last_error_xid, + w.last_error_count, + w.last_error_message, + w.last_error_time 4) Instead of adding a function to calculate the size, can we move PartitionTupleRouting from c file to the header file and use sizeof at the caller function? +/* + * PartitionTupleRoutingSize - exported to calculate total data size + * of logical replication mesage apply, because this is one of the + * ApplyExecutionData struct members. + */ +size_t +PartitionTupleRoutingSize(void) +{ + return sizeof(PartitionTupleRouting); +} 5) You could run pgindent and pgperltidy for the code and test code to fix the indent issues. + subWorkerPreparedXactSizeHash = hash_create("Subscription worker stats of prepared txn", + PGSTAT_SUBWORKER_HASH_SIZE, + &hash_ctl, + HASH_ELEM | HASH_STRINGS | HASH_CONTEXT); +# There's no entry at the beginning +my $result = $node_subscriber->safe_psql('postgres', +"SELECT count(*) FROM pg_stat_subscription_workers;"); +is($result, q(0), 'no entry for transaction stats yet'); 6) Few places you have used strlcpy and few places you have used memcpy, you can keep it consistent: + msg.m_command = command; + strlcpy(msg.m_gid, gid, sizeof(msg.m_gid)); + msg.m_xact_bytes = xact_size; + key.subid = subid; + memcpy(key.gid, gid, sizeof(key.gid)); + action = (create ? HASH_ENTER : HASH_FIND); Regards, Vignesh