pg.ddx.io pgsql-sql@postgresql.org mailing list archive
help / color / mirror / Atom feedC function - other process
5+ messages / 3 participants
[nested] [flat]
* C function - other process
@ 2005-04-22 19:18 Jakub <kubaw@o2.pl>
2005-04-22 19:39 ` Re: C function - other process Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 5+ messages in thread
From: Jakub Woźny @ 2005-04-22 19:18 UTC (permalink / raw)
To: pgsql-sql
Hello,
I wrote a simple function:
PG_FUNCTION_INFO_V1(my_fcn);
Datum
my_fcn()
{
int i,ret;
i=0;
signal(SIGCHLD,SIG_IGN);
switch(fork())
{
case 0:
{
SPI_connect();
for(i=0;i<10;i++)
{
SPI_exec("insert into my_tmp values ('asdasd');",1);
sleep(1);
}
ret = SPI_finish();
exit(ret);
}
default:
{
;
}
}
}
Next I create a function in my database:
CREATE FUNCTION my_fcn() RETURNS void
AS '$libdir/my_fcn', 'my_fcn'
LANGUAGE c;
Now I execute "select my_fcn();" and I don't see records in table
'my_tmp', but function works.
I checked returns values from SPI function, tehere are correct.
What is wrong?
Best regards,
jakub
--
kubaw@o2.pl
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: C function - other process
2005-04-22 19:18 C function - other process Jakub <kubaw@o2.pl>
@ 2005-04-22 19:39 ` Tom Lane <tgl@sss.pgh.pa.us>
2005-04-22 20:01 ` Re: C function - other process Michael Fuhr <mike@fuhr.org>
0 siblings, 1 reply; 5+ messages in thread
From: Tom Lane @ 2005-04-22 19:39 UTC (permalink / raw)
To: Jakub Woźny <kubaw@o2.pl>; +Cc: pgsql-sql
Jakub =?ISO-8859-2?Q?Wo=BCny?= <kubaw@o2.pl> writes:
> I wrote a simple function:
> signal(SIGCHLD,SIG_IGN);
> switch(fork())
This will NOT work. It WILL corrupt your database. You do not get to
randomly introduce new processes into the backend set.
regards, tom lane
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: C function - other process
2005-04-22 19:18 C function - other process Jakub <kubaw@o2.pl>
2005-04-22 19:39 ` Re: C function - other process Tom Lane <tgl@sss.pgh.pa.us>
@ 2005-04-22 20:01 ` Michael Fuhr <mike@fuhr.org>
2005-04-22 20:07 ` Re: C function - other process Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 5+ messages in thread
From: Michael Fuhr @ 2005-04-22 20:01 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Jakub Wo?ny <kubaw@o2.pl>; pgsql-sql
On Fri, Apr 22, 2005 at 03:39:55PM -0400, Tom Lane wrote:
> Jakub =?ISO-8859-2?Q?Wo=BCny?= <kubaw@o2.pl> writes:
> > I wrote a simple function:
>
> > signal(SIGCHLD,SIG_IGN);
> > switch(fork())
>
> This will NOT work. It WILL corrupt your database. You do not get to
> randomly introduce new processes into the backend set.
What about fork() followed by exec*(), either explicitly or via
popen(), system(), etc.? Should these be avoided as well, or is
there a safe way to do them? I'm thinking of the case where a
user-defined function wants to invoke some external command -- I've
done that in experiments but I've never been sure how safe it was.
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: C function - other process
2005-04-22 19:18 C function - other process Jakub <kubaw@o2.pl>
2005-04-22 19:39 ` Re: C function - other process Tom Lane <tgl@sss.pgh.pa.us>
2005-04-22 20:01 ` Re: C function - other process Michael Fuhr <mike@fuhr.org>
@ 2005-04-22 20:07 ` Tom Lane <tgl@sss.pgh.pa.us>
2005-04-22 20:36 ` Re: C function - other process Michael Fuhr <mike@fuhr.org>
0 siblings, 1 reply; 5+ messages in thread
From: Tom Lane @ 2005-04-22 20:07 UTC (permalink / raw)
To: Michael Fuhr <mike@fuhr.org>; +Cc: Jakub Wo?ny <kubaw@o2.pl>; pgsql-sql
Michael Fuhr <mike@fuhr.org> writes:
> What about fork() followed by exec*(), either explicitly or via
> popen(), system(), etc.? Should these be avoided as well, or is
> there a safe way to do them? I'm thinking of the case where a
> user-defined function wants to invoke some external command -- I've
> done that in experiments but I've never been sure how safe it was.
Execing some new program is safe enough, although you might wish to
explicitly close the various sockets the backend holds to make sure
the new program doesn't maliciously scribble on them. (It may be worth
marking them close-on-exec, although doing this without breaking the
Windows port might be hard.)
The problem with the hack at hand is that you can't have two processes
sharing the same backend slot (not to mention the same transaction ID).
But launching something that isn't a backend is no problem.
regards, tom lane
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: C function - other process
2005-04-22 19:18 C function - other process Jakub <kubaw@o2.pl>
2005-04-22 19:39 ` Re: C function - other process Tom Lane <tgl@sss.pgh.pa.us>
2005-04-22 20:01 ` Re: C function - other process Michael Fuhr <mike@fuhr.org>
2005-04-22 20:07 ` Re: C function - other process Tom Lane <tgl@sss.pgh.pa.us>
@ 2005-04-22 20:36 ` Michael Fuhr <mike@fuhr.org>
0 siblings, 0 replies; 5+ messages in thread
From: Michael Fuhr @ 2005-04-22 20:36 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-sql
On Fri, Apr 22, 2005 at 04:07:48PM -0400, Tom Lane wrote:
>
> Execing some new program is safe enough, although you might wish to
> explicitly close the various sockets the backend holds to make sure
> the new program doesn't maliciously scribble on them.
Is there a way to find out which fds to close, or should a function
just close everything from, say, 3 to <some value> (assuming that
0, 1, and 2 are stdin, stdout, and stderr)? I could think of
non-portable ways like looking under /proc/<pid>/fd, but I was
wondering if the backend keeps track of its fds somewhere.
Thanks.
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2005-04-22 20:36 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2005-04-22 19:18 C function - other process Jakub <kubaw@o2.pl>
2005-04-22 19:39 ` Tom Lane <tgl@sss.pgh.pa.us>
2005-04-22 20:01 ` Michael Fuhr <mike@fuhr.org>
2005-04-22 20:07 ` Tom Lane <tgl@sss.pgh.pa.us>
2005-04-22 20:36 ` Michael Fuhr <mike@fuhr.org>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox