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  (Pavel Stehule <pavel.stehule@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: [HACKERS] Declarative partitioning - another take
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Time to drop old-style (V0) functions?