On Wed, Jul 24, 2019 at 2:45 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Thu, Jul 18, 2019 at 5:10 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > On Mon, Jul 1, 2019 at 1:24 PM Thomas Munro <thomas.mu...@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
