Re: WAL page magic number (was Re: [HACKERS] Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct)
Heikki Linnakangas wrote: Tom Lane wrote: Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: Browsing the history of XLOG_PAGE_MAGIC, it used to be incremented by one whenever the format changes, at least as long as it has been been in xlog_internal.h. It started at 0xD05B in 2005, and was incremented by one by each commit till 0xD062. But then the hot standby patch bumped it to 0xD166, and on March 19th Simon changed it to 0x9002, and on March 28th to 0x9003. Is there a plan somewhere on all that, or was it just random whacking? Random whacking. Simon seems to have decided to try to make the number mean something, but it never meant anything before. It's not a version number, it's a magic identifier. We might need to avoid certain values to prevent collisions with other file formats, so I'm suspicious of trying to make it match up with some expectation. Ok, for better or worse, I whacked it back to the old series. Agreed. Making it match the version would be odd because you then have t bump it for every major release. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: WAL page magic number (was Re: [HACKERS] Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct)
Bruce Momjian wrote: Heikki Linnakangas wrote: Tom Lane wrote: Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: Browsing the history of XLOG_PAGE_MAGIC, it used to be incremented by one whenever the format changes, at least as long as it has been been in xlog_internal.h. It started at 0xD05B in 2005, and was incremented by one by each commit till 0xD062. But then the hot standby patch bumped it to 0xD166, and on March 19th Simon changed it to 0x9002, and on March 28th to 0x9003. Is there a plan somewhere on all that, or was it just random whacking? Random whacking. Simon seems to have decided to try to make the number mean something, but it never meant anything before. It's not a version number, it's a magic identifier. We might need to avoid certain values to prevent collisions with other file formats, so I'm suspicious of trying to make it match up with some expectation. Ok, for better or worse, I whacked it back to the old series. Agreed. Making it match the version would be odd because you then have t bump it for every major release. Not necessarily. It would make sense to me to just keep it the same if there has been no changes. The magic number would indicate the first version that used that format. I'm not advocating a switch to that system, but it would be sensible as well. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
WAL page magic number (was Re: [HACKERS] Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct)
Tom Lane wrote: The correct way to reflect a change in WAL contents is to bump the WAL page magic number. Browsing the history of XLOG_PAGE_MAGIC, it used to be incremented by one whenever the format changes, at least as long as it has been been in xlog_internal.h. It started at 0xD05B in 2005, and was incremented by one by each commit till 0xD062. But then the hot standby patch bumped it to 0xD166, and on March 19th Simon changed it to 0x9002, and on March 28th to 0x9003. Is there a plan somewhere on all that, or was it just random whacking? It's a bit weird though that the commit on March 19th moved it backwards. We don't guarantee backwards-compatibility, so any program looking at the WAL needs to know not only minimum version it supports but a list of all supported versions, so it's not catastrophic. Still weird, though. It hasn't been like that for long yet, and not in any released version, so we could still change it back to the original scheme (0xD063). 0x9002 sounds like it means the 9.0 release, which might be a good versioning scheme as well. If want to continue with that scheme, it should be documented in the comments. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: WAL page magic number (was Re: [HACKERS] Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct)
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: Tom Lane wrote: The correct way to reflect a change in WAL contents is to bump the WAL page magic number. Browsing the history of XLOG_PAGE_MAGIC, it used to be incremented by one whenever the format changes, at least as long as it has been been in xlog_internal.h. It started at 0xD05B in 2005, and was incremented by one by each commit till 0xD062. But then the hot standby patch bumped it to 0xD166, and on March 19th Simon changed it to 0x9002, and on March 28th to 0x9003. Is there a plan somewhere on all that, or was it just random whacking? Random whacking. Simon seems to have decided to try to make the number mean something, but it never meant anything before. It's not a version number, it's a magic identifier. We might need to avoid certain values to prevent collisions with other file formats, so I'm suspicious of trying to make it match up with some expectation. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: WAL page magic number (was Re: [HACKERS] Re: [COMMITTERS] pgsql: Make CheckRequiredParameterValues() depend upon correct)
Tom Lane wrote: Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: Browsing the history of XLOG_PAGE_MAGIC, it used to be incremented by one whenever the format changes, at least as long as it has been been in xlog_internal.h. It started at 0xD05B in 2005, and was incremented by one by each commit till 0xD062. But then the hot standby patch bumped it to 0xD166, and on March 19th Simon changed it to 0x9002, and on March 28th to 0x9003. Is there a plan somewhere on all that, or was it just random whacking? Random whacking. Simon seems to have decided to try to make the number mean something, but it never meant anything before. It's not a version number, it's a magic identifier. We might need to avoid certain values to prevent collisions with other file formats, so I'm suspicious of trying to make it match up with some expectation. Ok, for better or worse, I whacked it back to the old series. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
