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 1t8lbl-005rPL-KV for pgsql-hackers@arkaria.postgresql.org; Wed, 06 Nov 2024 19:22:25 +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 1t8lbh-008ewO-Aq for pgsql-hackers@arkaria.postgresql.org; Wed, 06 Nov 2024 19:22:21 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t8lbg-008ewG-Sh for pgsql-hackers@lists.postgresql.org; Wed, 06 Nov 2024 19:22:21 +0000 Received: from mail-qk1-x72b.google.com ([2607:f8b0:4864:20::72b]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1t8lbZ-000YZF-91 for pgsql-hackers@postgresql.org; Wed, 06 Nov 2024 19:22:20 +0000 Received: by mail-qk1-x72b.google.com with SMTP id af79cd13be357-7b158542592so8063685a.2 for ; Wed, 06 Nov 2024 11:22:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wi3ck-info.20230601.gappssmtp.com; s=20230601; t=1730920932; x=1731525732; darn=postgresql.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=fEZrtj3uxai46hS7LeQczScs5irXGzZer+xLz15bYeA=; b=tIqttpKlMMgHw518PI6mJVYoazWBbImkRg/4HI2tdcVsH30FS+WlqAX158y4bXunlS lLdGJajBJ4kNGgqz+IT/GCR2DBA0Aajztdl4SugxtR52TqDR4kkUJfWT4CJzjHzxDweF MoScrMQF2xxgDH5Ux10uOS9ULengJ1JRt6test1gSJxhLNVa6CVKhPdXxPDPh5blfuTa JCXKRVL75Q9myGrjbkityM98UXSgGJfpOMgA6KTIeTvCRUdE+UIa97Euqtjnb6HKap+Q Fd2kykAMYsYwJHZ7jbFUJAfOUiQUri0NDnl7eeT4GpqBbeCWNiWamdexNiytDfEwZt5f 6rQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730920932; x=1731525732; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=fEZrtj3uxai46hS7LeQczScs5irXGzZer+xLz15bYeA=; b=cvd9ew+FdKWzjqm2NLDcPTuhN9du/GuU6WxmiuFv2pXdOXIou+SKtj8BFOy1jKZ0vg 3mAqhzf7ncY+0jG6u5ZjcX3bcVIbVB2eaH2O8RuLmfUTGsKsUIANVoIchBPeGV8EhINm /91lzuwqcmxuQh27ZJSX0qa/uQ53Y3+l3oXz7nM4Ozk1HzXDVeSAqm54W74tgojuBNUv RATeAh8lNhUFtVL6lNtrvbbvg5BwwbJtEUNm/Z9CSMMQnR2BlyBnDOtHwFzROWs+kBIX 42DFOiftu1QgrBc1M0m3d8RZmpql3vcAXnJQji+WVQG2rt4Y+P3SFD3KoXhy9bfAD3Lb PHzA== X-Forwarded-Encrypted: i=1; AJvYcCUZzCRx0PUUkDlMbEL1EuVURizP2DsEWi5o2vMV3tAIXb2+geEI5UOtnNisGlllNnIZX0EpS+rVuZH5m8rA@postgresql.org X-Gm-Message-State: AOJu0YyyU/I2dOO7eeucIz3JR9f8Y2yFtuvsBGy3/5UES9R4VNQd3odD dosO3ctj97uVQPpsWnbh3uU8j6aJGmzRx7+ptElhEhLPXG3F8EiT6ni/83otfNk= X-Google-Smtp-Source: AGHT+IHooVKrY19WibCbvLMmpAzViwWh9KeJt1Ah+t17pCOZEWWBhXl2732D/NLyH7dB+60O76j2Hw== X-Received: by 2002:a05:620a:1a93:b0:7b1:4665:986a with SMTP id af79cd13be357-7b2fb9817c5mr2338594085a.31.1730920932034; Wed, 06 Nov 2024 11:22:12 -0800 (PST) Received: from [172.21.0.10] (pool-108-16-53-81.phlapa.fios.verizon.net. [108.16.53.81]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7b2f3a10bd0sm661710385a.56.2024.11.06.11.22.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Nov 2024 11:22:11 -0800 (PST) Message-ID: <4410956c-dcb9-4bbc-a47b-8abb2fddd6d8@wi3ck.info> Date: Wed, 6 Nov 2024 14:22:10 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Commit Timestamp and LSN Inversion issue To: Amit Kapila Cc: Aleksander Alekseev , pgsql-hackers , shveta malik , "Zhijie Hou (Fujitsu)" , tomas@vondra.me References: <9f7f4def-7ea8-4ad3-83e7-a8cc9d18c58a@wi3ck.info> Content-Language: en-US From: Jan Wieck 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 On 11/6/24 06:23, Amit Kapila wrote: > I think we avoid calling hook/callback functions after holding a lock > (spinlock or LWLock) as the user may do an expensive operation or > acquire some other locks in those functions which could lead to > deadlocks or impact the concurrency. So, it would be better to > directly call an inline function to perform the required operation. This is a valid concern. The reason why I kept it as a hook is because ReserveXLogInsertLocation() has no knowledge that this is allocating WAL space for a commit record. Only the caller does. We certainly need to be extremely careful what any such hook function is doing. Acquiring additional locks is definitely not acceptable. But I am not sure we should burden this function with specialized knowledge about what it is reserving WAL space for. Regards, Jan