免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
查看: 2534 | 回复: 0
打印 上一主题 下一主题

PostgreSQL CATALOG_VERSION_NO check [复制链接]

论坛徽章:
0
跳转到指定楼层
1 [收藏(0)] [报告]
发表于 2011-02-22 18:11 |只看该作者 |倒序浏览
源码文件postgresql-9.0.2/src/include/catalog/catversion.h
内容如下:
/*-------------------------------------------------------------------------
*
* catversion.h
*        "Catalog version number" for PostgreSQL.
*
* The catalog version number is used to flag incompatible changes in
* the PostgreSQL system catalogs.      Whenever anyone changes the format of
* a system catalog relation, or adds, deletes, or modifies standard
* catalog entries in such a way that an updated backend wouldn't work
* with an old database (or vice versa), the catalog version number
* should be changed.  The version number stored in pg_control by initdb
* is checked against the version number compiled into the backend at
* startup time, so that a backend can refuse to run in an incompatible
* database.
*
* The point of this feature is to provide a finer grain of compatibility
* checking than is possible from looking at the major version number
* stored in PG_VERSION.  It shouldn't matter to end users, but during
* development cycles we usually make quite a few incompatible changes
* to the contents of the system catalogs, and we don't want to bump the
* major version number for each one.  What we can do instead is bump
* this internal version number.  This should save some grief for
* developers who might otherwise waste time tracking down "bugs" that
* are really just code-vs-database incompatibilities.
*
* The rule for developers is: if you commit a change that requires
* an initdb, you should update the catalog version number (as well as
* notifying the pghackers mailing list, which has been the informal
* practice for a long time).
*
* The catalog version number is placed here since modifying files in
* include/catalog is the most common kind of initdb-forcing change.
* But it could be used to protect any kind of incompatible change in
* database contents or layout, such as altering tuple headers.
*
*
* Portions Copyright (c) 1996-2010, PostgreSQL Global Development Group
* Portions Copyright (c) 1994, Regents of the University of California
*
* $PostgreSQL: pgsql/src/include/catalog/catversion.h,v 1.587.2.1 2010/08/05 18:21:29 tgl Exp $
*
*-------------------------------------------------------------------------
*/
#ifndef CATVERSION_H
#define CATVERSION_H

/*
* We could use anything we wanted for version numbers, but I recommend
* following the "YYYYMMDDN" style often used for DNS zone serial numbers.
* YYYYMMDD are the date of the change, and N is the number of the change
* on that day.  (Hopefully we'll never commit ten independent sets of
* catalog changes on the same day...)
*/

/*                                                      yyyymmddN */
#define CATALOG_VERSION_NO      201008051

#endif

使用pg_controldata可以查看到这部分信息:
postgres@wapportal-guize-db-> pg_controldata /database/pgdata/pg_root
pg_control version number:            903
Catalog version number:               201004261
Database system identifier:           5486854347216502005
Database cluster state:               in production
pg_control last modified:             Tue 18 Jan 2011 10:19:10 AM CST
Latest checkpoint location:           46/5CBA21A0
Prior checkpoint location:            46/5C6DCCA0
Latest checkpoint's REDO location:    46/5C9181B0
Latest checkpoint's TimeLineID:       1
Latest checkpoint's NextXID:          0/130050360
Latest checkpoint's NextOID:          2919666
Latest checkpoint's NextMultiXactId:  652
Latest checkpoint's NextMultiOffset:  1318
Latest checkpoint's oldestXID:        655
Latest checkpoint's oldestXID's DB:   1
Latest checkpoint's oldestActiveXID:  130050360
Time of latest checkpoint:            Tue 18 Jan 2011 10:16:53 AM CST
Minimum recovery ending location:     0/0
Backup start location:                0/0
Current wal_level setting:            hot_standby
Current max_connections setting:      1800
Current max_prepared_xacts setting:   0
Current max_locks_per_xact setting:   64
Maximum data alignment:               8
Database block size:                  8192
Blocks per segment of large relation: 1048576
WAL block size:                       65536
Bytes per WAL segment:                67108864
Maximum length of identifiers:        64
Maximum columns in an index:          32
Maximum size of a TOAST chunk:        1996
Date/time type storage:               64-bit integers
Float4 argument passing:              by value
Float8 argument passing:              by value

今天在升级postgresql 9beta2 到postgresql 9.0.2发生了如下错误:
2011-01-18 09:58:52 CST @ (PID:4455 SID:4d34f3dc.1167)  DETAIL:  The database cluster was initialized with CATALOG_VERSION_NO 201004261, but the server was compiled with CATALOG_VERSION_NO 201008051.
2011-01-18 09:58:52 CST @ (PID:4455 SID:4d34f3dc.1167)  HINT:  It looks like you need to initdb.

看完上面那个.h文件的解释就不难理解了。
看样子要用pg_dump升级了。
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP