Subject: A modest proposal: make parser/rewriter/planner inputs read-only

From: Tom Lane <[email-masked]>
Date: Sat, 05 Apr 2025 12:46:37 -0400

The parser, rewriter, and planner all have a bad habit of scribbling
on their input parsetrees.  At this point I've lost count of how many
bugs that's caused (but e33f2335a and 0f43083d1 are the two latest
examples), and of how many places there are that are brute-forcing a
solution to the problem by copying a whole parsetree before letting
one of these subsystems see it.

Years ago we fixed the executor to treat its input Plan trees as
read-only.  It seems like we really ought to do the same for these
upstream subsystems.  Surely, whatever benefit we get from changing
Node contents in-place is lost due to all these other hacks.

While I've had this thought in the back of my head for a long while,
I haven't pursued it because I couldn't think of a practical way
to find all the places that are violating such a policy, much less
prevent future violations.  However, today I thought of this sketch 
of a solution:

1. Invent a way to make a particular memory context read-only
after putting some data into it.

2. In debug builds, after we've built a tree that should be considered
read-only, copy it into such a context and make it read-only.  Or
perhaps build it there in the first place.

3. Fix the resulting crashes.

4. Profit!  (In particular, nuke a lot of no-longer-needed copyObject
calls.)

My first thought about implementing #1 was to seek Valgrind's help,
but so far as I can find out there's no VALGRIND_MAKE_MEM_READ_ONLY.
Step #3 would be pretty tedious anyway if it required running under
Valgrind.  However, all modern hardware has the ability to mark
memory read-only at the page level, and most platforms expose that
in some way or other.  So it doesn't seem unreasonable to invent
a memory context option (or whole new context type, if that seems
easier) that is careful to align its allocation blocks on page
boundaries and then can set or clear the hardware R/O flag on
demand.  It'd be enough if the R/O enforcement worked on popular
development platforms, we don't have to make it work absolutely
everywhere.

I'm not planning to pursue this idea Right Now, but it seems like
something that could happen for v19 or so.  In the meantime I wanted
to get the ideas down on electrons.

Thoughts?

			regards, tom lane

---

From: Andres Freund <[email-masked]>
Date: Sat, 5 Apr 2025 22:30:54 -0400

Hi,

> development platforms, we don't have to make it work absolutely

FWIW, while hacking on patch to making hint bit writes not happening while IO
is going on (so we don't need to copy the page anymore and don't cause
filesystem level issues with DIO), I hacked up protection for shared buffers
using mprotect() - it worked way better than I thought it would. The overhead
ended up surprisingly low:

base:
real    1m4.613s
user    4m31.409s
sys     3m20.445s

ENFORCE_BUFFER_PROT

real    1m11.912s
user    4m27.332s
sys     3m28.063s

See https://postgr.es/m/043c8b50-d183-46e5-b054-145cc0f6f908%40iki.fi

I'm mostly sharing that to say that
a) yes, mprotect() is viable and works surprisingly well
b) it might be worth inventing some common platform abstraction for mprotect

That prototype patch already worked on most platforms, windows should be
entirely doable.

Greetings,

Andres Freund

---

From: Richard Guo <[email-masked]>
Date: Tue, 15 Apr 2025 18:20:42 +0900

> Node contents in-place is lost due to all these other hacks.

While I'm in favor of this idea, it seems that it will require lots of
code changes.  In particular, within the planner, the parsetree goes
through considerable transformations during the preprocessing phase,
such as subquery pull-up, constant folding, and so on.  Would this
proposal mean we'd need to refactor all those places to treat the
input parsetrees as read-only?  Just trying to understand the scope of
what would be involved.

Thanks
Richard

---

From: Andrei Lepikhov <[email-masked]>
Date: Tue, 15 Apr 2025 12:00:53 +0200

> to get the ideas down on electrons.
I generally like the idea because, for now, I need to be sure that no 
one touched the parse tree before copying it to do additional 
transformations before the optimisation phase.
But what is the way you are proposing here? Do you mean that one more 
entity will be explicitly introduced: a transformed parse tree?
It would open an opportunity for extensions to build a set of 
alternative transformed trees, pass them through the optimisation phase 
and choose the best plan.

-- 
regards, Andrei Lepikhov

---

From: Ashwin Agrawal <[email-masked]>
Date: Tue, 15 Apr 2025 17:06:13 -0700

> That prototype patch already worked on most platforms, windows should be

Also, I would like to provide reference to this old thread [1] in favor of
mprotect().
In that thread, and in Greenplum using mprotect helps detect Shared buffer
access rule violations.

[1]
https://www.postgresql.org/message-id/CANXE4Tfxmjv8Z-kcwWUCYxx6zCFS%3DGeBPm-ZjjLucvrGewjUtg%40mail.gmail.com

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.