On Mon, Feb 27, 2017 at 11:15 PM, Jim Nasby <jim.na...@bluetreble.com> wrote: >> * You're considering any WAL file with a power of 2 as valid. Suppose, >> the correct WAL seg size is 64mb. For some reason, the server >> generated a 16mb invalid WAL file(maybe it crashed while creating the >> WAL file). Your code seems to treat this as a valid file which I think >> is incorrect. Do you agree with that? > > Detecting correct WAL size based on the size of a random WAL file seems like > a really bad idea to me.
It's not the most elegant thing ever, but I'm not sure I really see a big problem with it. Today, if the WAL file were the wrong size, we'd just error out. With the patch, if the WAL file were the wrong size, but happened to be a size that we consider legal, pg_waldump would treat it as a legal file and try to display the WAL records contained therein. This doesn't seem like a huge problem from her; what are you worried about? I agree that it would be bad if, for example, pg_resetwal saw a broken WAL file in pg_wal and consequently did the reset incorrectly, because the whole point of pg_resetwal is to escape situations where the contents of pg_wal may be bogus. However, pg_resetwal can read the value from the control file, so the technique of believing the file size doesn't need to be used in that case anyway. The only tools that need to infer the WAL size from the sizes of the segments actually present are those that neither have a running cluster (where SHOW can be used) nor access to the control file. There aren't many of those, and pg_waldump, at least, is a debugging tool anyway. IIUC, the other case where this comes up is for pg_standby, but if the WAL segments aren't all the same size that tool is presumably going to croak with or without these changes, so I'm not really sure there's much of an issue here. I might be missing something. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers