On 06/18/2014 09:17 PM, Josh Berkus wrote:
On 06/18/2014 11:03 AM, Andres Freund wrote:
Well, all those actually do write to the xlog (to write a new
checkpoint, containing the updated control file). Since pg_resetxlog has
done all this pretty much since forever renaming it now seems to be a
big hassle for users for pretty much no benefit? This isn't a tool the
average user should ever touch.

If we're using it to create a unique system ID which can be used to
orchestrate replication and clustering systems, a lot more people are
going to be touching it than ever did before -- and not just for BDR.

I think pg_resetxlog is still appropriate: changing the system ID will reset the WAL. In particular, any archived WAL will become useless.

But yeah, this does change the target audience of pg_resetxlog significantly. Now that we'll have admins running pg_resetxlog as part of normal operations, we have to document it carefully. We also have to design the user interface carefully, to make it more clear that while resetting the system ID won't eat your data, some of the other settings will.

The proposed "pg_resetxlog --help" output looks like this:

pg_resetxlog resets the PostgreSQL transaction log.

  pg_resetxlog [OPTION]... DATADIR

  -e XIDEPOCH      set next transaction ID epoch
  -f               force update to be done
  -l XLOGFILE      force minimum WAL starting location for new transaction log
  -m MXID,MXID     set next and oldest multitransaction ID
  -n               no update, just show what would be done (for testing)
  -o OID           set next OID
  -O OFFSET        set next multitransaction offset
  -s [SYSID]       set system identifier (or generate one)
  -V, --version    output version information, then exit
  -x XID           set next transaction ID
  -?, --help       show this help, then exit

Report bugs to <pgsql-b...@postgresql.org>.

I don't think that's good enough. The -s option should be displayed more prominently, and the dangerous options like -l and -x should be more clearly labeled as such.

I would de-emphasize setting the system ID to a particular value. It might be useful for disaster recovery, like -x, but in general you should always reset it to a new unique value. If you make it too easy to set it to a particular value, someone will try initialize a streaming standby server using initdb+pg_dump, and changing the system ID to match the master's.

The user manual for pg_resetxlog says:

pg_resetxlog clears the write-ahead log (WAL) and optionally resets
some other control information stored in the pg_control file. This
function is sometimes needed if these files have become corrupted. It
should be used only as a last resort, when the server will not start
due to such corruption.

That's clearly not true for the -s option.

In summary, I think we want this feature in some form, but we'll somehow need to be make the distinction to the dangerous pg_resetxlog usage. It might be best, after all, to make this a separate utility, pg_resetsystemid. It would not need to have the capability to set the system ID to a particular value, only a randomly assigned one (setting it to a particular value could be added to pg_resetxlog, where other dangerous options are).

- Heikki

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to