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 →
-
Move "hot" members of PGPROC into a separate PGXACT array.
- ed0b409d2234 9.2.0 cited