I wrote:
> Noah Misch writes:
>> We achieve that division of labor for XLOG_BTREE_DELETE by examining the old
>> contents before RestoreBkpBlocks(). This is safe, I think, because we only
>> examine the page when the system has running hot standby backends, and we
>> only
>> allow hot standby co
Noah Misch writes:
> On Thu, Aug 02, 2012 at 02:49:45PM -0400, Tom Lane wrote:
>> * In spgRedoVacuumRedirect, call ResolveRecoveryConflictWithSnapshot
>> with the newest-redirect XID.
> There's an obsolete comment in spg_redo().
[ squint ... ] Comparing that to btree_redo, I realize that there'
On Thu, Aug 02, 2012 at 02:49:45PM -0400, Tom Lane wrote:
> I believe that the SPGiST issue should be fixed as follows:
>
> * It's okay for transactions inserting redirection tuples to use their
> own XID as the marker.
>
> * In spgvacuum.c, the test in vacuumRedirectAndPlaceholder to decide if
>
Noah Misch writes:
> On Mon, Mar 12, 2012 at 10:50:36PM -0400, Tom Lane wrote:
>> There is one more (known) stop-ship problem in SPGiST, which I'd kind of
>> like to get out of the way now before I let my knowledge of that code
>> get swapped out again. This is that SPGiST is unsafe for use by ho
On Thu, Apr 19, 2012 at 7:55 AM, Noah Misch wrote:
> On Mon, Mar 12, 2012 at 10:50:36PM -0400, Tom Lane wrote:
>> There is one more (known) stop-ship problem in SPGiST, which I'd kind of
>> like to get out of the way now before I let my knowledge of that code
>> get swapped out again. This is tha
On Mon, Mar 12, 2012 at 10:50:36PM -0400, Tom Lane wrote:
> There is one more (known) stop-ship problem in SPGiST, which I'd kind of
> like to get out of the way now before I let my knowledge of that code
> get swapped out again. This is that SPGiST is unsafe for use by hot
> standby slaves.
I su
