On Tue, Aug 13, 2019 at 6:28 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> So, for top-level transactions rollback, we can directly refer from
> UndoRequest *, the start and end locations. But, what should we do
> for sub-transactions (rollback to savepoint)? One related point is
> that we also need information about last_log_start_undo_location to
> update the undo apply progress (The basic idea is if the transactions
> undo is spanned across multiple logs, we update the progress in each
> of the logs.). We can remember that in the transaction state or
> undorequest *. Any suggestion?
The UndoRequest is only for top-level rollback. Any state that you
need in order to do subtransaction rollback needs to be maintained
someplace else, probably in the transaction state state, or some
subsidiary data structure. The point here is that the UndoRequest is
going to be stored in shared memory, but there is no reason ever to
store the information about a subtransaction in shared memory, because
that undo always has to be completed by the backend that is
responsible for that transaction. Those things should not get mixed
together.
> IIUC, for each transaction, we have to take a lock first time it
> attaches to a log and then the same lock at commit time. It seems the
> work under lock is less, but still, can't this cause a contention? It
> seems to me this is similar to what we saw in ProcArrayLock where work
> under lock was few instructions, but acquiring and releasing the lock
> by each backend at commit time was causing a bottleneck.
LWLocks are pretty fast these days and the critical section is pretty
short, so I think there's a chance it'll be just fine, but maybe it'll
cause enough cache line bouncing to be problematic. If so, I think
there are several possible ways to redesign the locking to improve
things, but it made sense to me to try the simple approach first.
> How will computation of oldestXidHavingUnappliedUndo will work?
>
> We can probably check the fxid queue and error queue to get that
> value. However, I am not sure if that is sufficient because incase we
> perform the request in the foreground, it won't be present in queues.
Oh, I forgot about that requirement. I think I can fix it so it does
that fairly easily, but it will require a little bit of redesign which
I won't have time to do this week.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company