Re: [HACKERS] pg_background contrib module proposal - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [HACKERS] pg_background contrib module proposal
Date
Msg-id CAFj8pRCJ4HhPG5U65rJNtmEqpExChkFb8jZ4a_AuNbzpUKYj+g@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] pg_background contrib module proposal  (Andrew Borodin <borodin@octonica.com>)
List pgsql-hackers


2016-12-09 13:48 GMT+01:00 Andrew Borodin <borodin@octonica.com>:
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 result rowtype 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.

This is not easy, because pgworker is related to database, not to server. There are servers where you can have thousands databases.

Regards

Pavel
 

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.


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Time to drop old-style (V0) functions?
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] pg_background contrib module proposal