Re: Re: [PATCH 3/8] Add support for a generic wal reading facility dubbed XLogReader

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Heikki Linnakangas <hlinnakangas@vmware.com>, Andres Freund <andres@2ndquadrant.com>, pgsql-hackers@postgresql.org, Robert Haas <robertmhaas@gmail.com>, Kevin Grittner <Kevin.Grittner@wicourts.gov>, Simon Riggs <simon@2ndquadrant.com>
Date: 2012-10-29T20:31:33Z
Lists: pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> I think you may have converted some malloc() calls from Andres' patch
> into palloc() -- because you have some palloc() calls which are later
> checked for NULL results, which obviously doesn't make sense.  At the
> same time, if we're going to use malloc() instead of palloc(), we need
> to check for NULL return value in XLogReaderAllocate() callers.  This
> seems easy to fix at first glance, but what is the correct response if
> it fails during StartupXLOG()?  Should we just elog(FATAL) and hope it
> never happens in practice?

Um, surely we can still let those functions use palloc?  It should
just be #define'd as pg_malloc() (ie something with an error exit)
in non-backend contexts.

			regards, tom lane


Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Move "hot" members of PGPROC into a separate PGXACT array.