On Wed, Jul 24, 2019 at 2:45 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Thu, Jul 18, 2019 at 5:10 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Mon, Jul 1, 2019 at 1:24 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> > > Yep, that was completely wrong. Here's a new version.
>
> 10.
> I think UndoLogAllocate can leak allocation of slots. It first
> allocates the slot for a new log from the free pool in there is no
> existing slot/log, writes a WAL record and then at a later point of
> time it actually creates the required physical space in the log via
> extend_undo_log which also writes a separate WAL. Now, if there is a
> error between these two operations, then we will have a redundant slot
> allocated. What if there are repeated errors for similar thing from
> multiple backends after which system crashes. Now, after restart, we
> will allocate multiple slots for different lognos which don't have any
> actual (physical) logs. This might not be a big problem in practice
> because the chances of error between two operations are less, but
> can't we delay the WAL logging for allocation of a slot for a new log.
>
After sending this email, I was browsing the previous comments raised
by me for this patch and it seems this same point was raised
previously [1] as well and there were few additional questions related
to same (See point-1 in email [1].)
[1] - https://www.postgresql.org/message-id/CAA4eK1LDctrYeZ8ev1N1v-8KwiigAmNMx%3Dt-UTs9qgEFt%2BP0XQ%40mail.gmail.com
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
