8
netikras
310d

wtf...

Ones of the best bugs I love the "most" are the ones where the fix is counter-intuitive, e.g. making smth seemingly incorrect to rectify the issue.

Like today, I crafter an SQL query to fetch some PG metrics. And postgres-exporter refused to accept it until I added an excessive comma [,] at the end of the SELECT block (right before FROM).

Like.. wtf...

Comments
  • 4
    This sounds like treating the symptoms rather than fixing the root cause 😄
  • 4
    @Lensflare feels like that too
  • 2
    Look up the source code.

    Probably the query gets additional fields appended or stuff like that.

    If I remember correctly, PostgreSQL exporter removed the custom queries yaml yuckity and replaced it by collectors.

    Hadn't had a chance to look at the collectors, but I hated the Yaml part.

    Yaml bad.
  • 2
    better pray that that version of PostgreSQL doesn't go out of date or discontinued.

    If I were you, I would start looking for an actual solution after doing the hacky one.
  • 2
    @Sid2006 I agree.

    Later... 😁
  • 5
    Write a test that documents that shit so when it breaks when you change PG versions it does too so you aren't chasing ghosts all week
  • 2
    @MammaNeedHummus tests for monitoring...? Meeh 😁 Imma be out of this project before pg changes 😁
  • 4
    @netikras goes around comes around 😁🫠
  • 3
    @MammaNeedHummus @IntrusionCM

    Found it!

    Turns out, it was my fault (as expected!). Adding that comma did not make it work - the exporter was erroring into a separate stream, so I did not see the errors. And that particular query was excluded from the effective configuration.

    Turns out, all the selected rows must be unique to each other. Actually, all the labels' sets must be unique within the resultset.

    I was selecting query text along with some metrics, but I failed to notice that the same query text could be executed against several DBs, by several users, which would yield duplicate rows. Moreover, the same query text in the same DB ran by the same user might have several different query IDs, making even more dupes.

    Adding more labels making the selected row's labels unique in the resultset was the fix.

    [maybe someone else will have this problem and google will throw this dR post at them. Let's make dR the new SO! :D ]
  • 2
    @netikras No please don't make dR the new SO.

    We want to rant and spew bullshit about our managers/employers. The world is already full of idiots who don't know how to add a foreign key to a table.
  • 2
    If you ask me, languages should mandate a trailing comma in every list, not just allow, mandate it. This way every item is the same, you have <item description> <comma> for every item, and adding a item or removing one always adds or removes exactly one comma. It is also good for list where you have one item per line, every line ends with a comma. No item or a empty list means no comma.

    It is just cleaner. Textfiles are the same, all lines end with a '\n', including the last one.
  • 2
    @netikras document that shit 😁

    Congrats on the fix
Add Comment