Re: Checksum errors in pg_stat_database

On Fri, Apr 12, 2019 at 8:18 AM Magnus Hagander <magnus@hagander.net> wrote:
> On Sun, Apr 7, 2019 at 6:28 PM Julien Rouhaud <rjuju123@gmail.com> wrote:
>> Thanks for looking it it!
>> On Sun, Apr 7, 2019 at 4:36 PM Magnus Hagander <magnus@hagander.net> wrote:
>> >
>> > I'm not sure I like the idea of using "<shared_objects>" as the database name. It's not very likely that somebody would be using that as a name for their database, but i's not impossible. But it also just looks strrange. Wouldn't NULL be a more appropriate choice?
>> >
>> > Likewise, shouldn't we return NULL as the number of backends for the shared counters, rather than 0?
>> I wanted to make things more POLA-compliant, but maybe it was a bad
>> idea.  I changed it for NULL here and for numbackends.
>>

ISTM the argument here is go with zero since you have zero connections
vs go with null since you can't actually connect, so it doesn't make
sense. (There is a third argument about making it -1 since you can't
connect, but that breaks sum(numbackends) so it's easily dismissed.) I
think I would have gone for 0 personally, but what ended up surprising
me was that a bunch of other stuff like xact_commit show zero when
AFAICT the above reasoning would apply the same to those columns.
(unless there is a way to commit a transaction in the global objects
that I don't know about).

>> > Micro-nit:
>> > +     <entry>Time at which the last data page checksum failures was detected in
>> > s/failures/failure/
>>
>> Oops.
>>
>> v5 attached.
>

What originally got me looking at this was the idea of returning -1
(or maybe null) for checksum failures for cases when checksums are not
enabled. This seems a little more complicated to set up, but seems
like it might ward off people thinking they are safe due to no
checksum error reports when they actually aren't.