On Thu, Jul 25, 2019 at 3:10 PM Andres Freund wrote:
> > I agree that this is unfortunate. Are you planning on working on it?
>
> Not at the moment, no. Are you planning / hoping to take a stab at it?
The current behavior ought to be fixed, and it seems like it falls to
me to do that. OTOH,
Hi,
On 2019-07-24 17:14:39 -0700, Peter Geoghegan wrote:
> On Wed, Jul 24, 2019 at 4:24 PM Andres Freund wrote:
> > but we really don't need to do any of that in this case - the only
> > locker is the current backend, after all.
> >
> > I think this isn't great, because it'll later will cause
On Wed, Jul 24, 2019 at 4:24 PM Andres Freund wrote:
> as you can see the same xmax is set for both row version, with the new
> infomask being HEAP_XMAX_KEYSHR_LOCK | HEAP_XMAX_LOCK_ONLY | HEAP_UPDATED.
Meta remark about your test case: I am a big fan of microbenchmarks
like this, which execute
