Re: Inadequate thought about buffer locking during hot standby replay
Gavin Flower <gavinflower@archidevsys.co.nz>
From: Gavin Flower <GavinFlower@archidevsys.co.nz>
To: Merlin Moncure <mmoncure@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
Heikki Linnakangas <hlinnakangas@vmware.com>, pgsql-hackers@postgresql.org
Date: 2012-11-13T18:23:38Z
Lists: pgsql-hackers
On 14/11/12 04:32, Merlin Moncure wrote: > On Tue, Nov 13, 2012 at 9:03 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Ok. It won't help all that much on 9.0, though. >> Well, it won't help GIST much, but the actually-reported-from-the-field >> case is in btree, and it does fix that. >> >> It occurs to me that if we're sufficiently scared of this case, we could >> probably hack the planner (in 9.0 only) to refuse to use GIST indexes >> in hot-standby queries. That cure might be worse than the disease though. > if anything, it should be documented. if you do this kind of thing > people will stop installing bugfix releases. > > merlin > > How about displaying a warning, when people try to use the 'feature', as well as document it? Cheers, Gavin
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