Re: POC: Cleaning up orphaned files using undo logs

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: POC: Cleaning up orphaned files using undo logs
Date: 2019-08-09 08:21:04
Message-ID: CAA4eK1+McY0qGaak0AHyzdgAn+F6dyxcpDwp9ifGg=1WVDadeQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jul 22, 2019 at 3:51 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> On Mon, Jul 22, 2019 at 2:21 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
>
> I have reviewed 0012-Infrastructure-to-execute-pending-undo-actions,
> Please find my comment so far.
>
> 1.
> + /* It shouldn't be discarded. */
> + Assert(!UndoRecPtrIsDiscarded(xact_urp));
>
> I think comments can be added to explain why it shouldn't be discarded.
>
> 2.
> + /* Compute the offset of the uur_next in the undo record. */
> + offset = SizeOfUndoRecordHeader +
> + offsetof(UndoRecordTransaction, urec_progress);
> +
> in comment /uur_next/uur_progress
>
> 3.
> +/*
> + * undo_record_comparator
> + *
> + * qsort comparator to handle undo record for applying undo actions of the
> + * transaction.
> + */
> Function header formating is not in sync with other functions.
>

Fixed all the above comments in the attached patch.

> 4.
> +void
> +undoaction_redo(XLogReaderState *record)
> +{
> + uint8 info = XLogRecGetInfo(record) & ~XLR_INFO_MASK;
> +
> + switch (info)
> + {
> + case XLOG_UNDO_APPLY_PROGRESS:
> + undo_xlog_apply_progress(record);
> + break;
>
> For HotStandby it doesn't make sense to apply this wal as this
> progress is only required when we try to apply the undo action after
> restart
> but in HotStandby we never apply undo actions.
>

I have already responded in my earlier email on why this is required [1].

> 5.
> + Assert(from_urecptr != InvalidUndoRecPtr);
> + Assert(to_urecptr != InvalidUndoRecPtr);
>
> we can use macros UndoRecPtrIsValid instead of checking like this.
>

Fixed.

> 6.
> + if ((slot == NULL) || (UndoRecPtrGetLogNo(urecptr) != slot->logno))
> + slot = UndoLogGetSlot(UndoRecPtrGetLogNo(urecptr), false);
> +
> + Assert(slot != NULL);
> We are passing missing_ok as false in UndoLogGetSlot. But, not sure
> why we are expecting that undo lot can not be dropped. In multi-log
> transaction it's possible
> that the tablespace in which next undolog is there is already dropped?
>

Already responded on this in my earlier reply [1].

> 7.
> + */
> + do
> + {
> + BlockNumber progress_block_num = InvalidBlockNumber;
> + int i;
> + int nrecords;
> .....
> + */
> + if (!UndoRecPtrIsValid(urec_ptr))
> + break;
> + } while (true);
>
> I think we can convert above loop to while(true) instead of do..while,
> because there is no need for do while loop.
>
> 8.
> + if (last_urecinfo->uur->uur_info & UREC_INFO_LOGSWITCH)
> + {
> + UndoRecordLogSwitch *logswitch = last_urecinfo->uur->uur_logswitch;
>
> IMHO, the caller of UndoFetchRecord should directly check
> uur->uur_logswitch instead of uur_info & UREC_INFO_LOGSWITCH.
> Actually, uur_info is internally set
> for inserting the tuple and check there to know what to insert and
> fetch but I think caller of UndoFetchRecord should directly rely on
> the field because ideally all
> the fields in UnpackUndoRecord must be set and uur_txt or
> uur_logswitch will be allocated when those headers present. I think
> this needs to be improved in undo interface patch
> as well (in UndoBulkFetchRecord).
>

Okay, fixed both of the above. I have exposed a new macro
IsUndoLogSwitched from undorecord.h which you might also want to use
in your patch.

Apart from this, in the attached patches, I have fixed various
comments raised in this thread from Amit Khandekar. I'll respond to
them separately. I have yet to address various comments raised by
Andres and Robert which also includes integration with the latest
patch on queues posted by Robert.

Note - The patches for undo-log and undo-interface has not been
rebased as others are working actively on their branches. The branch
where this code resides can be accessed at
https://github.com/EnterpriseDB/zheap/tree/undoprocessing

[1] - https://www.postgresql.org/message-id/CAA4eK1KoA0L%3DPNBc_uu2v8H0%3DLA_Cm%3Do9GyFm6i6DSD6mUMppg%40mail.gmail.com

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

Attachment Content-Type Size
0001-Move-some-md.c-specific-logic-from-smgr.c-to-md.c.patch application/octet-stream 7.7 KB
0002-Prepare-to-support-multiple-SMGR-implementations.patch application/octet-stream 1.4 KB
0003-Add-undo-log-manager.patch application/octet-stream 177.2 KB
0004-Allow-WAL-record-data-on-first-modification-after-a-.patch application/octet-stream 2.1 KB
0005-Add-prefetch-support-for-the-undo-log.patch application/octet-stream 7.9 KB
0006-Defect-and-enhancement-in-multi-log-support.patch application/octet-stream 4.2 KB
0007-Provide-interfaces-to-store-and-fetch-undo-records.patch application/octet-stream 111.1 KB
0008-undo-page-consistency-checker.patch application/octet-stream 4.4 KB
0009-Extend-binary-heap-functionality.patch application/octet-stream 5.3 KB
0010-Infrastructure-to-register-and-fetch-undo-action-req.patch application/octet-stream 66.8 KB
0011-Infrastructure-to-execute-pending-undo-actions.patch application/octet-stream 38.7 KB
0012-Allow-foreground-transactions-to-perform-undo-action.patch application/octet-stream 51.7 KB
0013-Allow-execution-and-discard-of-undo-by-background-wo.patch application/octet-stream 93.3 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dmitry Igrishin 2019-08-09 08:21:52 Re: Small patch to fix build on Windows
Previous Message Amit Langote 2019-08-09 07:29:48 Re: Problem with default partition pruning