|
4 | 4 | <FirstName>Phil</FirstName> |
5 | 5 | <Surname>Thompson</Surname> |
6 | 6 | </Author> |
7 | | -<Date>1998-07-13</Date> |
| 7 | +<Date>1998-08-08</Date> |
8 | 8 | </DocInfo> |
9 | 9 | <Title>Frontend/Backend Protocol</Title> |
10 | 10 |
|
@@ -389,9 +389,19 @@ The possible response messages from the backend are: |
389 | 389 |
|
390 | 390 | <Para> |
391 | 391 | A frontend must be prepared to accept ErrorResponse and NoticeResponse |
392 | | -messages whenever it is expecting any other type of message. Also, |
393 | | -if it issues any listen(l) commands then it must be prepared to accept |
394 | | -NotificationResponse messages at any time; see below. |
| 392 | +messages whenever it is expecting any other type of message. |
| 393 | + |
| 394 | +<Para> |
| 395 | +Actually, it is possible for NoticeResponse to arrive even when the frontend |
| 396 | +is not expecting any kind of message, that is, the backend is nominally idle. |
| 397 | +(In particular, the backend can be commanded to terminate by its postmaster. |
| 398 | +In that case it will send a NoticeResponse before closing the connection.) |
| 399 | +It is recommended that the frontend check for such asynchronous notices just |
| 400 | +before issuing any new command. |
| 401 | + |
| 402 | +<Para> |
| 403 | +Also, if the frontend issues any listen(l) commands then it must be prepared |
| 404 | +to accept NotificationResponse messages at any time; see below. |
395 | 405 |
|
396 | 406 |
|
397 | 407 | <Sect2> |
|