On 20.08.2020 10:36, Kyotaro Horiguchi wrote:
> At Wed, 19 Aug 2020 23:25:36 -0500, Justin Pryzby <pryzby@telsasoft.com> wrote in
>> On Thu, Jul 02, 2020 at 11:14:48AM +0900, Kyotaro Horiguchi wrote:
>>> As the result of a discussion with Fujita-san off-list, I'm going to
>>> hold off development until he decides whether mine or Thomas' is
>>> better.
>> The latest patch doesn't apply so I set as WoA.
>> https://commitfest.postgresql.org/29/2491/
> Thanks. This is rebased version.
>
> At Fri, 14 Aug 2020 13:29:16 +1200, Thomas Munro <thomas.munro@gmail.com> wrote in
>> Either way, we definitely need patch 0001. One comment:
>>
>> -CreateWaitEventSet(MemoryContext context, int nevents)
>> +CreateWaitEventSet(MemoryContext context, ResourceOwner res, int nevents)
>>
>> I wonder if it's better to have it receive ResourceOwner like that, or
>> to have it capture CurrentResourceOwner. I think the latter is more
>> common in existing code.
> There's no existing WaitEventSets belonging to a resowner. So
> unconditionally capturing CurrentResourceOwner doesn't work well. I
> could pass a bool instead but that make things more complex.
>
> Come to think of "complex", ExecAsync stuff in this patch might be
> too-much for a short-term solution until executor overhaul, if it
> comes shortly. (the patch of mine here as a whole is like that,
> though..). The queueing stuff in postgres_fdw is, too.
>
> regards.
>
Hi,
Looks like current implementation of asynchronous append incorrectly
handle LIMIT clause:
psql:append.sql:10: ERROR: another command is already in progress
CONTEXT: remote SQL command: CLOSE c1
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
