pg_background and BGWH_STOPPED

Hello,

We probably identified a bug in the pg_background implementation: https://github.com/vibhorkum/pg_background 
It is a race condition when starting the process and BGWH_STOPPED is returned - see the pull request for more info:
https://github.com/RekGRpth/pg_background/pull/1
 

I think I have created a fix (in one of the forks of the original repo, https://github.com/RekGRpth/pg_background,
whichalready addresses some compilation issues), but then again I am not very familiar with PG API and would very much
appreciateif anyone could review  the bug and approve the  solution.
 

Regards

Martin

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of amul sul
Sent: Thursday, November 24, 2016 4:47 AM
To: PostgreSQL-development
Subject: pg_background contrib module proposal

Hi All,

I would like to take over pg_background patch and repost for discussion and review.

Initially Robert Haas has share this for parallelism demonstration[1] and abandoned later with summary of open issue[2]
withthis pg_background patch need to be fixed, most of them seems to be addressed in core except handling of type
existswithout binary send/recv functions and documentation.
 
I have added handling for types that don't have binary send/recv functions in the attach patch and will work on
documentationat the end.
 

One concern with this patch is code duplication with exec_simple_query(), we could consider Jim Nasby’s patch[3] to
overcomethis,  but  certainly we will end up by complicating
 
exec_simple_query() to make pg_background happy.

As discussed previously[1] pg_background is a contrib module that lets you launch arbitrary command in a background
worker.

• VACUUM in background
• Autonomous transaction implementation better than dblink way (i.e.
no separate authentication required).
• Allows to perform task like CREATE INDEX CONCURRENTLY from a procedural language.

This module comes with following SQL APIs:

• pg_background_launch : This API takes SQL command, which user wants to execute, and size of queue buffer.
  This function returns the process id of background worker.
• pg_background_result   : This API takes the process id as input
parameter and returns the result of command
  executed thought the background worker.
• pg_background_detach : This API takes the process id and detach the background process which is waiting for  user to
readits results.
 


Here's an example of running vacuum and then fetching the results.
Notice that the
notices from the original session are propagated to our session; if an error had occurred, it would be re-thrown
locallywhen we try to read the results.
 

postgres=# create table foo (a int);
CREATE TABLE
postgres=# insert into foo values(generate_series(1,5)); INSERT 0 5

postgres=# select pg_background_launch('vacuum verbose foo'); pg_background_launch
----------------------
              65427
(1 row)

postgres=# select * from pg_background_result(65427) as (x text);
INFO:  vacuuming "public.foo"
INFO:  "foo": found 0 removable, 5 nonremovable row versions in 1 out of 1 pages
DETAIL:  0 dead row versions cannot be removed yet.
There were 0 unused item pointers.
Skipped 0 pages due to buffer pins.
0 pages are entirely empty.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
 x
--------
VACUUM
(1 row)


Thanks to Vibhor kumar, Rushabh Lathia and Robert Haas for feedback.

Please let me know your thoughts, and thanks for reading.

[1].
https://www.postgresql.org/message-id/CA%2BTgmoam66dTzCP8N2cRcS6S6dBMFX%2BJMba%2BmDf68H%3DKAkNjPQ%40mail.gmail.com
[2]. https://www.postgresql.org/message-id/CA%2BTgmobPiT_3Qgjeh3_v%2B8Cq2nMczkPyAYernF_7_W9a-6T1PA%40mail.gmail.com
[3]. https://www.postgresql.org/message-id/54541779.1010906%40BlueTreble.com

Regards,
Amul