Re: Questions regarding notify processing.

I realize that I'm carrying on a conversation with myself here; however,
nothing new 'bout that, I do it all the time ;o)

Just in case anyone else is interested, the only way I can get this to work
correctly is to put a 100 millisecond timer in front of the call to
CheckForNotifies as in:
XtAppAddTimeOut (app, 100,
(XtTimerCallbackProc) CheckForNotifies, (XtPointer) ctrl);
Now the 1/10 second timer, on my notebook with 1.2 gigs of ram and a 1700 MHz
processor, works just fine for now; however, when this app rolls out into the
real world with 100 users pounding on it, will 1/10 of a second still be long
enough? And, why does it have to be there at all?

Points to ponder, or not...

On Friday 25 February 2005 01:05 pm, Terry Lee Tucker saith:
> This thing is hanging up in PQnotifies. I have added a simple fprintf
> statement to the following function:
> void CheckForNotifies (Controls *ctrl)
> {
> #ifndef CALL_TRACE
> fprintf (stderr, "%s: %d: %s (%s)\n", __FILE__, __LINE__,
> __FUNCTION__, ctrl->table);
> #endif
>
> PQflush (ctrl->sys->conn); // always flush it first ;o)
>
> PQconsumeInput (ctrl->sys->conn);
> fprintf (stderr, "just before call to PQnotifies...\n");
> while ((ctrl->notify = PQnotifies (ctrl->sys->conn)) != NULL)
> {
> #ifndef DEBUG
> fprintf (stderr,
> "%s: ASYNC NOTIFY of '%s' from backend pid '%d' received\n",
> __FUNCTION__, ctrl->notify->relname,
> ctrl->notify->be_pid);
> #endif
> /* If you are interested in receiving any NOTICE data, you will
> * have to have this function defined locally. */
> if (ctrl->main->backEndNotify)
> {
> void (*p) () = (void *) ctrl->main->backEndNotify;
> (*p) (ctrl); // call the function
> }
> PQfreemem (ctrl->notify); // free the memory
> }
> }
> The fprintf statement prints and nothing else happens. Observe:
> move/move.c: 2072: preMenuActFunc (move::save_b)
> move/move.c: 2718: save_SQL ()
> move/move.c: 2798: save_SQL ()
> move/move.c: 2816: restoreState ()
> utility/global.c: 1804: CheckForNotifies (move)
> just before call to PQnotifies...
>
> And that is where it sits until I send a message notification from a
> separate client (plsql). When the message is sent, the process continues.
> Is this a bug? Did anybody look at the stack trace is sent? I don't have
> the expertise to analyze it.
>
> TIA
>
> On Friday 25 February 2005 06:00 am, Terry Lee Tucker saith:
> > See partial output from strace below. On this particular run, the command
> > locked up during the second edit operation. The notify message,
> > move_update, was delivered, but the PQsendquery never returns.
> >
> > Any ideas Tom?
> >
> > recv(3, "A\0\0\0\25\0\0~3move_update\0\0C\0\0\0\rUPDAT"..., 16384, 0) =
> > 42 write(2, "CheckForNotifies: ASYNC NOTIFY o"..., 82CheckForNotifies:
> > ASYNC NOTIFY of 'move_update' from backend pid '32307' received
> > ) = 82
> > write(2, "main/main.c: 1638: backEndNotify"..., 54main/main.c: 1638:
> > backEndNotify (32307: move_update)
> > ) = 54
> > write(2, "main/main.c: 1655: backEndNotify"..., 43main/main.c: 1655:
> > backEndNotify (leaving)
> > ) = 43
> > select(5, [3], [], [], {0, 0}) = 0 (Timeout)
> > select(5, [3], [], [], {0, 0}) = 0 (Timeout)
> > select(5, [3], [], [], {0, 0}) = 0 (Timeout)
> > select(5, [3], [], [], {0, 0}) = 0 (Timeout)
> > select(5, [3], [], [], {0, 0}) = 0 (Timeout)
> > select(5, [3], [], [], {0, 0}) = 0 (Timeout)
> > select(5, [3], [], [], {0, 0}) = 0 (Timeout)
> > select(5, [3], [], [], {0, 0}) = 0 (Timeout)
> > select(5, [3], [], [], {0, 0}) = 0 (Timeout)
> > select(5, [3], [], [], {0, 0}) = 0 (Timeout)
> > select(5, [3], [], [], {0, 0}) = 0 (Timeout)
> > select(5, [3], [], [], {0, 0}) = 0 (Timeout)
> > select(5, [3], [], [], {0, 0}) = 0 (Timeout)
> > select(5, [3], [], [], {0, 0}) = 0 (Timeout)
> > select(5, [3], [], [], {0, 0}) = 0 (Timeout)
> > select(5, [3], [], [], {0, 0}) = 0 (Timeout)
> > select(5, [3], [], [], {0, 0}) = 0 (Timeout)
> > ioctl(4, FIONREAD, [32]) = 0
> > read(4, "\34\364_\264\311\4\300\7<\1\0\0\304\243G\22\0\0\0\0\304"..., 32)
> > = 32 select(5, [3], [], [], {0, 0}) = 0 (Timeout)
> > ioctl(4, FIONREAD, [32]) = 0
> > read(4, "\34\364_\264\311\4\300\7\f\1\0\0\305\243G\22\0\4\300\7"..., 32)
> > = 32 select(5, [3], [], [], {0, 0}) = 0 (Timeout)
> > ioctl(4, FIONREAD, [384]) = 0
> > read(4, "\34\364_\264\311\4\300\7\365\0\0\0\306\243G\22\0\0\0\0"..., 384)
> > = 384
> > select(5, [3], [], [], {0, 0}) = 0 (Timeout)
> > select(5, [3], [], [], {0, 0}) = 0 (Timeout)
> > select(5, [3], [], [], {0, 0}) = 0 (Timeout)
> > select(5, [3], [], [], {0, 0}) = 0 (Timeout)
> > select(5, [3], [], [], {0, 0}) = 0 (Timeout)
> > ioctl(4, FIONREAD, [32]) = 0
> > read(4, "\226\252_\264\311\4\300\7\311\4\300\7\0\0\0\0\370\0\177"..., 32)
> > = 32 write(4, "\2\2\4\0\314\4\300\7\0\10\0\0}\240 \0", 16) = 16
> > select(5, [3], [], [], {0, 0}) = 0 (Timeout)
> > select(5, [3], [], [], {0, 0}) = 0 (Timeout)
> > select(5, [3], [], [], {0, 0}) = 0 (Timeout)
> > select(5, [3], [], [], {0, 0}) = 0 (Timeout)
> > select(5, [3], [], [], {0, 0}) = 0 (Timeout)
> > select(5, [3], [], [], {0, 0}) = 0 (Timeout)
> > write(4, "8\2\4\0\32\0\300\7\0\0\10\0\0\0\0\0>\5\7\0\312\4\300\7"...,
> > 500) = 500
> > read(4, 0xbffff040, 32) = -1 EAGAIN (Resource temporarily
> > unavailable)
> > select(5, [4], NULL, NULL, NULL) = 1 (in [4])
> > read(4, "\1\1t\264\0\0\0\0\304\364\3\1\370\0\177\1\320\2460\t`\347"...,
> > 32) = 32
> > write(4, "\17\2\2\0\314\4\300\7", 8) = 8
> > read(4, 0xbffff120, 32) = -1 EAGAIN (Resource temporarily
> > unavailable)
> > select(5, [4], NULL, NULL, NULL) = 1 (in [4])
> > read(4, "\1ku\264\0\0\0\0\257\0\0\0\311\4\300\7\0\0\0\0\0\0\0\0"..., 32)
> > = 32 write(4,
> > "B\2\7\0\314\4\300\7\24\0\300\7\256\0(at)\0\3\1@\0\256\0A\0"..., 64) = 64
> > read(4, 0xbffff0b0, 32) = -1 EAGAIN (Resource temporarily
> > unavailable)
> > select(5, [4], NULL, NULL, NULL) = 1 (in [4])
> > read(4, "\1tx\264\0\0\0\0\257\0\0\0\311\4\300\7\0\0;\t\260\267\343"...,
> > 32) = 32
> > select(5, [3], [], [], {0, 0}) = 0 (Timeout)
> > select(5, [3], [], [], {0, 0}) = 0 (Timeout)
> > ioctl(4, FIONREAD, [0]) = 0
> > write(4, "F\2\v\0\314\4\300\7\r\0\300\7\252\0<\0^\0\2\0\252\0j\0"..., 44)
> > = 44 ioctl(4, FIONREAD, [0]) = 0
> > gettimeofday({1109328767, 349228}, NULL) = 0
> > select(5, [3 4], [], [], NULL) = 1 (in [4])
> > ioctl(4, FIONREAD, [32]) = 0
> > read(4, "\36\203y\264\0\0\0\0\247\3\300\7]\1`\1\1\0\0\0^\1\0\0%"..., 32)
> > = 32 write(4, "\24\0\6\0]\1`\1%\1\0\0\0\0\0\0\0\0\0\0\200\226\230\0", 24)
> > = 24 read(4, 0xbffff2f0, 32) = -1 EAGAIN (Resource
> > temporarily unavailable)
> > select(5, [4], NULL, NULL, NULL) = 1 (in [4])
> > read(4, "\1\0z\264\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 32)
> > = 32 write(4, "+\0\1\0", 4) = 4
> > read(4, 0xbffff2e0, 32) = -1 EAGAIN (Resource temporarily
> > unavailable)
> > select(5, [4], NULL, NULL, NULL) = 1 (in [4])
> > read(4, "\1\1{\264\0\0\0\0\311\4\300\7\0\0\0\0\1\0\0\0\2\0\0\0@"..., 32)
> > = 32 write(4, "\22\0\25\0]\1`\1%\1\0\0\4\0\0\0
> > \0\0\0\17\0\0\0^\1\0\0"..., 132) = 132
> > read(4, 0xbffff440, 32) = -1 EAGAIN (Resource temporarily
> > unavailable)
> > select(5, [4], NULL, NULL, NULL) = 1 (in [4])
> > read(4, "\1\1~\264\0\0\0\0\311\4\300\7\0\0\0\0\0\0\0\0\2\0\0\0@"..., 32)
> > = 32 select(5, [3], [], [], {0, 0}) = 0 (Timeout)
> > ioctl(4, FIONREAD, [0]) = 0
> > ioctl(4, FIONREAD, [0]) = 0
> > gettimeofday({1109328768, 129317}, NULL) = 0
> > select(5, [3 4], [], [], NULL) = 1 (in [4])
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.