Hi!
On Thu, Aug 9, 2018 at 11:26 PM Ivan Kartyshov
<i.kartyshov@postgrespro.ru> wrote:
> Alexander Korotkov писал 2018-06-20 20:54:
> > Thinking about that more I found that adding vacuum mark as an extra
> > argument to LockAcquireExtended is also wrong. It would be still hard
> > to determine if we should log the lock in LogStandbySnapshot(). We'll
> > have to add that flag to shared memory table of locks. And that looks
> > like a kludge.
> >
> > Therefore, I'd like to propose another approach: introduce new lock
> > level. So, AccessExclusiveLock will be split into two
> > AccessExclusiveLocalLock and AccessExclusiveLock. In spite of
> > AccessExclusiveLock, AccessExclusiveLocalLock will be not logged to
> > standby, and used for heap truncation.
> >
> > I expect some resistance to my proposal, because fixing this "small
> > bug" doesn't deserve new lock level. But current behavior of
> > hot_standby_feedback is buggy. From user prospective,
> > hot_standby_feedback option is just non-worker, which causes master to
> > bloat without protection for standby queries from cancel. We need to
> > fix that, but I don't see other proper way to do that except adding
> > new lock level...
>
> Your offer is very interesting, it made patch smaller and more
> beautiful.
> So I update patch and made changes accordance with the proposed concept
> of
> special AccessExclusiveLocalLock.
> I would like to here you opinion over this implementation.
In general this patch looks good for me. It seems that comments and
documentation need minor enhancements. I'll make them and post the
revised patch.
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company