summaryrefslogtreecommitdiffstats
path: root/ChangeLog
blob: 51f096490510b8f9d7629cde5db5c48f844d7e60 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
2014-07-03  Pavel Raiskup  <praiskup@redhat.com>
	upgrade/initdb logs: diverge among service names

	Generate separate log file for each service.  Also, don't
	configure with INITDB_LOG or UPGRADE_LOG but rather with
	POSTGRES_HOME.

2014-07-03  Pavel Raiskup  <praiskup@redhat.com>
	postgresql-setup: expect '--port 5432' implictly

	.. only when '--unit=postgresql'.  When user specifies
	--unit=postgresql@unitname, the --port is still required.

	Also, don't adjust the 'port = ' configuration in postgresql.conf
	when not necessary.

2014-07-01  Pavel Raiskup  <praiskup@redhat.com>
	README-rpm-dist, postgresql.service, postgresql-cehck-db-dir

	Those files are now also generated in postgresql-setup.

2014-07-01  Pavel Raiskup  <praiskup@redhat.com>
	postgresql-ctl, DISTSUFF: introduce

	We need postgresql-ctl for to keep backward compatibility with clients
	setting "PGPORT" directly in service file.

	DISTSUFF variable (which is read by ./configure) may be used to
	generated namespaced binary names -- e.g. DISTSUFF=93 results in
	postgresql93-setup is generated instead of postgresql-setup.

2014-06-23  Pavel Raiskup  <praiskup@redhat.com>
	docs: generate manual page

	The help2man utility is needed for man-page generation.

2014-06-21  Pavel Raiskup  <praiskup@redhat.com>
	postgresql-setup: do not resist on PGPORT in service file

	We use /etc/sysconfig/postgresql for PGDATA configuration.  PGPORT there
	is optional as it is possible (and it is by default) to configure it in
	postgresql.conf.

2014-06-21  Pavel Raiskup  <praiskup@redhat.com>

	postgresql-setup: split this script from postgresql package

	Maintenance of postgresql-setup script becoming harder and dealing with
	its development in Fedora Rawhide dist-git costs quite a lot of work.
	Turns out that it would be better to start development separately and
	possibly package it separately also in future (which would be beneficial
	because we could not respin whole PostgreSQL package for hot-fix in
	postgresql-setup).

	Possibly, this package could be useful for other distributions.