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 1pFloW-0002SR-4d for pgsql-hackers@arkaria.postgresql.org; Thu, 12 Jan 2023 00:51: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 1pFloU-0000Mm-Us for pgsql-hackers@arkaria.postgresql.org; Thu, 12 Jan 2023 00:51: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 1pFloU-0000Md-LO for pgsql-hackers@lists.postgresql.org; Thu, 12 Jan 2023 00:51:26 +0000 Received: from mail-pl1-x62b.google.com ([2607:f8b0:4864:20::62b]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pFloN-0005Fu-JE for pgsql-hackers@lists.postgresql.org; Thu, 12 Jan 2023 00:51:26 +0000 Received: by mail-pl1-x62b.google.com with SMTP id d3so18577161plr.10 for ; Wed, 11 Jan 2023 16:51:19 -0800 (PST) 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=mx5yKrrFRAacIzbMZ/Dw+jSSfxLJKuM/PGIo2w+kPdw=; b=K7l5ln2NCjD/sP4X2BtI2RfGMbN6R8QqBjq4I0F/l9hBUPa4FUObi9Q6wqwpAaVgu3 kYfik+Og/tmlkgiElr5mHI1H29mBC9VWtTXVMgalM/oWOgE2wx1WXrpp0M3dU3R6eXhX VznNBMhkJJWQTqJKdN3kgl0LtQfis15aBxrGhKZcS7VuA1nfl4MtOAHulfloDLXqb4ey Z1bk4pEl47cKZqEPczmi4+rnsoGp5GqENt7m5FIjbVImgzT9Qw8RuYF8Fab+77T0i4+q tOs+op3EGWyIhLWUtqMc7qhtURIzjilYIBJrvBYjeCLUkPuG/u/7Zs73LX2qJQ1x6lAI 74lA== 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=mx5yKrrFRAacIzbMZ/Dw+jSSfxLJKuM/PGIo2w+kPdw=; b=sWyvGFnCmJ2N7a2bEOyfZ07gI+S69FpeaUPfPTu0iSr6DH0uWp6QoG0i2mK4Hvh6Zb vxakQSi6jTVTnFr52fCZMGYTnF5G41JZzerqGvuTKv7LxIpV/ogX/YgVCIn1u75QX91c vdcdf7chkcY8KkeJO1MwTWxI99cOIDNdtMYLZA5K5RlbEiSRrVk08SWG4qA6vOBv+iZC GohE1WHeEXjGmCn4R36EWOs8gA1PIwEZlJS5qfqyggaSRXOBtXaw2vEuN0mVMDqsbwh/ BvVYAeUIJf8ZStPjRF8oIob2B/bbN4rIjCJ+nDbtcZqwoIe6SapAEB4GVxl3OF5482Tf 26zA== X-Gm-Message-State: AFqh2kowXJdPHKc1yaxAJSOm+IqrK9Pfmc1zWyL+RktHBg9C9ohLwo3T V6t28rPnF2XASi6jIzGpFdg= X-Google-Smtp-Source: AMrXdXu5RwMdHHv2zJrsJKdcADCxlx1yzTFM65Op9/SO2tpyM7Me5UbyqwH54mp4DVWjw8Zw9xE7/Q== X-Received: by 2002:a17:902:bf47:b0:189:7548:2096 with SMTP id u7-20020a170902bf4700b0018975482096mr74386222pls.45.1673484677134; Wed, 11 Jan 2023 16:51:17 -0800 (PST) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id i7-20020a17090332c700b001897a8b537asm10825563plr.221.2023.01.11.16.51.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Jan 2023 16:51:16 -0800 (PST) Date: Wed, 11 Jan 2023 16:51:14 -0800 From: Nathan Bossart To: Bharath Rupireddy Cc: Kyotaro Horiguchi , Cary Huang , PostgreSQL Hackers , SATYANARAYANA NARLAPURAM Subject: Re: Switching XLog source from archive to streaming when primary available Message-ID: <20230112005114.GB2032194@nathanxps13> References: <20220916.153629.1624554489607517175.horikyota.ntt@gmail.com> <20221008215221.GA894639@nathanxps13> <20221009214725.GD900071@nathanxps13> <20221011031001.GC1322187@nathanxps13> 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 Tue, Oct 18, 2022 at 07:31:33AM +0530, Bharath Rupireddy wrote: > In summary, the standby state machine in WaitForWALToBecomeAvailable() > exhausts all the WAL in pg_wal before switching to streaming after > failing to fetch from archive. The v8 patch proposed upthread deviates > from this behaviour. Hence, attaching v9 patch that keeps the > behaviour as-is, that means, the standby exhausts all the WAL in > pg_wal before switching to streaming after fetching WAL from archive > for at least streaming_replication_retry_interval milliseconds. I think this is okay. The following comment explains why archives are preferred over existing files in pg_wal: * When doing archive recovery, we always prefer an archived log file even * if a file of the same name exists in XLOGDIR. The reason is that the * file in XLOGDIR could be an old, un-filled or partly-filled version * that was copied and restored as part of backing up $PGDATA. With your patch, we might replay one of these "old" files in pg_wal instead of the complete version of the file from the archives, but I think that is still correct. We'll just replay whatever exists in pg_wal (which may be un-filled or partly-filled) before attempting streaming. If that fails, we'll go back to trying the archives again. Would you mind testing this scenario? -- Nathan Bossart Amazon Web Services: https://aws.amazon.com