Bug 803295

Summary:	Confusing redundancy in specifying PGPORT in postgresql.service (FC16) and init.d/postgresql (FC15)
Product:	[Fedora] Fedora	Reporter:	Marek Kielar <mkielar>
Component:	postgresql	Assignee:	Tom Lane <tgl>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	16	CC:	devrim, hhorak, tgl
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-03-14 14:03:11 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Marek Kielar 2012-03-14 11:47:21 UTC

Description of problem:
This applies both to FC16 and FC15, and possibly all maintained.

Under FC16 the file /lib/systemd/system/postgresql.service
and under FC15 the file /etc/rc.d/init.d/postgresql
contain a line specifying PGPORT=5432.

By design of PostgreSQL this information is contained in postgresql.conf. However, the specified files by default override the PostgreSQL default in a not-that-obvious way (revealed only after "ps -Af"), since it is not mentioned in the PostgreSQL documentation while the postgresql.conf way is. Thus, it breaks the outcome of changing postgresql.conf to have no effect, also introducing data inconsistency at the same time between the init files and postgresql.conf, and is a source of confusion for newbies.

There is a way proposed in /lib/systemd/system/postgresql.service of putting /etc/systemd/system/postgresql.service to further override /lib/systemd/system/postgresql.service "default override" value, however either way this introduces aforementioned redundancy / data inconsistency.

One has also to take into account that setting PGPORT in the environment allows for not specifying it explicitly later while using PostgreSQL management tools.

The only ways I see out of this stalemate are:
1. to extract PGPORT out of a postgresql.conf file and use that (not that nice - a race condition is created, but easy enough for a good starting point), or
2. extract it from the being-run PostgreSQL instance (seems proper - no race condition, though possibly no such interface exposed at this time).

Version-Release number of selected component (if applicable):
The PostgreSQL versions are 9.0, 9.1, and possibly all maintained, but since this is rather an issue with initialization of FC15, FC16, and possibly all maintained, versions of FC seem more applicable.

How reproducible:
100%

Steps to Reproduce:
On a clean install of postgresql package:
1. Change postgresql.conf "port=" to a custom value.
2. Run postgresql service.

Actual results:
PostgreSQL runs at "default-override" port 5432.

Expected results:
PostgreSQL runs at the custom port.

Comment 1 Tom Lane 2012-03-14 14:03:11 UTC

IMO this is not a bug, and the current behavior is the expected one.  The postgresql documentation is perfectly clear that postmaster command-line switches override postgresql.conf.  Moreover, since it's worked like this in Fedora, RHEL, and most other distributions since approximately forever, people would be confused and unhappy if we removed the behavior.

Comment 2 Marek Kielar 2012-03-17 10:22:49 UTC

I find it simply wrong to say "it's worked like this [...] since approximately forever". Rather, it did until we migrated to systemd with postgresql package in FC16, it marks a new era - what worked like this forever? As I understand, what is really wanted is the same behavior out-of-the-box ie. just after installing postgresql package the server runs at port 5432.

Since a change has been made in where to customize the listening port value at migrating to systemd, a bit of slack has been made to allow for resolving issues with previous usage pattern eg. unneeded data redundancy.

That being said the transition doesn't seem to be complete as the package is internally inconsistent with respect to customizing the listening port as I'm just going to file a bug concerning this.

Comment 3 Marek Kielar 2012-03-17 11:46:34 UTC

Follow-up:
As seen with #804290, current approach is inherently flawed in that it introduces (new!) unneeded dependencies, with their own problems, and data redundancy that are hard to always remember to keep in line with the rest of the configuration and not obvious - right from the start!

Comment 4 Tom Lane 2012-03-17 17:03:51 UTC

These arguments don't seem to me to have anything to do with the key point, which is that it's traditional in at least Red Hat-based distributions to set PGPORT and PGDATA from someplace outside of postgresql.conf.  Moreover, while we could possibly extract PGPORT from postgresql.conf, we could hardly extract PGDATA from there since we'd need to know PGDATA to find the file in the first place.  And your suggestion of extracting them from a running instance is just circular --- it doesn't work at all for the "start" case, and how are you going to contact a running instance if you don't know its port number?

I don't plan to change this.