public inbox for [email protected]  
help / color / mirror / Atom feed
From: Tom Lane <[email protected]>
To: Dave Cramer <[email protected]>
Cc: James Pang <[email protected]>
Cc: [email protected]
Cc: Laurenz Albe <[email protected]>
Subject: Re: cached plan must not change result type
Date: Fri, 29 Mar 2024 12:21:06 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CADK3HHLkuDpfVKfzckH5z-e1_Z8DH-9WdOWaafbJ4HRuRqnsdg@mail.gmail.com>
References: <CAHgTRfcg2jGnjSqq1NVuMDtCjRU3aOXWrhXn1L=92Ka_Ug6euw@mail.gmail.com>
	<[email protected]>
	<CAHgTRfe+REHqYoQJ_ykj_p416PbdHz+UN06-R3PVr6auMx4w2g@mail.gmail.com>
	<CAHgTRfeXGN9d7vgg8LtwpNYw_+f-zmMYsOc1U9rhXkGcwWtNng@mail.gmail.com>
	<CADK3HHLkuDpfVKfzckH5z-e1_Z8DH-9WdOWaafbJ4HRuRqnsdg@mail.gmail.com>

Dave Cramer <[email protected]> writes:
> This is really an issue that needs to be solved in the backend. The error
> is coming from PostgreSQL and what should happen is that when you alter a
> table that a server prepared statement relies on the backend should send a
> message to tell us that all of the prepared statements that rely on are now
> invalid and we can reprepare them.

This is something that can't change without a wire protocol change.
There is nothing in the protocol that allows the backend to send out
a message like "oh, that Describe I sent you awhile back?  It might
be a lie now" at random times.  Also, what do you want to do about
race conditions --- that is, what if you fire off an Execute only
to find that one of those messages was already in flight to you?

A non-racy way to handle it might be for Bind/Execute to refuse to
run the query if its output has changed since the last Describe,
which we could check after acquiring table locks during Bind.
But we'd want to define "refuse" in a way that doesn't abort the
transaction, and that's a concept that doesn't exist in the
protocol at all.

			regards, tom lane





view thread (13+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: cached plan must not change result type
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox