pgenv: get to know your logs
In these days a work of mine, related to PostgreSQL, is going to be tested. One quick way to get a fully functional PostgreSQL instance is to usepgenv.
However, one user asked me how to find out quickly the problem why
pgenv was unable to start his own cluster.
Do your homework and read the logs! is the correct answer to the problem.
The you realize that part of your aim is to help people embracing the technology, so why should not
pgenv try to teach the user to do so?
And here are two very small and ridiculous features that could help some user to get used to learn the basis of every problem solving, especially with PostgreSQL.
A quick look at the logs when things go wrong
The first problem is that when the cluster does not start, for any reason,pgenv correctly tells you to examine the logs.
End of the story.
That means that you have to mangle your logs thru your own favourite tool, even if you are an experienced database and system administrator. I’m lazy, so let’s
pgenv provide me a quick hint:
% pgenv start
PostgreSQL 12.1 NOT started, examine logs in /home/luca/git/misc/PostgreSQL/pgenv/pgsql/data/server.log
Following are the last 5 lines of the log, as a quick hint:
2020-08-28 03:29:39.343 CEST [13046] LOG: could not bind IPv4 address "127.0.0.1": Address already in use
2020-08-28 03:29:39.343 CEST [13046] HINT: Is another postmaster already running on port 5432? If not, wait a few seconds and retry.
2020-08-28 03:29:39.343 CEST [13046] WARNING: could not create listen socket for "localhost"
2020-08-28 03:29:39.343 CEST [13046] FATAL: could not create any TCP/IP sockets
2020-08-28 03:29:39.343 CEST [13046] LOG: database system is shut down
It is that simple: if something goes wrong,
pgenv shows me the last bunch of lines of the logs. If I’m lucky, I will see the problem without having to manually type another command to dig into the logs (in the above, another cluster or process is holding the TCP/IP port 5432).
There is no black magic here:
tail is used to the rescue!
Show me my logs
What if you don’t remember wherepgenv is storing your logs and want to see them to mail or ask for help?
Here comes the new
log command, that in turns invokes tail on the logs (assuming there is one log!). The beauty of using tail is that it becomes very simple to support every other flag tail does support, doing therefore “complex” log analysis.
So, in the case you want your logs:
% pgenv log
Dumping the content of /home/luca/git/misc/PostgreSQL/pgenv/pgsql/data/server.log
2020-08-28 03:29:19.903 CEST [11867] LOG: aborting any active transactions
2020-08-28 03:29:19.905 CEST [11867] LOG: background worker "logical replication launcher" (PID 11874) exited with exit code 1
2020-08-28 03:29:19.906 CEST [11869] LOG: shutting down
2020-08-28 03:29:19.922 CEST [11867] LOG: database system is shut down
2020-08-28 03:29:39.342 CEST [13046] LOG: starting PostgreSQL 12.1 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 8.3.0-6ubuntu1) 8.3.0, 64-bit
2020-08-28 03:29:39.343 CEST [13046] LOG: could not bind IPv4 address "127.0.0.1": Address already in use
2020-08-28 03:29:39.343 CEST [13046] HINT: Is another postmaster already running on port 5432? If not, wait a few seconds and retry.
2020-08-28 03:29:39.343 CEST [13046] WARNING: could not create listen socket for "localhost"
2020-08-28 03:29:39.343 CEST [13046] FATAL: could not create any TCP/IP sockets
2020-08-28 03:29:39.343 CEST [13046] LOG: database system is shut down
and in the case you want something different:
% pgenv log -n 3 -f
Dumping the content of /home/luca/git/misc/PostgreSQL/pgenv/pgsql/data/server.log
2020-08-28 03:29:39.343 CEST [13046] WARNING: could not create listen socket for "localhost"
2020-08-28 03:29:39.343 CEST [13046] FATAL: could not create any TCP/IP sockets
2020-08-28 03:29:39.343 CEST [13046] LOG: database system is shut down
that prints the last three lines and waits for new logs to be displayed.
Conclusions
The newpgenv functionalities are just toys, but I hope they can help people approaching this project that can really help, in turn, to get a cluster up and running.