Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rSEVm-00CGaG-Vg for pgsql-hackers@arkaria.postgresql.org; Tue, 23 Jan 2024 11:00:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rSEVj-00BzSP-Vv for pgsql-hackers@arkaria.postgresql.org; Tue, 23 Jan 2024 11:00:07 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rSEVj-00BzSH-J9 for pgsql-hackers@lists.postgresql.org; Tue, 23 Jan 2024 11:00:07 +0000 Received: from mail-lj1-x236.google.com ([2a00:1450:4864:20::236]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rSEVg-002wpk-TT for pgsql-hackers@postgresql.org; Tue, 23 Jan 2024 11:00:06 +0000 Received: by mail-lj1-x236.google.com with SMTP id 38308e7fff4ca-2ccec119587so53051801fa.0 for ; Tue, 23 Jan 2024 03:00:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706007603; x=1706612403; darn=postgresql.org; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=/6cXgf+xnlP1IbyBgauH/S9YxW0lVZDsargGcVCvBQU=; b=JzxWhRXY9pS5j6EwORePcVq/ufXLiX5a8nDjCvgMJLp4qI35FQyPcw1HNeC3GFZmtk kF1yZIg5aX85RntUISv1jTZM+23+DWQ1gj2UHfAaEOxic+y6E2rxQ39MUF+q8WtFesIO DZ328flVQIEBW3f44fqIiqm4ckLFCL0a+9gZWN3zH6mO9uyAojq7WrdQdeSkjE32Ro2V uXJ8muL7zi8Gf/G9PdrmhE4MDVT+ZWkgM6gaPqYu+erEA3b0vUiNsFN3JpJtPAC33rce EmUrEFh43vvLLD4YEgVivSHO1RCSg2cFtrHfrc7Un7elcZZhRehMcP3OlcfMf+yrSJyY WJDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706007603; x=1706612403; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=/6cXgf+xnlP1IbyBgauH/S9YxW0lVZDsargGcVCvBQU=; b=om/W3gHNDUGWthkAcmQhIfaNwjyEgiD1+45a55H32jScBCY+kOmVGbQ6YpjFJHIOmX c1QyPXIs85/fLyOBYYay4GA4WZy2bO5R8GbWHLZEpxkcd7AFAvFTF9G09RwPwP/ndkfI n7J0wO4UVpcTb69gsusXHucf58S7xxQ87OGDBcNkpC06fQE+njxaaCJAIVy3Ir74mc/5 cHQd1fcDlfcDB9+LE/vdVDhWapg83Rq0bAjN3s+4r4igBulg0uS2wuQiGPGFh4R8UnEh ANDHgzKQgJOhHgk+uaEat99EXiCeTblUUSawnS0CUKz7Rwgi92e2gIjoaVTKBju5ckSH JHMw== X-Gm-Message-State: AOJu0Yz+/8w2rCY18QCB4RP6Jj0Uu9JKVRK1lKjgJW88jf+RRQQyxjZ8 0ZCzjSeGzKInWHW7KABuSMf+e01oW/8EPTuzXXuI7pJTZLuMCbyi X-Google-Smtp-Source: AGHT+IFMpkR8h2sQnHOztnXSkF9ch3FZee9mvG6Zx7TMYhrWIJnwT5N+mVPjKOMbKXC6y18bgTAM5Q== X-Received: by 2002:a2e:86c4:0:b0:2cf:1920:97 with SMTP id n4-20020a2e86c4000000b002cf19200097mr150638ljj.12.1706007602925; Tue, 23 Jan 2024 03:00:02 -0800 (PST) Received: from [1.0.0.7] ([91.185.77.50]) by smtp.gmail.com with ESMTPSA id e11-20020a05651c150b00b002cdfa840399sm1493877ljf.139.2024.01.23.03.00.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Jan 2024 03:00:02 -0800 (PST) Message-ID: <1eb70b1b-7575-9827-2534-439bdc1900d3@gmail.com> Date: Tue, 23 Jan 2024 14:00:01 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: BUG: Former primary node might stuck when started as a standby Content-Language: en-US To: Aleksander Alekseev , pgsql-hackers References: <74ea5e7e-9aa0-4d7a-85df-71a9d200a8d8@gmail.com> From: Alexander Lakhin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi Aleksander, [ I'm writing this off-list to minimize noise, but we can continue the discussion in -hackers, if you wish ] 22.01.2024 14:00, Aleksander Alekseev wrote: > Hi, > >> But node1 knows that it's a standby now and it's expected to get all the >> WAL records from the primary, doesn't it? > Yes, but node1 doesn't know if it always was a standby or not. What if > node1 was always a standby, node2 was a primary, then node2 died and > node3 is a new primary. Excuse me, but I still can't understand what could go wrong in this case. Let's suppose, node1 has WAL with the following contents before start: CPLOC | TL1R1 | TL1R2 | TL1R3 | while node2's WAL contains: TL1R1 | TL2R1 | TL2R2 | ... where CPLOC -- a checkpoint location, TLxRy -- a record y on a timeline x. I assume that requesting all WAL records from node2 without redoing local records should be the right thing. And even in the situation you propose: CPLOC | TL2R5 | TL2R6 | TL2R7 | while node3's WAL contains: TL2R5 | TL3R1 | TL3R2 | ... I see no issue with applying records from node3... > If node1 sees inconsistency in the WAL > records, it should report it and stop doing anything, since it doesn't > has all the information needed to resolve the inconsistencies in all > the possible cases. Only DBA has this information. I still wonder, what can be considered an inconsistency in this situation. Doesn't the exactly redo of all the local WAL records create the inconsistency here? For me, it's the question of an authoritative source, and if we had such a source, we should trust it's records only. Or in the other words, what if the record TL1R3, which node1 wrote to it's WAL, but didn't send to node2, happened to have an incorrect checksum (due to partial write, for example)? If I understand correctly, node1 will just stop redoing WAL at that position to receive all the following records from node2 and move forward without reporting the inconsistency (an extra WAL record). Best regards, Alexander