From: | jwieck(at)debis(dot)com (Jan Wieck) |
---|---|
To: | jwieck(at)debis(dot)com |
Cc: | maillist(at)candle(dot)pha(dot)pa(dot)us, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Bug? relpages, reltuples resets to zero |
Date: | 1998-10-23 15:29:33 |
Message-ID: | m0zWj9h-000EBPC@orion.SAPserv.Hamburg.dsh.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> I think the simple way of modifying the tuple in the page
> does not work. I found that catalog/index.c does the same for
> relpages and reltuples in UpdateStats(). Calling
> UpdateStats() after vc_updstats() as a quick hack solved the
> problem.
And now I know the way of modifying them in the buffer is the
only one to succeed. Doing it like index.c with
heap_replace() irritates vacuum itself.
Sometimes it's good to check returncodes :-).
WriteNoReleaseBuffer() (as it's name says) takes a buffer
number as argument, not a disk block number. Thus, it
returned FALSE sometimes when called to write buffer # 0.
The attdisbursion is also permanently saved on disk now. It
had the same problem.
Anyway, the fix is below.
Patch is regression tested.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck(at)debis(dot)com (Jan Wieck) #
*** vacuum.c.orig Fri Oct 23 16:47:21 1998
--- vacuum.c Fri Oct 23 16:41:56 1998
***************
*** 1792,1799 ****
--- 1792,1807 ----
/* overwrite the existing statistics in the tuple */
if (VacAttrStatsEqValid(stats))
{
+ Buffer abuffer;
+ /*
+ * We manipulate the heap tuple in the
+ * buffer, so we fetch it to get the
+ * buffer number
+ */
+ atup = heap_fetch(ad, SnapshotNow, &atup->t_ctid, &abuffer);
vc_setpagelock(ad, ItemPointerGetBlockNumber(&atup->t_ctid));
+ attp = (Form_pg_attribute) GETSTRUCT(atup);
if (stats->nonnull_cnt + stats->null_cnt == 0 ||
(stats->null_cnt <= 1 && stats->best_cnt == 1))
***************
*** 1822,1828 ****
if (selratio > 1.0)
selratio = 1.0;
attp->attdisbursion = selratio;
! WriteNoReleaseBuffer(ItemPointerGetBlockNumber(&atup->t_ctid));
/* DO PG_STATISTIC INSERTS */
--- 1830,1843 ----
if (selratio > 1.0)
selratio = 1.0;
attp->attdisbursion = selratio;
!
! /*
! * Invalidate the cache for the tuple
! * and write the buffer
! */
! RelationInvalidateHeapTuple(ad, atup);
! WriteNoReleaseBuffer(abuffer);
! ReleaseBuffer(abuffer);
/* DO PG_STATISTIC INSERTS */
***************
*** 1875,1884 ****
heap_close(sd);
}
RelationInvalidateHeapTuple(rd, rtup);
! /* XXX -- after write, should invalidate relcache in other backends */
! WriteBuffer(ItemPointerGetBlockNumber(&rtup->t_ctid));
heap_close(rd);
}
--- 1890,1904 ----
heap_close(sd);
}
+ /*
+ * Invalidate the cached pg_class tuple and
+ * write the buffer
+ */
RelationInvalidateHeapTuple(rd, rtup);
! WriteNoReleaseBuffer(buffer);
!
! ReleaseBuffer(buffer);
heap_close(rd);
}
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1998-10-23 17:02:27 | Re: [HACKERS] Bug? relpages, reltuples resets to zero |
Previous Message | Francois Machabee | 1998-10-23 14:29:46 | RE: [HACKERS] DestroyDB Patch *** Update |