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 1rkkhd-00F3y5-Se for pgsql-hackers@arkaria.postgresql.org; Thu, 14 Mar 2024 13:00:58 +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 1rkkhb-00HShR-Uz for pgsql-hackers@arkaria.postgresql.org; Thu, 14 Mar 2024 13:00:56 +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 1rkkhb-00HShI-LV for pgsql-hackers@lists.postgresql.org; Thu, 14 Mar 2024 13:00:56 +0000 Received: from meesny.iki.fi ([2001:67c:2b0:1c1::201]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rkkhY-004SkR-1U for pgsql-hackers@postgresql.org; Thu, 14 Mar 2024 13:00:54 +0000 Received: from [192.168.1.115] (dsl-hkibng22-54f8db-125.dhcp.inet.fi [84.248.219.125]) (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) (No client certificate requested) (Authenticated sender: hlinnaka) by meesny.iki.fi (Postfix) with ESMTPSA id 4TwSDK5T0TzyS4; Thu, 14 Mar 2024 15:00:49 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1710421250; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pKnjP5PcBVFl4Cewp8evp2NxCgvds3MZhCMeDHoDtwQ=; b=MdSY7Gfb5hQPuzd5t2TOr+qxlzw83R4kyw7u0hdt/WnQV+dJNoI8H58F6SYy6wx637RbQj WESPCbzqJQif00EX/U15eqCAy0nNo1+ynbvICJWEYsO1S21Rg1hjUboesHVHD9nFcIKARz FWcXR8YFVbXz+Utk1h/+E7d9lHNLFiI= ARC-Seal: i=1; s=meesny; d=iki.fi; t=1710421250; a=rsa-sha256; cv=none; b=iQ5CYvkyU+H4duZzse+oXZLslB4MMqudP6mOdCA217TjOTee5zR9KqteM8SJ7A+HlK9a71 Sa1sLmTn/7K0YGQ0pNBNyRSX64bzIrLcTDg6VPaVlnUDESuq0W6oVQL4/VUVTrMoC2okUC 0DKO9xJQIQr0EdW6t0iDwgwEYPkFaBM= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=hlinnaka smtp.mailfrom=hlinnaka@iki.fi ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1710421250; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pKnjP5PcBVFl4Cewp8evp2NxCgvds3MZhCMeDHoDtwQ=; b=Ocmi5H45BIjCXEJEOy8pS230kJL1MFJt5zYOnp22cXm9qaTvb0r9FS6WvyfsXj45v5IOoM d+OM3zAc4AMzPGSua2hhyzpOO7WQZCAlJaYVFC7lOeDD+yichc0fcTOE6VtSMxLTu0/fnD T6CQ52VHj1TYq8noXu3G/dCu7bh0mxE= Message-ID: <7ffe3d58-ec85-41f0-93af-37cfb60331c2@iki.fi> Date: Thu, 14 Mar 2024 15:00:49 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: BitmapHeapScan streaming read user and prelim refactoring Content-Language: en-US To: Robert Haas Cc: Dilip Kumar , Melanie Plageman , Nazir Bilal Yavuz , Andres Freund , Pg Hackers , Thomas Munro , Tomas Vondra References: <20240214194228.jf4o7luxtyra5ggv@awork3.anarazel.de> <20240216173559.xiy5xcl5dqmsprns@liskov> <20240227015028.knohvy3spaqwk7lf@liskov> <20240227142230.nu3ytvcjwouvczlt@liskov> <5f3b9d59-0f43-419d-80ca-6d04c07cf61a@iki.fi> From: Heikki Linnakangas In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 14/03/2024 14:34, Robert Haas wrote: > On Thu, Mar 14, 2024 at 6:37 AM Heikki Linnakangas wrote: >> If es_snapshot was different from the active snapshot, things would get >> weird, even without parallel query. The scans would use es_snapshot for >> the visibility checks, but any functions you execute in quals would use >> the active snapshot. > > Hmm, that's an interesting point. > > The case where the query is suspended and resumed - i.e. cursors are > used - probably needs more analysis. In that case, perhaps there's > more room for the snapshots to diverge. The portal code is pretty explicit about it, the ExecutorRun() call in PortalRunSelect() looks like this: PushActiveSnapshot(queryDesc->snapshot); ExecutorRun(queryDesc, direction, (uint64) count, portal->run_once); nprocessed = queryDesc->estate->es_processed; PopActiveSnapshot(); I looked at all the callers of ExecutorRun(), and they all have the active snapshot equal to queryDesc->snapshot, either because they called CreateQueryDesc() with the active snapshot before ExecutorRun(), or they set the active snapshot like above. -- Heikki Linnakangas Neon (https://neon.tech)