Thank you Craig,
>At a guess: transactional visibility. P1 will have not yet committed
its
>transaction, so the data isn't visible to P2 yet. Remember, PostgreSQL
>defaults to the READ COMMITTED isolation level and does not offer READ
>UNCOMMITTED for those rare situations where you might want it.
P1 did commit its insertion; even it commits its every transaction.
>By "send a trigger" I'm assuming you mean that you're using RAISE
NOTICE
>and LISTEN.
By 'send a trigger' what I meant was, P1 sends a TCP packet to P2 (It is
the preferred IPC in our application) asking it to start querying for
data.
>If P1 commits, then raises a notice to tell P2 about the changes, P2
>should be able to see the changes immediately. Even if P2's transaction
>began before it receives the notice it should still see the changes
>(because of READ COMMITTED isolation). However, if a function or
>statement is running in P2 when P1 commits, the changes made by P1 will
>only become visible after that function or statement finishes.
>If I'm mistaken in my interpretation and P1 does in fact commit before
>notifying P2 of the changes, then there must be something else going
on.
>Perhaps a bit more detail might help.
Processes P1 and P2 are executables developed in VC++. These are the
steps performed by P1 before sending the TCP packet (which acts as a
trigger) to P2.
1) Create an insertion query
2) Execute the query
3) Execute a 'Commit' command
4) Repeat 2 and 3 how many ever times needed
5) 'Select' part of the last 'insert'ed data to verify whether it is
accessible
6) Repeat 6 till the data is available
7) Send a TCP packet to P2 to start its 'Select' query