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 1ohHkE-00055q-5N for pgsql-hackers@arkaria.postgresql.org; Sat, 08 Oct 2022 21:52:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ohHkC-0000hH-1N for pgsql-hackers@arkaria.postgresql.org; Sat, 08 Oct 2022 21:52:28 +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 1ohHkB-0000h7-MH for pgsql-hackers@lists.postgresql.org; Sat, 08 Oct 2022 21:52:27 +0000 Received: from mail-pj1-x1035.google.com ([2607:f8b0:4864:20::1035]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1ohHk9-0003tz-7h for pgsql-hackers@lists.postgresql.org; Sat, 08 Oct 2022 21:52:26 +0000 Received: by mail-pj1-x1035.google.com with SMTP id pq16so7063028pjb.2 for ; Sat, 08 Oct 2022 14:52:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=d5cq6XsGRmaIuuD1XPHev5oYe3B2VKHvOePI3cPzSm0=; b=ZtydcijKMvwiJ+4XZnbF5P8Y+G2daUgg+Yt9XhqE1ylWkaNV9bb4uxHNrcn4HN7VS9 zt8MJW0feRbxCymQO+vu5lTwWFuaUopWlvrhRzFdU2aXGpPdg6uebwWRVDJfNXgOscsJ 69fCeoICCUj4+0ndQTSZZjL6Z6tl+cQqXpo7NWUlLcwCcQp5dZTUc8vNuyPeZpSjCHSe Ue97bCzd6p4lQ3dianrhywg/LUyQN+9MZrtIqdUYfJuLRE2zzhNM94Fqyf+YQifbGTwC 05XIGoTaw0z2mYFDZLdNdTP4FJh9oP33ZJWU8LdzQvKXMH3fNPku3/yrIMrG0DaJRW9P u4Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=d5cq6XsGRmaIuuD1XPHev5oYe3B2VKHvOePI3cPzSm0=; b=QOq6aOeCfMoUrjRewgyLQn7zAmYwvYa9S51ksVQAOUryO10f3W6tflLquu06GCtOB7 Rc1/yt3qoUaLnKLyWUNZKGRpKrF5TNaBDoFC6WHvEGbQQy7SOB5PqhdnUCfAww3KTfoa BRNAgJVyrTpNfsBuAiXwmfM0YkvsPBu7sWRpCV3Ak6Rfoayn8W/aZQljmXUPhJavoxKx Y8yEkVns7VkDNdkAY9RLhHwvscMpL8+PAFHxItgl7rxQHhAxFWUu5Ey2Fzb6Q0fDoq2h /3RWRH2K6S+Sj3UysxUQ+xQNGVK4Gh2HGuOY/8asbyNhAOZupAgjGyW1D0LKCh09hITY iaCQ== X-Gm-Message-State: ACrzQf3VOmvkmZrQyROJzCmeRo0g10DuOh8Q1HZC4GLYowqRwIMgabLb JYxXFciC8X867Mj/J4r01yk= X-Google-Smtp-Source: AMsMyM7V8oIWSZEHlX+yNogQFUfZG0mWDlB0BoM5NLuMWnCU42Ymxb7FHxe09ueEcRb/9vJxogWYrQ== X-Received: by 2002:a17:902:b907:b0:178:9d11:c978 with SMTP id bf7-20020a170902b90700b001789d11c978mr11753213plb.90.1665265943792; Sat, 08 Oct 2022 14:52:23 -0700 (PDT) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id u1-20020a17090ae00100b0020a7d076bfesm3542188pjy.2.2022.10.08.14.52.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 08 Oct 2022 14:52:23 -0700 (PDT) Date: Sat, 8 Oct 2022 14:52:21 -0700 From: Nathan Bossart To: Bharath Rupireddy Cc: Kyotaro Horiguchi , cary.huang@highgo.ca, pgsql-hackers@lists.postgresql.org, satyanarlapuram@gmail.com Subject: Re: Switching XLog source from archive to streaming when primary available Message-ID: <20221008215221.GA894639@nathanxps13> References: <20220915.172207.1940822794018442836.horikyota.ntt@gmail.com> <20220916.153629.1624554489607517175.horikyota.ntt@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, Sep 19, 2022 at 07:49:21PM +0530, Bharath Rupireddy wrote: > SwitchFromArchiveToStreamEnabled() seemed better at this point. I'm > attaching the v7 patch with that change. Please review it further. As I mentioned upthread [0], I'm still a little concerned that this patch will cause the state machine to go straight from archive recovery to streaming replication, skipping recovery from pg_wal. I wonder if this could be resolved by moving the standby to the pg_wal phase instead. Concretely, this line + if (switchSource) + break; would instead change currentSource from XLOG_FROM_ARCHIVE to XLOG_FROM_PG_WAL before the call to XLogFileReadAnyTLI(). I suspect the behavior would be basically the same, but it would maintain the existing ordering. However, I do see the following note elsewhere in xlogrecovery.c: * The segment can be fetched via restore_command, or via walreceiver having * streamed the record, or it can already be present in pg_wal. Checking * pg_wal is mainly for crash recovery, but it will be polled in standby mode * too, in case someone copies a new segment directly to pg_wal. That is not * documented or recommended, though. Given this information, the present behavior might not be too important, but I don't see a point in changing it without good reason. [0] https://postgr.es/m/20220906215704.GA2084086%40nathanxps13 -- Nathan Bossart Amazon Web Services: https://aws.amazon.com