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 1u18uB-00EpWL-8E for pgsql-hackers@arkaria.postgresql.org; Sat, 05 Apr 2025 19:10: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 1u18u9-001tSU-Kt for pgsql-hackers@arkaria.postgresql.org; Sat, 05 Apr 2025 19:10:09 +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 1u18u9-001tSM-6P for pgsql-hackers@lists.postgresql.org; Sat, 05 Apr 2025 19:10:09 +0000 Received: from mail.postgrespro.ru ([93.174.132.70]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1u18u6-0039cU-2k for pgsql-hackers@postgresql.org; Sat, 05 Apr 2025 19:10:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mx2023; t=1743880203; bh=XqvhGntcZnJTGWoPPEKWncVIvXAhaIFoPJ7FnZ9CLkU=; h=Message-ID:Date:User-Agent:Subject:To:Cc:References:From: In-Reply-To:From; b=X9jZSGzE4TG2d+VGYAWmJjG4iHzfiEZ11e18cgaMQdrHGRiTL2lwObuBXa2IgrgDy JaYSJ+5vfGTQok7zi2z70lgcXrxux2YPVDaIZM3EsGX72oG/WPkv5Q8YC74V1I7Vty +tR2r1TfF+iePpziUVCZ2PzEZjdIp3GTpwJg+nvf4enNf9J3d7IQIX9tRatNtc8yUu 1sKvf2WGg6FKih0gyTGg2G3CLOAfO/lWis8PFQmDQNA98HCkMaAH430mrC6YjKuTbW UCem+5Ks7vYZNBqPn5sNOOc8G20yR/rFrcSXVWfTgjDw2sdb6ASatGsmCxFtgk+3FQ a2TY8jB4Rxgfw== Received: from [172.30.48.118] (unknown [93.174.131.138]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: a.melnikov@postgrespro.ru) by mail.postgrespro.ru (Postfix/587) with ESMTPSA id D73E6602AC; Sat, 5 Apr 2025 22:10:02 +0300 (MSK) Message-ID: <4419f57e-8af5-425a-aa98-a2f921162d37@postgrespro.ru> Date: Sat, 5 Apr 2025 22:10:02 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Use XLOG_CONTROL_FILE macro everywhere? To: Fujii Masao , Kyotaro Horiguchi Cc: daniel@yesql.se, peter@eisentraut.org, tgl@sss.pgh.pa.us, robertmhaas@gmail.com, michael@paquier.xyz, pgsql-hackers@postgresql.org References: <54B16BF2-6979-4BB0-BE39-118D32B1BC58@yesql.se> <20240903.143756.562059416508617821.horikyota.ntt@gmail.com> <20240904.170927.1051663922860738119.horikyota.ntt@gmail.com> <359568e0-cffc-4f64-b84c-eee76ba229b8@postgrespro.ru> <2883bd25-f362-41ed-8d41-b6e0aac8fa27@postgrespro.ru> <18d80eb9-1e7a-4ead-98fe-60efc988954b@oss.nttdata.com> Content-Language: en-US From: "Anton A. Melnikov" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-KSMG-AntiPhishing: NotDetected, bases: 2025/04/05 18:33:00 X-KSMG-AntiSpam-Interceptor-Info: not scanned X-KSMG-AntiSpam-Status: not scanned, disabled by settings X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 2.1.0.7854, bases: 2025/04/05 16:48:00 #27857642 X-KSMG-AntiVirus-Status: NotDetected, skipped X-KSMG-LinksScanning: not scanned, disabled by settings X-KSMG-Message-Action: skipped X-KSMG-Rule-ID: 1 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi! On 05.04.2025 06:11, Fujii Masao wrote: > > Thanks for checking! Barring any objections, I'll go ahead and commit the patch. > As for me all is ok. Thanks! >> Maybe extend this to perl tests since there are several hardcoded names too? >> The patch attached tries to do this. > > I had the same thought, i.e., we could use scan_server_header() to pull > XLOG_CONTROL_FILE from xlog_internal.h and replace the hardcoded "global/pg_control" > in the TAP tests. But for now, that feels like overkill, since the TAP tests already > have other hardcoded values like the WAL directory (pg_wal), and we haven't used > macros like XLOGDIR there either. Replacing just "global/pg_control" might feel > inconsistent, and handling the other cases properly would take more time beyond > feature freeze. So I'm thinking it's better to use XLOG_CONTROL_FILE only in > C code for now. Agreed. Also think that it is better to fix all such places at once and some later. Best wishes! -- Anton A. Melnikov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company