Re: Cleaning up PREPARE query strings?

From: Sami Imseih <samimseih(at)gmail(dot)com>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Cleaning up PREPARE query strings?
Date: 2026-01-18 16:16:16
Message-ID: CAA5RZ0sU-XUaGAATHhNZ-85u5h8SSbw0ykBPdBjOK-YXQkoy6g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>
> > ISTM that your proposal will actually use more memory because
> > pstate->p_sourcetext does not get free'd, but we must now allocate
> > space for a new "cleaned" query.
>
> I'm not sure that I understand. Sure we allocate a new temporary buffer
> for
> the cleaned up query string but this will be freed soon. The query string
> stored in the prepared statement will stay in memory as long as the prepare
> statement exist so this any cleanup can actually save a lot of memory.
>

My point is pstate->p_sourcetext doesn't get freed just because we're not
referencing it from CachedPlanSource in prepared_queries. Instead, with
multi-statement strings, prepared_queries now use a newly allocated string,
new_query, which will be around until DEALLOCATE.

```
+ tmp = palloc(rawstmt->stmt_len + 1);
+ strlcpy(tmp, cleaned, rawstmt->stmt_len + 1);
+
+ new_query = tmp;
```

So this patch always increases memory usage for multi-statement strings;
we have both the original multi-statement string and the cleaned up copy
around.

--
Sami Imseih
Amazon Web Services (AWS)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kirill Reshke 2026-01-18 18:56:24 Re: let ALTER TABLE DROP COLUMN drop whole-row referenced object
Previous Message Filip Janus 2026-01-18 15:50:24 Re: Proposal: Adding compression of temporary files