Re: pg_stat_have_stats() returns true for dropped indexes (or for index creation transaction rolled back)

Hi,

On 8/31/22 9:10 AM, Kyotaro Horiguchi wrote:
> Thanks for the searching.
> +-- pg_stat_have_stats returns true for regression_slot_stats1
> +-- Its index is 1 in ReplicationSlotCtl->replication_slots
> +select pg_stat_have_stats('replslot', 0, 1);
>
> This is wrong. The index is actually 0.

Right, thanks for pointing out.

(gdb) p get_replslot_index("regression_slot_stats1")
$1 = 0
(gdb) p get_replslot_index("regression_slot_stats2")
$2 = 1
(gdb) p get_replslot_index("regression_slot_stats3")

$3 = 2

> We cannot know the id
> reliably since we don't expose it at all.

Right.

> We could slightly increase
> robustness by assuming the range of the id but that is just moving the
> problem to another place. If the test is broken by a change of
> replslot id assignment policy, it would be easily found and fixed.
>
> So is it fine simply fixing the comment with the correct ID?
>
> Or, contrarily we can be more sensitive to the change of ID assignment
> policy by checking all the replication slots.
>
> select count(n) from generate_series(0, 2) as n where pg_stat_have_stats('replslot', 0, n);
>
> The number changes from 3 to 0 across the slots drop.. If any of the
> slots has gone out of the range, the number before the drop decreases.

Thanks for the ideas! I'm coming up with a slightly different one (also
based on Andre's feedback in [1]) in the upcoming v4.

[1]:
https://www.postgresql.org/message-id/20220831192657.jqhphpud2mxbzbom%40awork3.anarazel.de

Regards,

--
Bertrand Drouvot
Amazon Web Services:https://aws.amazon.com