Re: Add PortalDrop in exec_execute_message

Поиск
Список
Период
Сортировка
От Yura Sokolov
Тема Re: Add PortalDrop in exec_execute_message
Дата
Msg-id fb7b58d91dcc23b592ace457dc0f8c3a@postgrespro.ru
обсуждение исходный текст
Ответ на Re: Add PortalDrop in exec_execute_message  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: Add PortalDrop in exec_execute_message  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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 client message.  I think if the client wanted
>> > to close the portal ahead of time, it would need a new libpq entry point
>> > to send the message to do that.
>> 
>> - PQsendQuery issues Query message, and exec_simple_query closes its
>>   portal.
>> - people doesn't expect PQsendQueryParams to be different from
>>   PQsendQuery aside of parameter sending. The fact that the portal
>>   remains open is a significant, unexpected and undesired difference.
>> - PQsendQueryGuts is used in PQsendQueryParams and 
>> PQsendQueryPrepared.
>>   It is always sends empty portal name and always "send me all rows"
>>   limit (zero). Both usages are certainly to just perform query and
>>   certainly no one expects portal remains open.
> 
> Thinking about it some more, Yura's argument about PQsendQuery does 
> make
> sense -- since what we're doing is replacing the use of a 'Q' message
> just because we can't use it when in pipeline mode, then it is
> reasonable to think that the replacement ought to have the same
> behavior.  Upon receipt of a 'Q' message, the portal is closed
> automatically, and ISTM that that behavior should be preserved.
> 
> That change would not solve the problem he complains about, because 
> IIUC
> his framework is using PQsendQueryPrepared, which I'm not proposing to
> change.  It just removes the other discrepancy that was discussed in 
> the
> thread.
> 
> The attached patch does it.  Any opinions?

I'm propose to change PQsendQueryParams and PQsendQueryPrepared
(through change of PQsendQueryGuts) since they both has semantic
"execute unnamed portal till the end and send me all rows".

Extended protocol were introduced by Tom Lane on 2003-05-05
in 16503e6fa4a13051debe09698b6db9ce0d509af8
This commit already has Close ('C') message.
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=16503e6fa4a13051debe09698b6db9ce0d509af8

libpq adoption of extended protocol were made by Tom month later
on 2003-06-23 in efc3a25bb02ada63158fe7006673518b005261ba
and there is already no Close message in PQsendQueryParams.
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=efc3a25bb02ada63158fe7006673518b005261ba

I didn't found any relevant discussion in pgsql-hackers on May
and June 2003.

This makes me think, Close message were intended to be used
but simply forgotten when libpq patch were made.

Tom, could I be right?

regards,
Yura.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: vignesh C
Дата:
Сообщение: Re: locking [user] catalog tables vs 2pc vs logical rep
Следующее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: Race condition in recovery?