CG <[EMAIL PROTECTED]> writes:
> Thanks to the great suggestions I've at least gotten it to not hang...
>
> Martijn's hint about blocking led me to open up those filehandles in
> a non-blocking mode. It appears that write() will write, at a
> maximum, only 4096 bytes when it is called from within
Thanks to the great suggestions I've at least gotten it to not hang...
Martijn's hint about blocking led me to open up those filehandles in a
non-blocking mode. It appears that write() will write, at a maximum, only 4096
bytes when it is called from within PostgreSQL. I've tried to push data int
Martijn van Oosterhout writes:
> The things that have screwed me up in the past with pulling tricks like
> this are:
>
> 1. Program has registered atexit() handlers. _exit() avoids this.
> 2. Pending stdio output that gets flushed. The backend doesn't use
> stdio much so you might be fine here.
>
On Fri, Oct 28, 2005 at 11:59:03AM -0400, Douglas McNaught wrote:
> Dennis Jenkins <[EMAIL PROTECTED]> writes:
>
> > Is it safe for the postgres engine to fork()? Would
> > the child need to close down anything immediately in
> > its main() to avoid corrupting the parent?
>
> I *think* (Tom may
Dennis Jenkins <[EMAIL PROTECTED]> writes:
> Is it safe for the postgres engine to fork()? Would
> the child need to close down anything immediately in
> its main() to avoid corrupting the parent?
I *think* (Tom may correct me) that as long as you don't call into the
backend code at all in the c
--- CG <[EMAIL PROTECTED]> wrote:
>
> There's no other way to load data into the toolkit!
> (Can you /feel/ the
> insanity?)
>
> Does this give you any more insight into an
> alternate method of getting this
> thing done?
>
Write a completely seperate process to process your
FDF stuff. Have th
--- Douglas McNaught <[EMAIL PROTECTED]> wrote:
> CG <[EMAIL PROTECTED]> writes:
>
> > Does this give you any more insight into an
> alternate method of getting this
> > thing done?
>
> I would fork(), set up file descriptors
> appropriately, then have the
> child call the Adobe library and th
--- Martijn van Oosterhout wrote:
> On Fri, Oct 28, 2005 at 07:24:12AM -0700, CG wrote:
> Not entirely sure, but I'm sure the size of the write matters. For
> example, if your test rpogram, did you check that the write actually
> wrote everything?
There's beginning and ending tokens in the FDF f
On Fri, Oct 28, 2005 at 07:24:12AM -0700, CG wrote:
> So it might be a kernel thing. What is different when the function is called
> from within PostgreSQL that is different that the function being called in a
> standalone program?
Not entirely sure, but I'm sure the size of the write matters. For
CG <[EMAIL PROTECTED]> writes:
> Does this give you any more insight into an alternate method of getting this
> thing done?
I would fork(), set up file descriptors appropriately, then have the
child call the Adobe library and the parent feed the data to it.
Once the document is loaded in the chil
--- Martijn van Oosterhout wrote:
> On Fri, Oct 28, 2005 at 06:38:29AM -0700, CG wrote:
>
> Umm, what *are* you trying to do? Is this running in the backend?
Yes, running on the back-end. I'm trying to utilize Adobe's FDF toolkit to
parse the FDF files stored in my database. They distirubte a C
On Fri, Oct 28, 2005 at 06:38:29AM -0700, CG wrote:
> PostgreSQL 7.4 ...
>
> Essentially, I've written a function in C for use with PostgreSQL. The
> debugger
> shows that the program is hanging on the part of the program that is writing
> data into it's own STDIN.
Umm, what *are* you trying to
12 matches
Mail list logo
