On 2021-Jun-09, Tom Lane wrote:
> BTW, to be clear: I think Alvaro's change is also necessary.
> If libpq is going to silently do something different in pipeline
> mode than it does in normal mode, it should strive to minimize
> the semantic difference. exec_simple_query includes a PortalDrop,
>
Yura Sokolov writes:
> This makes me think, Close message were intended to be used
> but simply forgotten when libpq patch were made.
> Tom, could I be right?
You could argue all day about what the intentions were nearly twenty
years ago. But the facts on the ground are that we don't issue Close
Alvaro Herrera wrote 2021-06-08 00:07:
On 2021-May-27, Yura Sokolov wrote:
Alvaro Herrera писал 2021-05-26 23:59:
> I don't think they should do that. The portal remains open, and the
> libpq interface does that. The portal gets closed at end of transaction
> without the need for any clien
On 2021-Jun-09, Tom Lane wrote:
> I wrote:
> > It turns out that the problem is specific to SELECT FOR UPDATE, and
> > it happens because nodeLockRows is not careful to shut down the
> > EvalPlanQual mechanism it uses before returning NULL at the end of
> > a scan. If EPQ has been fired, it'll be
I wrote:
> It turns out that the problem is specific to SELECT FOR UPDATE, and
> it happens because nodeLockRows is not careful to shut down the
> EvalPlanQual mechanism it uses before returning NULL at the end of
> a scan. If EPQ has been fired, it'll be holding a tuple slot
> referencing whateve
I wrote:
> I'm still wondering though why Yura is observing resources remaining
> held by an executed-to-completion Portal. I think investigating that
> might be more useful than tinkering with pipeline mode.
I got a chance to look into this finally. The lens I've been looking
at this through is
Alvaro Herrera writes:
> On 2021-Jun-07, Alvaro Herrera wrote:
>> The attached patch does it. Any opinions?
> Eh, really attached.
No particular objection. I'm not sure this will behave quite the
same as simple-Query in error cases, but probably it's close enough.
I'm still wondering though w
On 2021-Jun-07, Alvaro Herrera wrote:
> The attached patch does it. Any opinions?
Eh, really attached.
--
Álvaro Herrera39°49'30"S 73°17'W
"No es bueno caminar con un hombre muerto"
>From c5c6e8860e9d425ddea82e32868fedc7562ec51c Mon Sep 17 00:00:00 2001
From: Alvaro
Alvaro Herrera writes:
> The attached patch does it. Any opinions?
My opinion is there's no patch here.
regards, tom lane
On 2021-May-27, Yura Sokolov wrote:
> Alvaro Herrera писал 2021-05-26 23:59:
> > I don't think they should do that. The portal remains open, and the
> > libpq interface does that. The portal gets closed at end of transaction
> > without the need for any client message. I think if the client wa
Tom Lane wrote 2021-05-27 00:19:
Alvaro Herrera writes:
(I didn't add a Close Portal message to PQsendQueryInternal in
pipeline
mode precisely because there is no such message in PQsendQueryGuts.
I think it would be wrong to unconditionally add a Close Portal
message
to any of those places.)
Alvaro Herrera писал 2021-05-26 23:59:
On 2021-May-25, Yura Sokolov wrote:
Tom Lane писал 2021-05-21 21:23:
> Yura Sokolov writes:
> > I propose to add PortalDrop at the 'if (completed)' branch of
> > exec_execute_message.
>
> This violates our wire protocol specification, which
> specifically
Alvaro Herrera writes:
> (I didn't add a Close Portal message to PQsendQueryInternal in pipeline
> mode precisely because there is no such message in PQsendQueryGuts.
> I think it would be wrong to unconditionally add a Close Portal message
> to any of those places.)
Yeah, I'm not very comfortabl
On 2021-May-25, Yura Sokolov wrote:
> Tom Lane писал 2021-05-21 21:23:
> > Yura Sokolov writes:
> > > I propose to add PortalDrop at the 'if (completed)' branch of
> > > exec_execute_message.
> >
> > This violates our wire protocol specification, which
> > specifically says
> >
> > If succe
Tom Lane писал 2021-05-21 21:23:
Yura Sokolov writes:
I propose to add PortalDrop at the 'if (completed)' branch of
exec_execute_message.
This violates our wire protocol specification, which
specifically says
If successfully created, a named portal object lasts till the end
of
the
Yura Sokolov writes:
> I propose to add PortalDrop at the 'if (completed)' branch of
> exec_execute_message.
This violates our wire protocol specification, which
specifically says
If successfully created, a named portal object lasts till the end of
the current transaction, unless explici
Hi, hackers.
I've been playing with "autoprepared" patch, and have got isolation
"freeze-the-dead" test stuck on first VACUUM FREEZE statement.
After some research I found issue is reproduced with unmodified master
branch if extended protocol used. I've prepared ruby script for
demonstration (cau
17 matches
Mail list logo
