From DBD::Pg:

ATTRIBUTES COMMON TO ALL HANDLES
       InactiveDestroy (boolean)

       If set to true, then the "disconnect" method will not be
       automatically called when the database handle goes out of
       scope. This is required if you are forking, and even then
       you must tread carefully and ensure that either the parent
       or the child (but not both!) handles all database calls
       from that point forwards, so that messages from the
       Postgres backend are only handled by one of the processes.
       If you don't set things up properly, you will see messages
       such as "server closed the connection unexpectedly", and
       "message type 0x32 arrived from server while idle". The
       best solution is to either have the child process
       reconnect to the database with a fresh database handle, or
       to rewrite your application not to use use forking. See
       the section on "Asynchronous Queries" for a way to have
       your script continue to work while the database is
       processing a request.
[download]

so sharing the database handle between children will not work. You weren't exactly clear on what you meant by having access to the table, but since it is temporary, it will be destroyed at the end of the session and so re-opening the database handle for each forked child will not work either. Perhaps you should create a non-temporary table, re-open the database handle in each child and drop the table when your parent process exits. Alternatively you could use a different Net::Server personality, like Net::Server::Multiplex, which doesn't fork.