Re: [HACKERS] pg_background contrib module proposal
От | Andrew Borodin |
---|---|
Тема | Re: [HACKERS] pg_background contrib module proposal |
Дата | |
Msg-id | CAJEAwVF2MY+-HnFLD=1Ygtm5yfgEEkRTZy+Ob-HDG=Wcdf4d_w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_background contrib module proposal (Andrew Borodin <borodin@octonica.com>) |
Ответы |
Re: [HACKERS] pg_background contrib module proposal
|
Список | pgsql-hackers |
I've read the code and now I have more suggestions. 1. Easy one. The case of different natts of expected and acutal result throws same errmsg as the case of wrong types. I think we should assist the user more here if (natts != tupdesc->natts) ereport(ERROR, (errcode(ERRCODE_DATATYPE_MISMATCH), errmsg("remote query resultrowtype does not match the specified FROM clause rowtype"))); and here if (type_id != tupdesc->attrs[i]->atttypid) ereport(ERROR, (errcode(ERRCODE_DATATYPE_MISMATCH), errmsg("remote query result rowtype does not match the specified FROM clause rowtype"))); 2. This code errhint("You may need to increase max_worker_processes.") Is technically hinting absolutley right. But this extension requires something like pg_bouncer or what is called "thread pool". You just cannot safely fire a background task because you do not know how many workes can be spawned. Maybe it'd be better to create 'pool' of workers and form a queue of queries for them? This will make possible start a millions of subtasks. 3. About getting it to the core, not as an extension. IMO this is too sharp thing to place it into core, I think that it's best place is in contribs. Thanks for the work on such a cool and fun extension. Best regards, Andrey Borodin.
В списке pgsql-hackers по дате отправления: