From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Shay Rojansky <roji(at)roji(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Odd query execution behavior with extended protocol |
Date: | 2015-10-06 22:10:03 |
Message-ID: | 8155.1444169403@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Oct 6, 2015 at 5:53 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I dunno, if you close a portal before you've gotten CommandComplete,
>> should you expect that all its actions were taken? Arguably, that
>> should be more like a ROLLBACK.
> I dunno either, but a rollback would undo everything, and a commit
> would do everything. Ending up in a state where we've done some of it
> but not all of it is strange. Being able to run an unbounded number
> of commands without a CommandCounterIncrement is *really* strange.
I'm fairly sure that we *have* done all of it; the Portal code is careful
to execute DML commands to completion whether or not the client accepts
all the RETURNING rows. It will become visible after you commit. The
issue here is just whether it's visible to a subsequent Bind within the
same transaction.
> I'm not very sure what to do about it, though.
Possibly we need the close-portal message processing code to do the CCI
stuff if it observes that the Portal hasn't been run to completion.
(I think there is already enough state in the Portal struct to tell that,
though I'm too lazy to look right now.)
I'm concerned though whether this would amount to a protocol break.
It's certainly a behavioral change that we'd have to document.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-10-06 22:13:05 | Re: Odd query execution behavior with extended protocol |
Previous Message | Michael Paquier | 2015-10-06 22:06:07 | Re: pg_ctl/pg_rewind tests vs. slow AIX buildfarm members |