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 <mag...@hagander.net> wrote: > On Sun, Apr 7, 2019 at 6:28 PM Julien Rouhaud <rjuju...@gmail.com> wrote: >> Thanks for looking it it! >> On Sun, Apr 7, 2019 at 4:36 PM Magnus Hagander <mag...@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. Robert Treat https://xzilla.net