[PATCHES] ReadBuffer() error checking

AFAIK, ReadBuffer() will elog on error, so callers can assume that the buffer it returns is valid. The vast majority of ReadBuffer() call sites make this assumption, but some went to the trouble of checking that the returned buffer was valid and elog'ing if it was not. I've removed the error ch

Re: [PATCHES] PITR docs enhancements

Gavin Sherry wrote: Just some docs enhancements based on feedback I received from a few recent talks on PITR. I'll apply this to HEAD tonight or tomorrow. -Neil ---(end of broadcast)--- TIP 8: explain analyze is your friend

Re: [PATCHES] Give the TODO list a little more verbose explanation

Robert, I think there are some mistakes with your addition. Here's a reworked paragraph: --- This is a list of items which have been put to or discussed by contributors to the project. Many items have been discussed extensively on the mailing lists, the archives of which can be found here: http:/

[PATCHES] Developer's FAQ update

Hi all, An initial look at bring the developer's FAQ up to date and reworking some text to make it more useful. Thanks, Gavin# Old manifest: 2910f7d05f74e086c097595fe8cc78ad728474e4 # New manifest: f4a4fb1871edfc75efcfa80ade602e36463909f0 # Summary of changes: # # patch doc/FAQ_DEV #from

Re: [PATCHES] Give the TODO list a little more verbose explanation

This is certainly nicer than what I had. This seems to be mostly a copy/paste change, but if I need to submit a new patch lmk. Robert Treat On Saturday 13 November 2004 03:57, Gavin Sherry wrote: > Robert, > > I think there are some mistakes with your addition. Here's a reworked > paragraph: >

Re: [PATCHES] Win32 signals & sockets

Magnus Hagander wrote: If this is accepted I also plan to do a patch to split out the forkexec code into a separate file and try to clean up the dependencies a bit further. It'd be nice if I could get that into 8.0.0 (which would probably mean this beta, since it seems to be the last one), but it'

Re: [PATCHES] ReadBuffer() error checking

Neil Conway <[EMAIL PROTECTED]> writes: > AFAIK, ReadBuffer() will elog on error, so callers can assume that the > buffer it returns is valid. The vast majority of ReadBuffer() call sites > make this assumption, but some went to the trouble of checking that the > returned buffer was valid and el

Re: [PATCHES] Give the TODO list a little more verbose explanation

Gavin Sherry <[EMAIL PROTECTED]> writes: > Robert, > I think there are some mistakes with your addition. Here's a reworked > paragraph: FWIW, I like Gavin's wording better, because it makes it clearer that there's not necessarily consensus on any particular TODO item being a good idea.

Re: [PATCHES] ReadBuffer() error checking

Tom Lane wrote: Agreed. I get the impression that at one time it was not so, but certainly for the last many years there's been no need to test. Patch applied. A related issue in the same general area is that the smgr code is currently implemented to elog on error, but its API still reflects an as

Re: [PATCHES] PITR docs enhancements

Gavin Sherry wrote: Just some docs enhancements based on feedback I received from a few recent talks on PITR. Applied, with a bunch of additional fixes. -Neil ---(end of broadcast)--- TIP 8: explain analyze is your friend