From: Andy Fan <zhihuifan1213@163.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Etsuro Fujita <etsuro.fujita@gmail.com>,  Pg Hackers
 <pgsql-hackers@postgresql.org>
Subject: Re: postgres_fdw: Provide better emulation of READ COMMITTED behavior
In-Reply-To: <CA+TgmoaYs6DLXrZB8NWzUi3YPL9yvBhFOG4UMENMCJ+WY2pn5A@mail.gmail.com>
	(Robert Haas's message of "Thu, 5 Dec 2024 12:37:02 -0500")
References: <CAPmGK14Nj7vuJELKuhyiwMMhat8SsyUY+88yAyTZLdqXG0xYuw@mail.gmail.com>
	<CA+TgmoaYs6DLXrZB8NWzUi3YPL9yvBhFOG4UMENMCJ+WY2pn5A@mail.gmail.com>
Date: Fri, 06 Dec 2024 18:50:25 +0800
Message-ID: <875xnxqe4u.fsf@163.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/875xnxqe4u.fsf%40163.com>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> writes:

> On Thu, Dec 5, 2024 at 4:41=E2=80=AFAM Etsuro Fujita <etsuro.fujita@gmail=
.com> wrote:
>> Comments welcome!  Maybe I am missing something, though.
>
> I have a hard time seeing how this would work if cursors are in use on
> the main server. Say I do this:
>
> DECLARE foo CURSOR FOR SELECT * FROM ft1 UNION ALL SELECT * FROM ft2;
> ...fetch some rows from cursor foo but few enough that we only scan ft1...
> ...do something that causes a snapshot refresh like issue another query...
> ...fetch more rows from cursor foo until we start scanning ft2...

Apart from the above issue, what do you think about that we are using a
'SELECT pg_catalog.pg_refresh_snapshot()' to let the remote do the
refresh_snapshot VS 'a new message type for this'?  There are lots of
things happen in the 'SELECT' way like 'a extra network communication',
'a complete parser-planner-executor workflow.' With a new message type
for this, we can send the message character with the next query
together. if so, can the two overheads removed?=20


--=20
Best Regards
Andy Fan