[v9.3] Extra Daemons (Re: elegant and effective way for running jobs inside a database)

On Wed, Apr 25, 2012 at 10:40 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:

I tried to implement a patch according to the idea. It allows extensions
to register an entry point of the self-managed daemon processes,
then postmaster start and stop them according to the normal manner.

I've got a provisional version of this as well, that I was expecting
to submit for 9.3CF1

Best thing is probably to catch up at PGCon on this, so we can merge
the proposals and code.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

On 25 April 2012 10:40, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:

I tried to implement a patch according to the idea. It allows extensions
to register an entry point of the self-managed daemon processes,
then postmaster start and stop them according to the normal manner.

The patch needs much work yet, but has many good ideas.

There doesn't seem to be a place where we pass the parameter to say
which one of the multiple daemons a particular process should become.
It would be helpful for testing to make the example module call 2
daemons each with slightly different characteristics or parameters, so
we can test the full function of the patch.

I think its essential that we allow these processes to execute SQL, so
we must correctly initialise them as backends and set up signalling.
Which also means we need a parameter to limit the number of such
processes.

Also, I prefer to call these bgworker processes, which is more similar
to auto vacuum worker and bgwriter naming. That also gives a clue as
to how to set up signalling etc..

I don't think we should allow these processes to override sighup and
sigterm. Signal handling should be pretty standard, just as it is with
normal backends.

I have a prototype that has some of these characteristics, so I see
our work as complementary.

At present, I don't think this patch would be committable in CF1, but
I'd like to make faster progress with it than that. Do you want to
work on this more, or would you like me to merge our prototypes into a
more likely candidate?

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

2012/6/8 Simon Riggs <simon@2ndquadrant.com>:

On 25 April 2012 10:40, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:

I tried to implement a patch according to the idea. It allows extensions
to register an entry point of the self-managed daemon processes,
then postmaster start and stop them according to the normal manner.

The patch needs much work yet, but has many good ideas.

There doesn't seem to be a place where we pass the parameter to say
which one of the multiple daemons a particular process should become.
It would be helpful for testing to make the example module call 2
daemons each with slightly different characteristics or parameters, so
we can test the full function of the patch.

This patch intended to register a daemon multiple times with different
name such as "auth-counter-1" or "auth-counter-2".
But, I agree with the suggestion to take a parameter to identify each
daemon makes interface better than the original one.

I think its essential that we allow these processes to execute SQL, so
we must correctly initialise them as backends and set up signalling.
Which also means we need a parameter to limit the number of such
processes.

It should be controllable with a flag of RegisterExtraDaemon().
Although it helps to reduce code duplication in case when extra daemons
execute SQL, but some other use-cases may not need SQL execution.

Also, I prefer to call these bgworker processes, which is more similar
to auto vacuum worker and bgwriter naming. That also gives a clue as
to how to set up signalling etc..

I don't think we should allow these processes to override sighup and
sigterm. Signal handling should be pretty standard, just as it is with
normal backends.

Hmm. CHECK_FOR_INTERRUPTS() might be sufficient to handle
signaling behavior according to the standard.

I have a prototype that has some of these characteristics, so I see
our work as complementary.

At present, I don't think this patch would be committable in CF1, but
I'd like to make faster progress with it than that. Do you want to
work on this more, or would you like me to merge our prototypes into a
more likely candidate?

I'm not favor in duplicate similar efforts. If available, could you merge
some ideas in my patch into your prototypes?

Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>

On Sun, Jun 10, 2012 at 4:15 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:

2012/6/8 Simon Riggs <simon@2ndquadrant.com>:

I have a prototype that has some of these characteristics, so I see
our work as complementary.

At present, I don't think this patch would be committable in CF1, but
I'd like to make faster progress with it than that. Do you want to
work on this more, or would you like me to merge our prototypes into a
more likely candidate?

I'm not favor in duplicate similar efforts. If available, could you merge
some ideas in my patch into your prototypes?

so, we are waiting for a new patch? is it coming from Simon or Kohei?

--
Jaime Casanova         www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación

On 21 June 2012 19:13, Jaime Casanova <jaime@2ndquadrant.com> wrote:

On Sun, Jun 10, 2012 at 4:15 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:

2012/6/8 Simon Riggs <simon@2ndquadrant.com>:

I have a prototype that has some of these characteristics, so I see
our work as complementary.

At present, I don't think this patch would be committable in CF1, but
I'd like to make faster progress with it than that. Do you want to
work on this more, or would you like me to merge our prototypes into a
more likely candidate?

I'm not favor in duplicate similar efforts. If available, could you merge
some ideas in my patch into your prototypes?

so, we are waiting for a new patch? is it coming from Simon or Kohei?

There is an updated patch coming from me. I thought I would focus on
review of other work first.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

2012-06-21 23:53 keltezéssel, Simon Riggs írta:

On 21 June 2012 19:13, Jaime Casanova <jaime@2ndquadrant.com> wrote:

On Sun, Jun 10, 2012 at 4:15 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:

2012/6/8 Simon Riggs <simon@2ndquadrant.com>:

I have a prototype that has some of these characteristics, so I see
our work as complementary.

At present, I don't think this patch would be committable in CF1, but
I'd like to make faster progress with it than that. Do you want to
work on this more, or would you like me to merge our prototypes into a
more likely candidate?

I'm not favor in duplicate similar efforts. If available, could you merge
some ideas in my patch into your prototypes?

so, we are waiting for a new patch? is it coming from Simon or Kohei?

There is an updated patch coming from me. I thought I would focus on
review of other work first.

We have some use cases for this patch, when can you post
a new version? I would test and review it.

Thanks in advance,
Zoltán Böszörményi

--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
http://www.postgresql.at/

2012-04-25 11:40 keltezéssel, Kohei KaiGai írta:

2012/3/10 Simon Riggs <simon@2ndquadrant.com>:

On Fri, Mar 9, 2012 at 6:51 PM, Andrew Dunstan <andrew@dunslane.net> wrote:

On 03/09/2012 01:40 PM, Robert Haas wrote:

On Fri, Mar 9, 2012 at 12:02 PM, David E. Wheeler<david@justatheory.com>
wrote:

On Mar 9, 2012, at 7:55 AM, Merlin Moncure wrote:

100% agree (having re-read the thread and Alvaro's idea having sunk
in). Being able to set up daemon processes side by side with the
postmaster would fit the bill nicely. It's pretty interesting to
think of all the places you could go with it.

pgAgent could use it *right now*. I keep forgetting to restart it after
restarting PostgreSQL and finding after a day or so that no jobs have run.

That can and should be fixed by teaching pgAgent that failing to
connect to the server, or getting disconnected, is not a fatal error,
but a reason to sleep and retry.

Yeah. It's still not entirely clear to me what a postmaster-controlled
daemon is going to be able to do that an external daemon can't.

Start and stop at the same time as postmaster, without any pain.

It's a considerable convenience to be able to design this aspect once
and then have all things linked to the postmaster follow that. It
means people will be able to write code that runs on all OS easily,
without everybody having similar but slightly different code about
starting up, reading parameters, following security rules etc.. Tight
integration, with good usability.

I tried to implement a patch according to the idea. It allows extensions
to register an entry point of the self-managed daemon processes,
then postmaster start and stop them according to the normal manner.

[kaigai@iwashi patch]$ ps ax | grep postgres
27784 pts/0 S 0:00 /usr/local/pgsql/bin/postgres
27786 ? Ss 0:00 postgres: writer process
27787 ? Ss 0:00 postgres: checkpointer process
27788 ? Ss 0:00 postgres: wal writer process
27789 ? Ss 0:00 postgres: autovacuum launcher process
27790 ? Ss 0:00 postgres: stats collector process
27791 ? Ss 0:00 postgres: auth_counter <== (*)

The auth_counter being included in this patch is just an example of
this functionality. It does not have significant meanings. It just logs
number of authentication success and fails every intervals.

I'm motivated to define an extra daemon that attach shared memory
segment of PostgreSQL as a computing server to avoid limitation of
number of GPU code that we can load concurrently.

Thanks,

I have tested this original version. The patch has a single trivial reject,
after fixing it, it compiled nicely.

After adding shared_preload_libraries='$libdir/auth_counter', the extra
daemon start and stops nicely with pg_ctl start/stop. The auth_counter.c
code is a fine minimalistic example on writing one's own daemon.

Thanks,
Zoltán Böszörményi

--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
http://www.postgresql.at/

2012/6/29 Boszormenyi Zoltan <zb@cybertec.at>:

2012-04-25 11:40 keltezéssel, Kohei KaiGai írta:

2012/3/10 Simon Riggs <simon@2ndquadrant.com>:

On Fri, Mar 9, 2012 at 6:51 PM, Andrew Dunstan <andrew@dunslane.net>
wrote:

On 03/09/2012 01:40 PM, Robert Haas wrote:

On Fri, Mar 9, 2012 at 12:02 PM, David E.
Wheeler<david@justatheory.com>
 wrote:

On Mar 9, 2012, at 7:55 AM, Merlin Moncure wrote:

100% agree  (having re-read the thread and Alvaro's idea having sunk
in).  Being able to set up daemon processes side by side with the
postmaster would fit the bill nicely.  It's pretty interesting to
think of all the places you could go with it.

pgAgent could use it *right now*. I keep forgetting to restart it
after
restarting PostgreSQL and finding after a day or so that no jobs have
run.

That can and should be fixed by teaching pgAgent that failing to
connect to the server, or getting disconnected, is not a fatal error,
but a reason to sleep and retry.

Yeah. It's still not entirely clear to me what a postmaster-controlled
daemon is going to be able to do that an external daemon can't.

Start and stop at the same time as postmaster, without any pain.

It's a considerable convenience to be able to design this aspect once
and then have all things linked to the postmaster follow that. It
means people will be able to write code that runs on all OS easily,
without everybody having similar but slightly different code about
starting up, reading parameters, following security rules etc.. Tight
integration, with good usability.

I tried to implement a patch according to the idea. It allows extensions
to register an entry point of the self-managed daemon processes,
then postmaster start and stop them according to the normal manner.

[kaigai@iwashi patch]$ ps ax | grep postgres
27784 pts/0    S      0:00 /usr/local/pgsql/bin/postgres
27786 ?        Ss     0:00 postgres: writer process
27787 ?        Ss     0:00 postgres: checkpointer process
27788 ?        Ss     0:00 postgres: wal writer process
27789 ?        Ss     0:00 postgres: autovacuum launcher process
27790 ?        Ss     0:00 postgres: stats collector process
27791 ?        Ss     0:00 postgres: auth_counter              <== (*)

The auth_counter being included in this patch is just an example of
this functionality. It does not have significant meanings. It just logs
number of authentication success and fails every intervals.

I'm motivated to define an extra daemon that attach shared memory
segment of PostgreSQL as a computing server to avoid limitation of
number of GPU code that we can load concurrently.

Thanks,

I have tested this original version. The patch has a single trivial reject,
after fixing it, it compiled nicely.

After adding shared_preload_libraries='$libdir/auth_counter', the extra
daemon start and stops nicely with pg_ctl start/stop. The auth_counter.c
code is a fine minimalistic example on writing one's own daemon.

Thanks for your testing.

According to Simon's comment, I'm waiting for his integration of this patch
with another implementation by him.

The auth_counter is just an proof-of-concept patch, so, it is helpful if you
could provide another use case that can make sense.

Best regards,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>

2012-06-29 16:44 keltezéssel, Kohei KaiGai írta:

2012/6/29 Boszormenyi Zoltan <zb@cybertec.at>:

2012-04-25 11:40 keltezéssel, Kohei KaiGai írta:

2012/3/10 Simon Riggs <simon@2ndquadrant.com>:

On Fri, Mar 9, 2012 at 6:51 PM, Andrew Dunstan <andrew@dunslane.net>
wrote:

On 03/09/2012 01:40 PM, Robert Haas wrote:

On Fri, Mar 9, 2012 at 12:02 PM, David E.
Wheeler<david@justatheory.com>
wrote:

On Mar 9, 2012, at 7:55 AM, Merlin Moncure wrote:

100% agree (having re-read the thread and Alvaro's idea having sunk
in). Being able to set up daemon processes side by side with the
postmaster would fit the bill nicely. It's pretty interesting to
think of all the places you could go with it.

pgAgent could use it *right now*. I keep forgetting to restart it
after
restarting PostgreSQL and finding after a day or so that no jobs have
run.

That can and should be fixed by teaching pgAgent that failing to
connect to the server, or getting disconnected, is not a fatal error,
but a reason to sleep and retry.

Yeah. It's still not entirely clear to me what a postmaster-controlled
daemon is going to be able to do that an external daemon can't.

Start and stop at the same time as postmaster, without any pain.

It's a considerable convenience to be able to design this aspect once
and then have all things linked to the postmaster follow that. It
means people will be able to write code that runs on all OS easily,
without everybody having similar but slightly different code about
starting up, reading parameters, following security rules etc.. Tight
integration, with good usability.

I tried to implement a patch according to the idea. It allows extensions
to register an entry point of the self-managed daemon processes,
then postmaster start and stop them according to the normal manner.

[kaigai@iwashi patch]$ ps ax | grep postgres
27784 pts/0 S 0:00 /usr/local/pgsql/bin/postgres
27786 ? Ss 0:00 postgres: writer process
27787 ? Ss 0:00 postgres: checkpointer process
27788 ? Ss 0:00 postgres: wal writer process
27789 ? Ss 0:00 postgres: autovacuum launcher process
27790 ? Ss 0:00 postgres: stats collector process
27791 ? Ss 0:00 postgres: auth_counter <== (*)

The auth_counter being included in this patch is just an example of
this functionality. It does not have significant meanings. It just logs
number of authentication success and fails every intervals.

I'm motivated to define an extra daemon that attach shared memory
segment of PostgreSQL as a computing server to avoid limitation of
number of GPU code that we can load concurrently.

Thanks,

I have tested this original version. The patch has a single trivial reject,
after fixing it, it compiled nicely.

After adding shared_preload_libraries='$libdir/auth_counter', the extra
daemon start and stops nicely with pg_ctl start/stop. The auth_counter.c
code is a fine minimalistic example on writing one's own daemon.

Thanks for your testing.

According to Simon's comment, I'm waiting for his integration of this patch
with another implementation by him.

The auth_counter is just an proof-of-concept patch, so, it is helpful if you
could provide another use case that can make sense.

Well, we have two use cases that are more complex:

- an SQL-driven scheduler, similar to pgAgent, it's generic enough,
we might port it to this scheme and publish it
- a huge volume importer daemon, it was written for a very specific
purpose and for a single client, we cannot publish it.

Both need database connections, the second needs more than one,
so they need to link to the client side libpq, the way it was done for
walreceiver can be done here as well.

Best regards,
Zoltán Böszörményi

--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
http://www.postgresql.at/

On Fri, Jun 29, 2012 at 9:44 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:

The auth_counter is just an proof-of-concept patch, so, it is helpful if you
could provide another use case that can make sense.

what about pgbouncer?

--
Jaime Casanova         www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación

2012/6/21 Simon Riggs <simon@2ndquadrant.com>:

On 21 June 2012 19:13, Jaime Casanova <jaime@2ndquadrant.com> wrote:

On Sun, Jun 10, 2012 at 4:15 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:

2012/6/8 Simon Riggs <simon@2ndquadrant.com>:

I have a prototype that has some of these characteristics, so I see
our work as complementary.

At present, I don't think this patch would be committable in CF1, but
I'd like to make faster progress with it than that. Do you want to
work on this more, or would you like me to merge our prototypes into a
more likely candidate?

I'm not favor in duplicate similar efforts. If available, could you merge
some ideas in my patch into your prototypes?

so, we are waiting for a new patch? is it coming from Simon or Kohei?

There is an updated patch coming from me. I thought I would focus on
review of other work first.

Simon, what about the current status of this patch?

Do I have something to help for the integration by the upcoming CF?

Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>

Excerpts from Boszormenyi Zoltan's message of vie jun 29 09:11:23 -0400 2012:

We have some use cases for this patch, when can you post
a new version? I would test and review it.

What use cases do you have in mind?

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

2012/9/11 Alvaro Herrera <alvherre@2ndquadrant.com>:

Excerpts from Boszormenyi Zoltan's message of vie jun 29 09:11:23 -0400 2012:

We have some use cases for this patch, when can you post
a new version? I would test and review it.

What use cases do you have in mind?

I'm motivated with this feature to implement background calculation server
to handle accesses to GPU device; to avoid limitation of number of processes
that can use GPU device simultaneously.

Probably, other folks have their use cases.
For example, Zoltan introduced his use case in the upthread as follows:

- an SQL-driven scheduler, similar to pgAgent, it's generic enough,
we might port it to this scheme and publish it
- a huge volume importer daemon, it was written for a very specific
purpose and for a single client, we cannot publish it.

Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>

Excerpts from Kohei KaiGai's message of mar sep 11 12:46:34 -0300 2012:

2012/9/11 Alvaro Herrera <alvherre@2ndquadrant.com>:

Excerpts from Boszormenyi Zoltan's message of vie jun 29 09:11:23 -0400 2012:

We have some use cases for this patch, when can you post
a new version? I would test and review it.

What use cases do you have in mind?

I'm motivated with this feature to implement background calculation server
to handle accesses to GPU device; to avoid limitation of number of processes
that can use GPU device simultaneously.

Hmm, okay, so basically a worker would need a couple of LWLocks, a
shared memory area, and not much else? Not a database connection.

Probably, other folks have their use cases.
For example, Zoltan introduced his use case in the upthread as follows:

- an SQL-driven scheduler, similar to pgAgent, it's generic enough,
we might port it to this scheme and publish it

Hm, this would benefit from a direct backend connection to get the
schedule data (SPI interface I guess).

- a huge volume importer daemon, it was written for a very specific
purpose and for a single client, we cannot publish it.

This one AFAIR requires more than one connection, so a direct data
connection is no good -- hence link libpq like walreceiver.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

2012/9/11 Alvaro Herrera <alvherre@2ndquadrant.com>:

Excerpts from Kohei KaiGai's message of mar sep 11 12:46:34 -0300 2012:

2012/9/11 Alvaro Herrera <alvherre@2ndquadrant.com>:

Excerpts from Boszormenyi Zoltan's message of vie jun 29 09:11:23 -0400 2012:

We have some use cases for this patch, when can you post
a new version? I would test and review it.

What use cases do you have in mind?

I'm motivated with this feature to implement background calculation server
to handle accesses to GPU device; to avoid limitation of number of processes
that can use GPU device simultaneously.

Hmm, okay, so basically a worker would need a couple of LWLocks, a
shared memory area, and not much else? Not a database connection.

Right. It needs shared memory area to communicate with each backend
and locking mechanism, but my case does not take database accesses
right now.

Probably, other folks have their use cases.
For example, Zoltan introduced his use case in the upthread as follows:

- an SQL-driven scheduler, similar to pgAgent, it's generic enough,
we might port it to this scheme and publish it

Hm, this would benefit from a direct backend connection to get the
schedule data (SPI interface I guess).

I also think SPI interface will be first candidate for the daemons that
needs database access. Probably, lower layer interfaces (such as
heap_open and heap_beginscan) are also available if SPI interface
can be used.

Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>

Excerpts from Kohei KaiGai's message of mar sep 11 13:25:18 -0300 2012:

2012/9/11 Alvaro Herrera <alvherre@2ndquadrant.com>:

- an SQL-driven scheduler, similar to pgAgent, it's generic enough,
we might port it to this scheme and publish it

Hm, this would benefit from a direct backend connection to get the
schedule data (SPI interface I guess).

I also think SPI interface will be first candidate for the daemons that
needs database access. Probably, lower layer interfaces (such as
heap_open and heap_beginscan) are also available if SPI interface
can be used.

Well, as soon as you have a database connection on which you can run
SPI, you need a lot of stuff to ensure your transaction is aborted in
case of trouble and so on. At that point you can do direct access as
well.

I think it would be a good design to provide different cleanup routes
for the different use cases: for those that need database connections we
nede to go through AbortOutOfAnyTransaction() or something similar; for
others we can probably get away with much less than that. Not 100% sure
at this point.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

2012-09-11 17:58 keltezéssel, Alvaro Herrera írta:

Excerpts from Kohei KaiGai's message of mar sep 11 12:46:34 -0300 2012:

2012/9/11 Alvaro Herrera <alvherre@2ndquadrant.com>:

Excerpts from Boszormenyi Zoltan's message of vie jun 29 09:11:23 -0400 2012:

We have some use cases for this patch, when can you post
a new version? I would test and review it.

What use cases do you have in mind?

I'm motivated with this feature to implement background calculation server
to handle accesses to GPU device; to avoid limitation of number of processes
that can use GPU device simultaneously.

Hmm, okay, so basically a worker would need a couple of LWLocks, a
shared memory area, and not much else? Not a database connection.

Probably, other folks have their use cases.
For example, Zoltan introduced his use case in the upthread as follows:

- an SQL-driven scheduler, similar to pgAgent, it's generic enough,
we might port it to this scheme and publish it

Hm, this would benefit from a direct backend connection to get the
schedule data (SPI interface I guess).

Indeed. And the advantage is that the scheduler's lifetime is exactly
the server's lifetime so there is no need to try reconnecting as soon
as the server goes away and wait until it comes back.

- a huge volume importer daemon, it was written for a very specific
purpose and for a single client, we cannot publish it.

This one AFAIR requires more than one connection, so a direct data
connection is no good -- hence link libpq like walreceiver.

Yes.

Best regards,
Zoltán Böszörményi

--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
http://www.postgresql.at/

On Tuesday, September 11, 2012 9:09 PM Alvaro Herrera wrote:
Excerpts from Boszormenyi Zoltan's message of vie jun 29 09:11:23 -0400 2012:

We have some use cases for this patch, when can you post
a new version? I would test and review it.

What use cases do you have in mind?

Wouldn't it be helpful for some features like parallel query in future?

With Regards,
Amit Kapila.

Excerpts from Amit Kapila's message of mié sep 12 00:30:40 -0300 2012:

On Tuesday, September 11, 2012 9:09 PM Alvaro Herrera wrote:
Excerpts from Boszormenyi Zoltan's message of vie jun 29 09:11:23 -0400 2012:

We have some use cases for this patch, when can you post
a new version? I would test and review it.

What use cases do you have in mind?

Wouldn't it be helpful for some features like parallel query in future?

Maybe, maybe not -- but I don't think it's a wise idea to include too
much complexity just to support such a thing. I would vote to leave
that out for now and just concentrate on getting external stuff working.
There are enough use cases that it's already looking nontrivial.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services