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 1q6Cm8-0006c2-Ov for pgsql-hackers@arkaria.postgresql.org; Mon, 05 Jun 2023 16:09:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1q6Cm7-0002rW-BE for pgsql-hackers@arkaria.postgresql.org; Mon, 05 Jun 2023 16:09:43 +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 1q6Cm7-0002qq-1R for pgsql-hackers@lists.postgresql.org; Mon, 05 Jun 2023 16:09:43 +0000 Received: from mail-oo1-xc31.google.com ([2607:f8b0:4864:20::c31]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1q6Cm0-000PAv-Ff for pgsql-hackers@lists.postgresql.org; Mon, 05 Jun 2023 16:09:42 +0000 Received: by mail-oo1-xc31.google.com with SMTP id 006d021491bc7-555536b85a0so2372631eaf.2 for ; Mon, 05 Jun 2023 09:09:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685981375; x=1688573375; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=aYPIFYscUQoiUThr8VG6kgeUbFbV6A7QIDgJITnC9aA=; b=kkRo11kZfM8rEWLGJudUTmXDb3uVse5+JeePnP1HpEORqTqRfRGBV2dn2AHuZMeOPh qgF7HZlZUQI1BeE8VdUNohFz5D/MS51Q1FGZ+2bp1nWbyqYV03gnXdsgXwda29/3sfjR PKKkT5gVxcWnOEgBbM0S1JRWqVa7aMNfZhuEVWstf+0x8yL/FuVBZ2LuqkrjV5k7MwO1 HK20pWjKtb/4ifAJIezgGBDbFcnKU+TZQLW1aaJmVEXae7A5+bBeizFPfTw1oeyi47+q pX1+2Eu0MOn9qTV0fE9QnU99OCt1lJmZH7K5KJfY2bucQpXwnSwzNn48LMO7D5xOjaZU CqVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685981375; x=1688573375; 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=aYPIFYscUQoiUThr8VG6kgeUbFbV6A7QIDgJITnC9aA=; b=TxBRmI2yU/NwmWY3UanypexyNpZlww3IKav0BT4zjZs/FKW1VrLlj+76zXuRw0WEks K5wXTR6kRkWQMxhXqBvVQFkQNKqj1px1FN93SGmFYCoMwilv4rWqhrIOJEAc+2ENUa/X OtLGRh2clO+GQNCsuHChJdU4VWSwQzvPSuT5UOPcpm0/9F0jmPcB6KF51tc6TPXVNd1m D7/XSqUEB9J25sj63cid1EZtIWGBLLWVhbSi/mwxUHxbDuMYPR1fWdBU+2kNW1NowPTR hb57rxnw2WDTRBzNzgU0p6MRWdv6Vmr4lHe3edmBQaSypEs0ly1ZX/3RJqitDQTOSAaL 93iQ== X-Gm-Message-State: AC+VfDwHR7EkbsA3rcWZvmSNLFtdTDuTltZueObdQcaXYekKBa/VpXMx h9u6Jm0i9sPIbrglgk+rY+aiMCoaaR/Ufs35vieHwIcl X-Google-Smtp-Source: ACHHUZ4s06AafGVVdOwIqVXsk02zCRGU4uyfOKz2oQ9TyI5ZxTfZIi+vAeIiSu98FAF5vrxfcr6ggAuHAekg1S7fKQU= X-Received: by 2002:a4a:ba01:0:b0:558:b85e:cf7f with SMTP id b1-20020a4aba01000000b00558b85ecf7fmr294155oop.4.1685981374797; Mon, 05 Jun 2023 09:09:34 -0700 (PDT) MIME-Version: 1.0 References: <87cz2otiw3.fsf@wibble.ilmari.org> In-Reply-To: From: vignesh C Date: Mon, 5 Jun 2023 21:39:22 +0530 Message-ID: Subject: Re: Implement generalized sub routine find_in_log for tap test To: Michael Paquier Cc: Andrew Dunstan , =?UTF-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= , 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 Sun, 4 Jun 2023 at 03:51, Michael Paquier wrote: > > On Mon, May 29, 2023 at 07:49:52AM +0530, vignesh C wrote: > > Thanks for the comment, the attached v3 version patch has the changes > > for the same. > > -if (find_in_log( > - $node, $log_offset, > - qr/peer authentication is not supported on this platform/)) > +if ($node->log_contains( > + qr/peer authentication is not supported on this platform/), > + $log_offset,) > > This looks like a typo to me, the log offset is eaten. > > Except of that, I am on board with log_contains(). Thanks for fixing this. > There are two things that bugged me with the refactoring related to > connect_ok and connect_fails: > - check_connect_log_contents() is a name too complicated. While > looking at that I have settled to a simpler log_check(), as we could > perfectly use that for something else than connections as long as we > want to check multiple patterns at once. > - The refactoring of the documentation for the routines of Cluster.pm > became incorrect. For example, the patch does not list anymore > log_like and log_unlike for connect_ok. This new name suggested by you looks simpler, your documentation of having it in connect_ok and connect_fails and referring it to log_check makes it more clearer. Regards, Vignesh