Re: recovering from "found xmin ... from before relfrozenxid ..."
Ashutosh Sharma <ashu.coek88@gmail.com>
From: Ashutosh Sharma <ashu.coek88@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: "Andrey M. Borodin" <x4mmm@yandex-team.ru>,
MBeena Emerson <mbeena.emerson@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Andres Freund <andres@anarazel.de>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
Tom Lane <tgl@sss.pgh.pa.us>, Stephen Frost <sfrost@snowman.net>
Date: 2020-08-03T16:13:04Z
Lists: pgsql-hackers
On Mon, Aug 3, 2020 at 7:06 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Mon, Aug 3, 2020 at 5:05 AM Ashutosh Sharma <ashu.coek88@gmail.com> wrote:
> > Could you please explain this point once more in detail? I am not quite able to understand under what circumstances a buffer would be modified, but won't be marked as dirty or a WAL won't be written for it.
>
> Whenever this branch is taken:
>
> + if (nskippedItems == noffs)
> + goto skip_wal;
>
If the above path is taken that means none of the items in the page
got changed. As per the following if-check whenever an item in the
offnos[] array is found dead or unused, it is skipped (due to continue
statement) which means the item is neither marked dead nor it is
marked frozen. Now, if this happens for all the items in a page, then
the above condition (nskippedItems == noffs) would be true and hence
the buffer would remain unchanged, so, we don't mark such a buffer as
dirty and neither do any WAL logging for it. This is my understanding,
please let me know if I am missing something here. Thank you.
if (!ItemIdIsUsed(itemid) || ItemIdIsDead(itemid))
{
nskippedItems++;
ereport(NOTICE,
(errmsg("skipping tid (%u, %u) because it is
already marked %s",
blkno, offnos[i],
ItemIdIsDead(itemid) ? "dead" : "unused")));
continue;
}
> At this point you have already modified the page, using ItemIdSetDead,
> HeapTupleHeaderSet*, and/or directly adjusting htup->infomask. If this
> branch is taken, then MarkBufferDirty() and log_newpage_buffer() are
> skipped.
>
--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com
Commits
-
Fix wrong data table horizon computation during backend startup.
- 1c7675a7a426 14.0 landed
-
Centralize horizon determination for temp tables, fixing bug due to skew.
- 94bc27b57680 14.0 landed
-
pg_surgery: Try to stabilize regression tests.
- 0811f766fd74 14.0 landed
-
New contrib module, pg_surgery, with heap surgery functions.
- 34a947ca13e5 14.0 landed
-
Set cutoff xmin more aggressively when vacuuming a temporary table.
- a7212be8b9e0 14.0 cited
-
snapshot scalability: Don't compute global horizons while building snapshots.
- dc7420c2c927 14.0 cited
-
Introduce vacuum errcontext to display additional information.
- b61d161c1463 13.0 cited