Re: Trigger that spawns forked process - Mailing list pgsql-general

From Christopher Murtagh
Subject Re: Trigger that spawns forked process
Date
Msg-id 1115760716.9735.50.camel@localhost.localdomain
Whole thread Raw
In response to Re: Trigger that spawns forked process  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Trigger that spawns forked process
List pgsql-general
On Tue, 2005-05-10 at 16:17 -0400, Tom Lane wrote:
> ... let's see, you already broke the backend there --- unless its normal
> setting of SIGCHLD is IGNORE, in which case munging it is unnecessary
> anyway ...

Here's my (probably all garbled) explanation: Essentially what that code
is a self-daemonizing perl wrapper. Setting SIGCHLD to IGNORE will
prevent zombie processes from hanging around, essentially
daemonizing/orphaning/forking the perl script.

> > unless ($pid) {
> >      $cmd="your command here";
> >      system "$cmd";
> >      if ($? != 0) {
> >          # handle errors here
> >      }
> >      exit;
> > }
>
> I'm not sure what happens when you do "exit" here, but I'll lay odds
> against it being exactly the right things.

It ends the daemonized process, kinda like a wrapper suicide. :-)

> (An atexit hook in a backend
> process is entitled to suppose it is cleaning up a backend.)  Also,
> exactly what is your "handle errors" step going to be?

Well, if my command fails for some reason, I can replace '#handle
errors' with something that notifies me (email, or by populating the
database, etc.).

> You don't get to reflect anything back into the database at that point.

 That's ok, my $cmd might or might not have db connections in it, same
for the error checking script (which could be written in a totally
different language).

> The main reason why this is probably a bad idea is that your
> transaction is causing side-effects outside the database that cannot
> be undone if the transaction later rolls back. The general consensus
> of people who have looked at this is that it's safer to fire those
> operations after the transaction actually commits.

 I should have stated that this will get used only by single auto-commit
transactions. Any rollbacks are essentially changes to the past and
aren't permitted. Instead if someone wanted to 'undo' a change, they
would re-submit a previous version. This way, I can keep my replication
code to very atomic things which makes it very simple to write and
maintain.

 From my (somewhat limited experience) point of view, I think that this
plperlu script isn't much different from writing a daemon to receive
signals via NOTIFY. Instead the script is self daemonizing, and it will
always run (instead of a couple of NOTIFY's building up and only one
being sent), which is more in line with what I want.

 Sorry, my explanation probably isn't very clear at all, I've been
writing talk material and my brain is in a totally different space. Feel
free to deliver any LARTs. :-)

Cheers,

Chris



pgsql-general by date:

Previous
From: Christopher Murtagh
Date:
Subject: Re: Trigger that spawns forked process
Next
From: Mischa Sandberg
Date:
Subject: Re: [PERFORM] "Hash index" vs. "b-tree index" (PostgreSQL