Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by hub.org (8.8.8/8.8.8) with ESMTP id WAA18585 for ; Mon, 5 Oct 1998 22:50:29 -0400 (EDT) (envelope-from tgl@sss.pgh.pa.us) Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id WAA05434; Mon, 5 Oct 1998 22:49:36 -0400 (EDT) To: "Marc G. Fournier" cc: PostgreSQL-development Subject: Re: [HACKERS] Open 6.4 items In-reply-to: Your message of Mon, 5 Oct 1998 14:29:41 -0400 (EDT) Date: Mon, 05 Oct 1998 22:49:36 -0400 Message-ID: <5432.907642176@sss.pgh.pa.us> From: Tom Lane "Marc G. Fournier" writes: >> I can commit those changes tonight if I have the go-ahead. Or I can >> wait till post-6.4. Your call. > Go for it...that will at least get them off the list... OK, the NOTIFY rewrite is checked in. We'll see what breaks, if anything. >> flock is a release stopper as far as I'm concerned, because the backend >> *does not compile* on my platform without diking out that code. Actually, it looks like Vadim replaced the flock() call with fcntl() a few weeks ago, and I'd not noticed because I had a locally modified copy of pqcomm.c. I don't know if fcntl(F_SETLK) is any more portable than flock() --- it compiles on my platform, where flock() didn't, but that proves little. So I went ahead and put in an autoconf test, only checking for fcntl(F_SETLK) rather than flock(). I still think the process-pid-in-a-textfile approach to locking is safer, but we can leave that for the next release. That's two items off the must-fix list and onto the are-there-bugs? list... regards, tom lane