2020年11月16日(月) 15:48 Bharath Rupireddy <bharath.rupireddyforpostg...@gmail.com>: > > On Thu, Nov 12, 2020 at 4:01 AM Mark Dilger > <mark.dil...@enterprisedb.com> wrote: > > > > While supporting customers, it would frequently be useful to have more > > information about the history of a cluster. For example, which prior > > versions were ever installed and running on the cluster? Has the cluster > > ever been run with fsync=off? When did the server last enter recovery, if > > ever? Was a backup_label file present at that time? > > > > +1 for the idea. The information will be useful at times for debugging > purposes.
It's certainly something which would be nice to have. > > Would it make sense to alternately, or additionally, store some of this > > information in a flat text file in pg_data, say a new file named > > "cluster_history" or such? > > > > IMHO, this is also a good idea. We need to think of the APIs to > open/read/write/close that history file? How often and which processes > and what type of data they write? Is it that the postmaster alone will > write into that file? If multiple processes are allowed to write, how > to deal with concurrent writers? Will users have to open manually and > read that file? or Will we have some program similar to > pg_controldata? Will we have some maximum limit to the size of this > file? pg_stat_statements might be worth looking at as one way of handling that kind of file. However the problem with keeping a separate file which is not WAL-logged would mean it doesn't get propagated to standbys, and there's also the question of how it could be maintained across upgrades via pg_upgrade. FWIW I did once create a background worker extension [1] which logs configuration changes to a table, though it's not particularly maintained or recommended for production use. [1] https://github.com/ibarwick/config_log Regards Ian Barwick -- EnterpriseDB: https://www.enterprisedb.com
