Re: Support prepared statement invalidation when result types change

2024-04-03 Thread Jelte Fennema-Nio
On Sun, 7 Jan 2024 at 07:55, vignesh C wrote: > One of the test has aborted in CFBot at [1] with: Rebased the patchset and removed patch 0003 since it was causing the CI issue reported by vignesh and it seems much less useful and more controversial to me anyway (due to the extra required

Re: Support prepared statement invalidation when result types change

2024-01-07 Thread Shay Rojansky
On Mon, Sep 18, 2023 at 1:31 PM Jelte Fennema-Nio wrote: > Furthermore caching RowDescription is also not super useful, most > clients request it every time because it does not require an extra > round trip, so there's almost no overhead in requesting it. Just to point out, FWIW, that the .NET

Re: Support prepared statement invalidation when result types change

2024-01-06 Thread vignesh C
On Mon, 18 Sept 2023 at 18:01, Jelte Fennema-Nio wrote: > > @Euler thanks for the review. I addressed the feedback. > > On Fri, 15 Sept 2023 at 01:41, Andy Fan wrote: > > What if a client has *cached* an old version of RowDescription > > and the server changed it to something new and sent

Re: Support prepared statement invalidation when result types change

2023-09-18 Thread Jelte Fennema-Nio
@Euler thanks for the review. I addressed the feedback. On Fri, 15 Sept 2023 at 01:41, Andy Fan wrote: > What if a client has *cached* an old version of RowDescription > and the server changed it to something new and sent resultdata > with the new RowDescription. Will the client still be able

Re: Support prepared statement invalidation when result types change

2023-09-14 Thread Andy Fan
Hi, > > This requirement was not documented anywhere and it > can thus be a surprising error to hit. But it's actually not needed for > this to be an error, as long as we send the correct RowDescription there > does not have to be a problem for clients when the result types or > column counts

Re: Support prepared statement invalidation when result types change

2023-09-13 Thread Euler Taveira
On Tue, Sep 12, 2023, at 10:17 AM, Jelte Fennema wrote: > When running the Postgres JDBC tests with this patchset I found dumb > mistake in my last patch where I didn't initialize the contents of > orig_params correctly. This new patchset fixes that. > 0001: Don't you want to execute this code

Re: Support prepared statement invalidation when result types change

2023-09-12 Thread Jelte Fennema
When running the Postgres JDBC tests with this patchset I found dumb mistake in my last patch where I didn't initialize the contents of orig_params correctly. This new patchset fixes that. v4-0001-Support-prepared-statement-invalidation-when-resu.patch Description: Binary data

Re: Support prepared statement invalidation when result types change

2023-09-08 Thread Jelte Fennema
: Fri, 25 Aug 2023 17:09:38 +0200 Subject: [PATCH v3 1/3] Support prepared statement invalidation when result types change The cached plan for a prepared statements can get invalidated when DDL changes the tables used in the query, or when search_path changes. When this happens the prepared statement

Re: Support prepared statement invalidation when result types change

2023-08-29 Thread Jelte Fennema
On Tue, 29 Aug 2023 at 11:29, jian he wrote: > regression=# CREATE TEMP TABLE pcachetest AS SELECT * FROM int8_tbl; > SELECT 5 > regression=# PREPARE prepstmt2(bigint) AS SELECT * FROM pcachetest > WHERE q1 = $1;' > PREPARE > regression=# alter table pcachetest rename q1 to x; > ALTER TABLE >

Re: Support prepared statement invalidation when result types change

2023-08-29 Thread jian he
On Tue, Aug 29, 2023 at 12:51 AM Jelte Fennema wrote: > > Could you share the full set of commands that cause the reporting > issue? I don't think my changes should impact this reporting, so I'm > curious if this is a new issue, or an already existing one. I didn't apply your v2 patch. full set

Re: Support prepared statement invalidation when result types change

2023-08-28 Thread Jelte Fennema
On Mon, 28 Aug 2023 at 11:27, jian he wrote: > With parameters, it also works, only a tiny issue with error reporting. > > prepstmt2 | PREPARE prepstmt2(bigint) AS SELECT * FROM pcachetest > WHERE q1 = $1; | {bigint}| {bigint,bigint,bigint} > ERROR: column "q1" does not exist at

Re: Support prepared statement invalidation when result types change

2023-08-28 Thread Jelte Fennema
On Mon, 28 Aug 2023 at 15:05, Konstantin Knizhnik wrote: > The following assignment of format is not corrects: > > It has to be copied as below: > > portal->formats = (int16 *) > MemoryContextAlloc(portal->portalContext, > natts * sizeof(int16)); >

Re: Support prepared statement invalidation when result types change

2023-08-28 Thread Konstantin Knizhnik
On 25.08.2023 8:57 PM, Jelte Fennema wrote: The cached plan for a prepared statements can get invalidated when DDL changes the tables used in the query, or when search_path changes. When this happens the prepared statement can still be executed, but it will be replanned in the new context.

Re: Support prepared statement invalidation when result types change

2023-08-28 Thread jian he
On Sat, Aug 26, 2023 at 1:58 AM Jelte Fennema wrote: > > The cached plan for a prepared statements can get invalidated when DDL > changes the tables used in the query, or when search_path changes. When > this happens the prepared statement can still be executed, but it will > be replanned in the

Support prepared statement invalidation when result types change

2023-08-25 Thread Jelte Fennema
prepared statement invalidation when result types change The cached plan for a prepared statements can get invalidated when DDL changes the tables used in the query, or when search_path changes. When this happens the prepared statement can still be executed, but it will be replanned in the new