Re: Inadequate thought about buffer locking during hot standby replay
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Simon Riggs <simon@2ndquadrant.com>, pgsql-hackers@postgresql.org
Date: 2012-11-12T15:42:10Z
Lists: pgsql-hackers
On 2012-11-12 10:19:09 -0500, Tom Lane wrote: > Andres Freund <andres@2ndquadrant.com> writes: > > On 2012-11-10 16:24:22 -0500, Tom Lane wrote: > >> If any of this stuff were getting used by external modules, changing it > >> would be problematic ... but fortunately, it isn't, because we lack > >> support for plug-in rmgrs. So I'm not worried about back-patching the > >> change, and would prefer to keep the 9.x branches in sync. > > > XLR_BKP_BLOCK_* might be used by things like pg_lesslog and its surely > > used by xlogdump. Not sure if either are worth that much attention, but > > it seems worth noticing that such a change will break stuff. > > Hm. Okay, how about we leave the old macros in place in the back > branches? Sounds good to me. The RestoreBkpBlocks change seems unproblematic to me. If anything its good that it has been renamed. Thanks, Andres
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Rewrite the GiST insertion logic so that we don't need the post-recovery
- 9de3aa65f01f 9.1.0 cited