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
