Re: Non-blocking archiver process

Here are a few comments from me:

I think that by calling system(), anything that is printed out by the child
process ends up in the PostgreSQL log. With the patch, the output of the
command seems like it will be read into a buffer and discarded. That's a
significant behavior difference.

This patch has a 10ms polling loop after which it checks for interrupts,
and then repeats. I think our normal convention in these kinds of cases is
to use WaitLatchOrSocket(). That allows for a longer sleep time (like 1s)
which results in fewer processor wakeups, while actually still being more
responsive because the arrival of an interrupt should set the process latch
and terminate the wait.

In general, I agree with Artem's comments about writing code that fits the
PostgreSQL style. We don't want to invent new ways of solving problems for
which we already have infrastructure, nor do we want to solve problems in
this case in a way that is different from what we do in other cases. Using
ereport appropriately is part of that, but there's a lot more to it. Artem
mentioned malloc and free, but notice, for example, that we also have our
own wrapper around popen() in OpenPipeStream(). Maybe we shouldn't use that
here, but we shouldn't *accidentally* not use that here.

I wonder whether we should really be using popen() in any form, actually.
If what we want is for the output of the command to go to our standard
output, as it does with system(), that's exactly what popen() is designed
not to do, so it doesn't seem like a natural fit. Perhaps we should be
using fork() + exec()? Or maybe we already have some good infrastructure
for this we can reuse somewhere?

--
Robert Haas
EDB: http://www.enterprisedb.com