Does logging work as desired if you add this new configuration to extraConfig instead of the changes you made here?

@aanderse
Yes:

https://github.com/jappeace/linux-config/blob/work-machine/configuration.nix#L367

Thanks for answering. Two things:

• I don't think you need to change log_destination, but I'm not sure.
• Isn't the name enableSystemLogging misleading? All logging is too the system log (journald) already. I would also think that people might want to only turn a few of these options on instead of all sometimes. Maybe an attribute set representing the configuration file would make the situation better here.

I don't think you need to change log_destination, but I'm not sure.

Default behavior appears to be logging to some file in /var/lib/postgresql/PG_VERSION/log. Enabling syslog will put everything into journalctl on a systemd machine. postgres predates system wide logging schemes so it make sense the default would be a file.

I would also think that people might want to only turn a few of these options on instead of all sometimes

Probably yeah. Especially log_statement all may not always be desirable for larger apps.

Maybe an attribute set representing the configuration file would make the situation better here.

So you mean a configuration option per postgres option nested within something called logging? Yeah I can rework it into that.

Actually I think that writing of files into /var/lib/postgresql/PG_VERSION/log is because of the logging collector. I'm not sure what happens to stderr.

Actually I think that writing of files into /var/lib/postgresql/PG_VERSION/log is because of the logging collector. I'm not sure what happens to stderr.

I believe stderr is be redirected to journald.

So you mean a configuration option per postgres option nested within something called logging? Yeah I can rework it into that.

What about something like this?

Maybe that didn't work because I still had the log collector enabled? Wait I'll try again

Yeah it was that, so enabling the logging collector will capture the stderr, and then if you enable syslog you get both files and syslog output. The advantage being that logging collector will never drop a message (at a small risk of freezing the system if it's unable to write for some reason).

@jappeace what about something like this?

@aanderse I just saw yeah, but I didn't want to break backward compatibility, and I also like having the types, there are several fields which are simply weird booleans or enums. But you're right, it's pretty much a one to one mapping.

@aanderse I just saw yeah, but I didn't want to break backward compatibility, and I also like having the types, there are several fields which are simply weird booleans or enums. But you're right, it's pretty much a one to one mapping.

The problem with applying type checking to less commonly used configuration values (ie. making them options) is that you end up replicating the entire configuration file eventually. See NixOS/rfcs#42 for an interesting discussion on the pros and cons of options vs a single settings option (for less common configuration). This RFC is likely to become the recommendation to module authors going forward.

@aanderse Okay, I see, so module size appears to be a big problem (I thought it was the opposite, more = better). These logging options then shouldn't be added as separate options but as in your suggestion. You should make a PR for that.