Subject: Re: Why does exec_simple_query requires 2 snapshots

From: Andy Fan <[email-masked]>
Date: Wed, 19 Feb 2025 01:10:21 +0000

Tom Lane <[email-masked]> writes:

> Andy Fan <[email-masked]> writes:
>> My question is why can't we share the same snapshot for the 2 cases?
>> parser & planner requires Catalog Snapshot which should be the 
>> latest one, but in the above case, looks the executor can reuse it as
>> well. Is there anything I missed?
>
> Many years ago, we committed a patch to do exactly that.  We had
> to back it out again because it broke too many real-world scenarios.
> I'm too lazy to search the archives for you, but you might be able
> to find the commit and revert by searching the git history.
>
> 			regards, tom lane

Commit id is 532994299e2, thank you Tom!

-- 
Best Regards
Andy Fan

---

From: Tom Lane <[email-masked]>
Date: Tue, 18 Feb 2025 21:30:45 -0500

> Commit id is 532994299e2, thank you Tom!

Ah, cool.  If you didn't find it already, there should be a
pgsql-hackers or pgsql-bugs thread of approximately that date
with more detail.  Sadly, we didn't adopt the convention of
including Discussion: links in commit messages till some
years after that.

			regards, tom lane

---

From: Andy Fan <[email-masked]>
Date: Wed, 19 Feb 2025 08:50:05 +0000

Tom Lane <[email-masked]> writes:

> links in commit messages till some years after that.

Links in commit messages is a really great change.

I have found more details at [1], the issue can be summaried as IIUC:

The current strategy is below:
t1: snapshot1
parser&planner
t2: snapshot2
executor.

which makes the committed tuple between (t1, t2] are visible to user, but if
we share the same snapshot, the committed tuple would not be visible to
user, Chaning it would be a behavior change. 

[1] https://www.postgresql.org/message-id/5075D8DF.6050500%40fuzzy.cz

-- 
Best Regards
Andy Fan

---

From: Michail Nikolaev <[email-masked]>
Date: Sat, 8 Mar 2025 10:51:45 +0100

Hello!

I was thinking the same thing once - and you may
see db989184cda7f4aa1ff764cca96142029e7e093b for the special comment about
that :)

https://github.com/postgres/postgres/commit/db989184cda7f4aa1ff764cca96142029e7e093b