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 1meuDc-0002Iq-0y for pgsql-hackers@arkaria.postgresql.org; Mon, 25 Oct 2021 07:16:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1meuDa-00029G-RN for pgsql-hackers@arkaria.postgresql.org; Mon, 25 Oct 2021 07:16:26 +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 1meuDa-000296-I5 for pgsql-hackers@lists.postgresql.org; Mon, 25 Oct 2021 07:16:26 +0000 Received: from mail-wr1-x435.google.com ([2a00:1450:4864:20::435]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1meuDX-0006VT-UZ for pgsql-hackers@lists.postgresql.org; Mon, 25 Oct 2021 07:16:25 +0000 Received: by mail-wr1-x435.google.com with SMTP id m22so7672240wrb.0 for ; Mon, 25 Oct 2021 00:16:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aiven.io; s=google; h=from:to:cc:subject:date:message-id:organization:in-reply-to :references:mime-version:content-transfer-encoding; bh=rZf0ynuwvTIv/T37M+P4tn+qNnguF6wb7HFwqq7P4j0=; b=ibD/V4zHpTLN6/Oa0cMF79OldhILN9Xx4nQNjtiwjDKILI2xAay1FL2KCU3dzU4inA XcOcAkqEKm6w2C1qn0nkzgr3f1sJeaN6hjxa7nnNZMlyIr8eSNoN9GEmfclB0dBSzFQU 5GjvFl52RpMkELc7G+7YjG9bnQWsx79Volzg4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :in-reply-to:references:mime-version:content-transfer-encoding; bh=rZf0ynuwvTIv/T37M+P4tn+qNnguF6wb7HFwqq7P4j0=; b=mvMZNFmxMrALR48CwrclOuUD3jXlhaPQ8rYb19HG2Zz8APG5xM5wwWf8kUsr/ros94 fw3hpFkejoxmu810Yq3zJ3SEjLLtdW1zUebvAnyNpJASwE32XRbvjfaNeFzkyIl0lgw0 h+Vjgpt6e7wFswHjTVnKvJ43XbR9EPwUi5r/9mJW6xQOCyt4d7DAGdfJDXSvECtTL75i Oi2SMhQcmgELw6rJrp+ggoio16UoTouUm2C2xA3O/cl0qwU/mlXjX79c6f2sbobCXr5p jHCOLDq8L+CFPEUCYrEs+thbGMAZlzxxgZ1XWFSzvPsEN7Ws+ARRtg2N3S0PkoQoLnib Y61w== X-Gm-Message-State: AOAM530z5EllNEWi9mo7/N8VGc5jbv04qWjHtG84YMfBk9S1aWjTNml9 7iAqtfT+mOY7xZG0bWXBogx07Q== X-Google-Smtp-Source: ABdhPJwVcvGlUw8WQ/7jOmGEcIkhzUggJwOQKJAkMq0Nc9iBfGwJVagjQXGTCCK0/WP5KN0ua5YgBg== X-Received: by 2002:adf:a411:: with SMTP id d17mr15144654wra.232.1635146182739; Mon, 25 Oct 2021 00:16:22 -0700 (PDT) Received: from aivenronan.localnet (static-176-158-121-96.ftth.abo.bbox.fr. [176.158.121.96]) by smtp.gmail.com with ESMTPSA id 10sm19658374wme.27.2021.10.25.00.16.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Oct 2021 00:16:22 -0700 (PDT) From: Ronan Dunklau To: Michael Paquier Cc: pgsql-hackers@lists.postgresql.org, Bharath Rupireddy , Kyotaro Horiguchi , Masahiko Sawada Subject: Re: pg_receivewal starting position Date: Mon, 25 Oct 2021 09:15:32 +0200 Message-ID: <5781690.lOV4Wx5bFT@aivenronan> Organization: aiven In-Reply-To: References: <4126495.44csPzL39Z@aivenronan> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Le lundi 25 octobre 2021, 08:51:23 CEST Michael Paquier a =E9crit : > On Thu, Oct 21, 2021 at 10:36:42AM +0200, Ronan Dunklau wrote: > > Done. I haven't touched the timeline switch test patch for now, but I > > still > > include it here for completeness. >=20 > As 0001 and 0002 have been applied, I have put my hands on 0003, and > found a couple of issues upon review. >=20 > + Assert(slot_name !=3D NULL); > + Assert(restart_lsn !=3D NULL); > There is no need for those asserts, as we should support the case > where the caller gives NULL for those variables. Does it make sense though ? The NULL slot_name case handling is pretty=20 straight forward has it will be handled by string formatting, but in the ca= se=20 of a null restart_lsn, we have no way of knowing if the command was issued = at=20 all.=20 >=20 > + if (PQserverVersion(conn) < 150000) > + return false; > Returning false is incorrect for older server versions as we won't > fallback to the old method when streaming from older server. What > this needs to do is return true and set restart_lsn to > InvalidXLogRecPtr, so as pg_receivewal would just stream from the > current flush location. "false" should just be returned on error, > with pg_log_error(). Thank you, this was an oversight when moving from the more complicated erro= r=20 handling code.=20 >=20 > +$primary->psql('postgres', > + 'INSERT INTO test_table VALUES (generate_series(1,100));'); > +$primary->psql('postgres', 'SELECT pg_switch_wal();'); > +$nextlsn =3D > + $primary->safe_psql('postgres', 'SELECT pg_current_wal_insert_lsn();'); > +chomp($nextlsn); > There is no need to switch twice to a new WAL segment as we just need > to be sure that the WAL segment of the restart_lsn is the one > archived. Note that RESERVE_WAL uses the last redo point, so it is > better to use a checkpoint and reduce the number of logs we stream > into the new location. >=20 > Better to add some --no-sync to the new commands of pg_receivewal, to > not stress the I/O more than necessary. I have added some extra -n > while on it to avoid loops on failure. >=20 > Attached is the updated patch I am finishing with, which is rather > clean now. I have tweaked a couple of things while on it, and > documented better the new GetSlotInformation() in streamutil.c. > -- > Michael =2D-=20 Ronan Dunklau