> If you subtract recently dead from that number within the heap
> implementation, then it will no longer
> reflect non-removable tuples and the log message in the cluster
> function "found %.0f removable, %.0f nonremovable row versions" will no
> longer be correct.
Yes, that's correct. I did no
Hi Sami,
Your patch should correct the problem. However, given that this function is
part of the tableam API, I am wondering if the fix shouldn't be outside
heap's copy_for_cluster implementation? I guess it depends on the semantics
of num_tuples, but the cluster code seems to allude to interpreti
> In both cases, he recently dead tuples must be copied to the table or index,
> but
> they should not be counted towards reltuples. So, I think we need to fix this
> in
> heapam_relation_copy_for_cluster by probably subtracting
> tups_recently_dead from num_tuples ( which is the value set in
> p
> You need a concurrent transaction to recreate the situation. I am attaching
> an isolation test to show the behavior,
Thanks! That helps.
Indeed heapam_relation_copy_for_cluster and heapam_index_build_range_scan
are counting HEAPTUPLE_RECENTLY_DEAD ( tuples removed but cannot be removed )
diffe
Hi Sami,
You need a concurrent transaction to recreate the situation. I am attaching
an isolation test to show the behavior, along with its output file. I ran
it on PostgreSQL 17.4.
The test has two permutations, the first one runs on a table without an
index and the second permutation with an in
> Does this seem like a bug or is it intentional?
pg_class.reltuples/relpages are only an estimate as per documentation.
However, I cannot reproduce the situation you are talking about on HEAD.
In the below example, I create a table without indexes, then insert and
delete some rows. run vacuum to
Hi all,
I noticed a potential issue with the heap cluster code used by VACUUM FULL
and CLUSTER, but I am not sure so I thought I'd post the question to the
list.
The code in question counts the number of tuples it processes and uses that
count to update reltuples in pg_class. However, the tuple c
