Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iFeN6-0002ez-PK for pgsql-committers@arkaria.postgresql.org; Wed, 02 Oct 2019 13:08:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iFeN4-0007Ki-Jr for pgsql-committers@arkaria.postgresql.org; Wed, 02 Oct 2019 13:08:46 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iFeN4-0007KP-96 for pgsql-committers@lists.postgresql.org; Wed, 02 Oct 2019 13:08:46 +0000 Received: from mail-qt1-x844.google.com ([2607:f8b0:4864:20::844]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1iFeN1-0002Ge-Ga for pgsql-committers@lists.postgresql.org; Wed, 02 Oct 2019 13:08:44 +0000 Received: by mail-qt1-x844.google.com with SMTP id d16so5612054qtq.8 for ; Wed, 02 Oct 2019 06:08:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=TSTdyeD1EXMVKCzuhw0sN08xpMectAkI85/rSrKSINA=; b=bJWzDvC/RP83MBOsf4YGSG6hSOlbgXasOhN4OQPLKNlKOBa7xSMXvScpys+MakPzzt 5VBaw1rJEJBq+qkU3Bgwc3jiTNr8eDFupVlNfkd5aemQhje2ljxGUoDTyUbcQ17IMUy6 QFQSuz5W81mKrx4oDDozjuUSGUwP6knVAUR5TpPe4/L4BWdRnWfvw7WVsvK8Tta0y5bF s3B0b7vXUo2gImSCywdIpz3JGdfml889o89ZjYSgXXDIueZ/ugdXueSpiVtTGTwnzW9n eGWtDWDvtSC+Bgb6UmaWRIwPh1yzqvuDeBJlM6FAkLr+wHYGv1XArU27VDNqICzV111y xRjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=TSTdyeD1EXMVKCzuhw0sN08xpMectAkI85/rSrKSINA=; b=mkPyn9FM7cFUJDr6DjqpNvv++EGHPeER3wUCK3rAwjqBr4S1p7MIWDujeo866kB5mj nF6c6b01nHE00w2+CRF9/mmanyl/JAv8WR0Qn3JERiZiZGaHJ4e7Zmv6bv8I4/+oVB+j oJmt0MTsDRNHS5LXK/qULj1Ei6ed5hjhAbiVjop8hDmYVC6LUzsiexBg7fIEdAMjQSrG z9tiXDMJECLdBdMayXXLVCth9F7qyLmHKOcpJG7TGaWlLPqh5SKkYFaWHBjshUbfRIR/ CeWqYmZxnoasMYAzsjf7/M+ulVo2W8plZLtwCH8XmB00CPDiK8kNU7Z8Im3enF+QG3UK SwIQ== X-Gm-Message-State: APjAAAWdhJjjaHhdqOSxLcUD0iujWPCpfoLXJt/ct5OlsBu1eXq3Hllh mVH+mmc1zhbcsW1EMNZaEAp3uA== X-Google-Smtp-Source: APXvYqw+OMFFVUaD+KiGZtGorUCdTlCo56QTou4MpDvcRGnX1tAbUpaNdhnmkAu4b9jdz3nmYxlmQQ== X-Received: by 2002:a0c:ec46:: with SMTP id n6mr2909787qvq.23.1570021721982; Wed, 02 Oct 2019 06:08:41 -0700 (PDT) Received: from nimloth.alvh.no-ip.org ([190.217.183.202]) by smtp.gmail.com with ESMTPSA id m186sm9440305qkd.119.2019.10.02.06.08.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Oct 2019 06:08:41 -0700 (PDT) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 263CF300832; Wed, 2 Oct 2019 10:08:39 -0300 (-03) Date: Wed, 2 Oct 2019 10:08:39 -0300 From: Alvaro Herrera To: Michael Paquier Cc: Fujii Masao , Andres Freund , Tom Lane , pgsql-committers@lists.postgresql.org Subject: Re: pgsql: Add hooks for session start and session end, take two Message-ID: <20191002130839.GA7050@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20191002051424.GC3130@paquier.xyz> User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2019-Oct-02, Michael Paquier wrote: > On Wed, Oct 02, 2019 at 01:27:50PM +0900, Fujii Masao wrote: > > If only session end hook is problematic, you will commit session start > > hook again? > > Sure, it would be possible to cut the apple in half here. Now my > understanding was that both hooks were a set. What do people think? I think that having just session start is still useful, even if I encourage you to get session end covered, because yes they do form a set :-) I don't think it's completely *impossible* to get session end to work, only it needs to be run prior to any subsystem shutdown (I haven't actually looked at the code, mind). Of course, it'll need to be clear that it might not run in certain cases. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services