So, does anyone care?!

Yes! This bug just isn't priority for us.

FYI, upstream package postgresql93-server-9.3.20-3PGDG.rhel7.x86_64 breaks because of this issue:

* Thu Dec 07 2017 John K. Harvey <john.harvey> - 9.3.20-3PGDG
- Fixes for CVE-2017-12172 (EL-6 only)
- Update TimeOutSec parameter to match systemd docs (EL-7 only)

# systemctl start postgresql-9.3
Job for postgresql-9.3.service failed because a timeout was exceeded. See "systemctl status postgresql-9.3.service" and "journalctl -xe" for details.

(See http://www.postgresql-archive.org/BUG-14967-Postgresql-won-t-start-after-upgrade-from-postgresql93-9-3-20-1PGDG-rhel7-x86-64-td5996531.html )

However, I understand that 'infinity' as a timeout value is only recognised from systemd 229, whereas EL7 contains 219, so it looks like the PGSQL project may have jumped the gun here.

The support for infinity was added in https://github.com/systemd/systemd/commit/36c16a7cdd6c33d7980efc2cd6a2211941f302b4 , which was quite a large change. Also, there was at least one regression-fixing follow-up commit: https://github.com/systemd/systemd/commit/89beff89edba592366b2960bd830d3f6e602c2c7 . Therefore I don't think it's a good candidate for backporting. But perhaps we could adapt the parser to accept "infinity" and interpret it the same way as 0: to disable the timeout.

*** Bug 1638138 has been marked as a duplicate of this bug. ***

I am closing this bug at this time in order to focus our efforts on higher priority issues.

The TimeoutSec, TimeoutStartSec, and TimeoutStopSec mechanisms within the revision of systemd for RHEL 7 (based on 219 with a steadily growing number of backports) are documented as the following in "man systemd.service":

       TimeoutStartSec=
           Configures the time to wait for start-up. If a daemon service does not signal start-up
           completion within the configured time, the service will be considered failed and will be
           shut down again. Takes a unit-less value in seconds, or a time span value such as "5min
           20s". Pass "0" to disable the timeout logic. Defaults to DefaultTimeoutStartSec= from the
           manager configuration file, except when Type=oneshot is used, in which case the timeout is
           disabled by default (see systemd-system.conf(5)).

       TimeoutStopSec=
           This option serves two purposes. First, it configures the time to wait for each ExecStop=
           command. If any of them times out, subsequent ExecStop= commands are skipped and the
           service will be terminated by SIGTERM. If no ExecStop= commands are specified, the service
           gets the SIGTERM immediately. Second, it configures the time to wait for the service itself
           to stop. If it doesn't terminate in the specified time, it will be forcibly terminated by
           SIGKILL (see KillMode= in systemd.kill(5)). Takes a unit-less value in seconds, or a time
           span value such as "5min 20s". Pass "0" to disable the timeout logic. Defaults to
           DefaultTimeoutStopSec= from the manager configuration file (see systemd-system.conf(5)).

       TimeoutSec=
           A shorthand for configuring both TimeoutStartSec= and TimeoutStopSec= to the specified
           value.

As noted above, the method to disable the timeout logic is to use the "0" value. The "infinity" value was not available until the upstream 229 release. 

The use of "infinity" is now available within the RHEL 8 release, as it is based upon upstream systemd 239. As indicated by David above, the backport for allowing "infinity" use instead of "0" is currently deemed to risky to existing installations to proceed forwards with within the RHEL 7 release.