[HACKERS] NOTIFY in Background Worker

2015-08-28 Thread jacques klein
Hello,

I added a NOFITY chan to the SQL arg of an SPI_execute(), (I did it
also with just the NOTIFY statement),
but the listeners (other workers) don't get the notification until a
NOTIFY chan is done for example with pgadmin,

They don't get lost, just not emited after the not forgotten call of
CommitTransactionCommand().

Is this normal ( i.e. not supported (yet) ), a bug, or did I overlook
some doc. (or source code) ?.

For now, I will try to emit the NOTIFY via libpq.

Jacques K.



[HACKERS] how to write/setup a C trigger function in a background worker

2015-08-19 Thread jacques klein
I would like to execute a trigger function (written in C) in one of my
background workers.

Didn't figure out how to do that not even if it's possible.

Currently my trigger function is called, but in the server-process
connected to the client who does the insert into ... .

Any hint/help is welcome.

Jacques K.




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] how to write/setup a C trigger function in a background worker

2015-08-19 Thread jacques klein
Well, sorry David, I don't understand what you mean,

let me explain what I want to do: in short, IPC between background
workers.

I am trying to transform my app. from a multi-threaded C SQL-client into
some background workers, execution speed beeing the goal (avoid
network io).
Worker start/stopping is nicely solved by server start/stop, but I have
also to do some messaging/notifying between my worker processes, and
would like to use a Postgres based solution instead of the usual unix or
network ipc, or course by avoiding polling (tables acting as message
queues).


On Wed, 2015-08-19 at 10:01 -0700, David Fetter wrote:
 On Wed, Aug 19, 2015 at 05:37:31PM +0200, jacques klein wrote:
  I would like to execute a trigger function (written in C) in one of my
  background workers.
  
  Didn't figure out how to do that not even if it's possible.
 
 You can write your trigger function in such a way as not to do the
 usual check for trigger context, but it might be better to write two
 functions, one with the trigger stuff in it, the other, which it
 calls, for whatever action you actually want to trigger, and call that
 second in your background worker.
 
 Cheers,
 David.




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] how to write/setup a C trigger function in a background worker

2015-08-19 Thread jacques klein
Ok, think I got it,

I can use LISTEN and NOTIFY to do my IPC stuf, will just have to see if
it's possible to listen in a worker, with a permanent server connection,
I guess.
(as I remember, I already did a listener 10 years ago in a C client
app.)

Thanks,
Jaquest K.


On Wed, 2015-08-19 at 16:54 -0400, Bill Moran wrote:
 On Wed, 19 Aug 2015 19:45:47 +0200
 jacques klein jacques.k...@googlemail.com wrote:
 
  Well, sorry David, I don't understand what you mean,
  
  let me explain what I want to do: in short, IPC between background
  workers.
  
  I am trying to transform my app. from a multi-threaded C SQL-client into
  some background workers, execution speed beeing the goal (avoid
  network io).
  Worker start/stopping is nicely solved by server start/stop, but I have
  also to do some messaging/notifying between my worker processes, and
  would like to use a Postgres based solution instead of the usual unix or
  network ipc, or course by avoiding polling (tables acting as message
  queues).
 
 I think what David is saying, and what I would suggest, is the
 following:
 
 * It's not possible to have a trigger execute in the background
 * Create a background job that runs perpetually and listens for
   notification that it has work to do (i.e. it sleeps until notified)
 * Notify the job from the trigger
 
  On Wed, 2015-08-19 at 10:01 -0700, David Fetter wrote:
   On Wed, Aug 19, 2015 at 05:37:31PM +0200, jacques klein wrote:
I would like to execute a trigger function (written in C) in one of my
background workers.

Didn't figure out how to do that not even if it's possible.
   
   You can write your trigger function in such a way as not to do the
   usual check for trigger context, but it might be better to write two
   functions, one with the trigger stuff in it, the other, which it
   calls, for whatever action you actually want to trigger, and call that
   second in your background worker.
   
   Cheers,
   David.
  
  
  
  
  -- 
  Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
  To make changes to your subscription:
  http://www.postgresql.org/mailpref/pgsql-hackers
 
 




-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] How to compile, link and use a C++ extension

2015-08-14 Thread jacques klein
Hello, I want to write a BackgroundWorker in C++ (have lots of C++ 
code and libs to reuse).


I found35.9.13 Using C++ for Extensibility  in the 9.3/4 
documentation who says it's possible and gives some guidelines for 
source-code writing.

Compiling is not too difficult if one understands this chapter.

However I coudn't find any doc. about how to solve the problem of 
linking C++ code and libs into the .so of my extension,
and nothing to solve the runtime-loading problem of the c++ specific .so 
files ( for ex. to make work a simple usage std::string )


I started my tests by cloning the contrib/worker_spi code, and when 
transforming the code into C++, I could only note that C++ is not 
supported in the provided Makefiles.


I also found some rather old (2008) message in this mailing list which 
addresses the same subject:
 http://www.postgresql.org/message-id/4938e5ed.60...@acm.org: 
Mostly Harmless: Welcoming our C++ friends

with patches that didn't reach their way into the source-distrib , I guess.

Is there something more actual about this subject that could help ?.

Jacques K.