Re: Checksum errors in pg_stat_database

I started looking at this the other night but I see Magnus beat me in
committing it...

On Fri, Apr 12, 2019 at 8:18 AM Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Sun, Apr 7, 2019 at 6:28 PM Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
>> Thanks for looking it it!
>> On Sun, Apr 7, 2019 at 4:36 PM Magnus Hagander <magnus(at)hagander(dot)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.

Robert Treat
https://xzilla.net