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.
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.