Thread: Dropped connection during COPY causes trouble
Don't kill a psql client that's in the middle of a COPY IN operation. With current sources, the connected backend fails to quit, but instead goes into an infinite loop writing pq_recvbuf: unexpected EOF on client connection to stderr over and over. If you have postmaster stderr directed to a disk file, as I believe is standard procedure, by and by the disk the postmaster logfile is on fills up, and people start getting very unhappy... I assume this is fairly easily fixed, but do not have a fix right this instant. It's probably my fault though --- I suppose it is an artifact of the changes I made a couple months ago to prevent NOTICE messages from coming out at inopportune times. (If the bug were in pre-6.5 releases I'm sure we'd have heard about it before.) Will produce a back-patch for 6.5 when I have it, but wanted to give people a heads-up now. Most embarrassing. BTW, it occurs to me that the system ought to have provisions for limiting the size of the logfile, rotating logfiles from time to time, etc ... right now you cannot do those things easily except by restarting the postmaster :-(. Even without this bug, a determined attacker could create a DOS attack by doing EXPLAIN VERBOSE enough times to run the postmaster logfile up to full disk. Bruce, I think we need another TODO item: * prevent postmaster logfile from growing without bound regards, tom lane
> > BTW, it occurs to me that the system ought to have provisions for > limiting the size of the logfile, rotating logfiles from time to > time, etc ... right now you cannot do those things easily except > by restarting the postmaster :-(. Even without this bug, a determined > attacker could create a DOS attack by doing EXPLAIN VERBOSE enough > times to run the postmaster logfile up to full disk. Bruce, I think > we need another TODO item: > * prevent postmaster logfile from growing without bound Not sure this really is a PostgreSQL issue. Other OS systems have this problem too. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On 22-Jul-99 Bruce Momjian wrote: >> >> BTW, it occurs to me that the system ought to have provisions for >> limiting the size of the logfile, rotating logfiles from time to >> time, etc ... right now you cannot do those things easily except >> by restarting the postmaster :-(. Even without this bug, a determined >> attacker could create a DOS attack by doing EXPLAIN VERBOSE enough >> times to run the postmaster logfile up to full disk. Bruce, I think >> we need another TODO item: >> * prevent postmaster logfile from growing without bound > > Not sure this really is a PostgreSQL issue. Other OS systems have this > problem too. I've seen these complaints on other lists for other programs (mail, news, web, etc...). IMO it's more of an administration issue than an OS issue or even something for the program filling it. The admin needs to know what's running on his/her system and how to handle the logs (and the rotating of) accordingly. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null # include <std/disclaimers.h> TEAM-OS2 Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
At 09:48 PM 7/21/99 -0400, Vince Vielhaber wrote: >I've seen these complaints on other lists for other programs (mail, news, >web, etc...). IMO it's more of an administration issue than an OS issue >or even something for the program filling it. The admin needs to know >what's running on his/her system and how to handle the logs (and the >rotating of) accordingly. Well, there are programs that allow automatic rotating of logs, of course. AOLserver - the webserver I use with Postgres - is one example. I think I can limit the size of a log, too, but would have to check. It seems like a useful feature for any 24/7 service. - Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, and other goodies at http://donb.photo.net