Re: [HACKERS] Query caching
On Fri, 10 Nov 2000 [EMAIL PROTECTED] wrote: > Did someone think about query costs ? Is you prepare > query like SELECT id FROM t1 WHERE type=$1 and > execute it with $1=1 and 2. For 1 there is one record > in t1 a all other have type=2. > Without caching, first query will use index, second > not. > Should cached plan use index or not ? > devik The postgresql already have planns caching. See SPI (saveplan), but it's usable for internal stuff (for example triggers..) only. The PREPARE/EXECUTE pull up it to be<->fe and make new memory type that allows save it in shared memory. But else it's *nothing* new. A validity of cached planns is user problem now. Not some internal method how check changes that out of date some query (or exist some idea?). It can be more changes like changes in DB schema. If resolve this anyone clever person it will great for VIEW, SPI too. Rebuid a query plan in the planner is not a problem, in the cache is stored original query tree, but you must known when... or must know it a DB user. Karel
[HACKERS] SYSLOG/LOG_LOCAL0
Any reason to NOT make the facility used (Currently hardcoded to LOG_LOCAL0) settable at runtime? (or at least compile)? Larry -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 (voice) Internet: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
[HACKERS] Syslog Facility Patch
Here is a patch for allowing the syslog facility to be set.
Index: doc/src/sgml/runtime.sgml
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/doc/src/sgml/runtime.sgml,v
retrieving revision 1.33
diff -c -r1.33 runtime.sgml
*** doc/src/sgml/runtime.sgml 2000/11/10 16:32:09 1.33
--- doc/src/sgml/runtime.sgml 2000/11/12 17:13:37
***
*** 822,827
--- 822,839
+ SYSLOG_FACILITY (string)
+
+
+ If the SYSLOG option is set to 1 or greater, this option determines
+ the syslog facility used. You may choose
+ from LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7.
+ the default is LOCAL0
+
+
+
+
+
TRACE_NOTIFY (boolean)
Index: src/backend/utils/error/elog.c
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/utils/error/elog.c,v
retrieving revision 1.65
diff -c -r1.65 elog.c
*** src/backend/utils/error/elog.c 2000/10/30 06:48:36 1.65
--- src/backend/utils/error/elog.c 2000/11/12 17:13:39
***
*** 58,63
--- 58,64
* ... in theory anyway
*/
int Use_syslog = 0;
+ char *Syslog_facility = "LOCAL0";
static void write_syslog(int level, const char *line);
***
*** 620,625
--- 621,627
static bool openlog_done = false;
static unsigned long seq = 0;
+ static int syslog_fac = LOG_LOCAL0;
int len = strlen(line);
if (Use_syslog == 0)
***
*** 627,633
if (!openlog_done)
{
! openlog("postgres", LOG_PID | LOG_NDELAY, LOG_LOCAL0);
openlog_done = true;
}
--- 629,651
if (!openlog_done)
{
! if (strcmp(Syslog_facility,"LOCAL0") == 0)
! syslog_fac = LOG_LOCAL0;
! if (strcmp(Syslog_facility,"LOCAL1") == 0)
! syslog_fac = LOG_LOCAL1;
! if (strcmp(Syslog_facility,"LOCAL2") == 0)
! syslog_fac = LOG_LOCAL2;
! if (strcmp(Syslog_facility,"LOCAL3") == 0)
! syslog_fac = LOG_LOCAL3;
! if (strcmp(Syslog_facility,"LOCAL4") == 0)
! syslog_fac = LOG_LOCAL4;
! if (strcmp(Syslog_facility,"LOCAL5") == 0)
! syslog_fac = LOG_LOCAL5;
! if (strcmp(Syslog_facility,"LOCAL6") == 0)
! syslog_fac = LOG_LOCAL6;
! if (strcmp(Syslog_facility,"LOCAL7") == 0)
! syslog_fac = LOG_LOCAL7;
! openlog("postgres", LOG_PID | LOG_NDELAY, syslog_fac);
openlog_done = true;
}
Index: src/backend/utils/misc/guc.c
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/utils/misc/guc.c,v
retrieving revision 1.16
diff -c -r1.16 guc.c
*** src/backend/utils/misc/guc.c2000/11/09 11:25:59 1.16
--- src/backend/utils/misc/guc.c2000/11/12 17:13:39
***
*** 39,44
--- 39,45
extern int CheckPointTimeout;
extern int XLOGbuffers;
extern int XLOG_DEBUG;
+ extern char * Syslog_facility;
/*
* Debugging options
***
*** 303,308
--- 304,312
{"unix_socket_group", PGC_POSTMASTER, &Unix_socket_group,
"", NULL},
+ #ifdef ENABLE_SYSLOG
+ {"syslog_facility", PGC_SIGHUP, &Syslog_facility, "LOCAL0", NULL},
+
+ #endif
{NULL, 0, NULL, NULL, NULL}
};
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 (voice) Internet: [EMAIL PROTECTED]
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Re: [HACKERS] cygwin gcc problem.
Still no luck with this. I'm at a loss. Has ANYONE been able to compile PostgreSQL on Windows 2000 with the CYGWIN package? If so, I'd be glad to know what steps were taken to accomplish this. I tried Matthew's suggestions, but that didn't seem to make a difference. I'm starting to wonder now if I've got a buggy CYGWIN... My goal here is to have a decent PostgresSQL distribution for W2K, which of course I'll make available in Installation form. However, if I can't get this sucker going, its not going to happen. Thanks in advance, Gary - Original Message - From: "Matthew" <[EMAIL PROTECTED]> To: "'Alfred Perlstein '" <[EMAIL PROTECTED]>; "'Gary MacDougall '" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Saturday, November 11, 2000 1:29 PM Subject: RE: [HACKERS] cygwin gcc problem. > I sucessfully compiled 7.0.2 on Win 2000 recently. I had a lot of problems > when I first installed cygwin and I select default text type of DOS. When i > removed cygwin, and changed that option during install it all worked (I'm > not sure if I swited it from DOS to Unix, or from Unix to DOS). I'm not > sure that's the problem you are having but it helped me. > > -Original Message- > From: Alfred Perlstein > To: Gary MacDougall > Cc: [EMAIL PROTECTED] > Sent: 11/11/00 1:31 PM > Subject: Re: [HACKERS] cygwin gcc problem. > > * Gary MacDougall <[EMAIL PROTECTED]> [00 11:28] wrote: > > I'm trying to compile postgresql on Windows 2000. I've followed the > directions accordingly. > > > > When I run the "configure" script, and I get the following error > message: > > > > > > configure: error installation or configuration problem: C compiler > cannot creat > > e executables. > > > > If anyone has any clues, I'd greatly appreciate the assistance. > > I think you need to ask on the cygwin lists. If you're compiling > this on Windows 2000 you already need a compiler to compile it. > > I would just find the binary distribution and install that. > > -Alfred
Re: [HACKERS] cygwin gcc problem.
I can't remember now where I found this, but I followed the instructions here -- http://people.freebsd.org/~kevlo/postgres/portNT.html -- to the letter just last night and was successful in getting PostgreSQL running on my W2K laptop. As mentioned below, I selected Unix file type for the CYGWIN installation. I haven't played too much with it yet, but I was able to create a new database and load a database dump from a RedHat machine. Hope this helps, Joe - Original Message - From: "Gary MacDougall" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "Matthew" <[EMAIL PROTECTED]>; "'Alfred Perlstein '" <[EMAIL PROTECTED]> Sent: Sunday, November 12, 2000 12:22 PM Subject: Re: [HACKERS] cygwin gcc problem. > Still no luck with this. I'm at a loss. > > Has ANYONE been able to compile PostgreSQL on Windows 2000 > with the CYGWIN package? If so, I'd be glad to know what steps > were taken to accomplish this. > I tried Matthew's suggestions, but that didn't seem to make a difference. > I'm starting to wonder now if I've got a buggy CYGWIN... > > My goal here is to have a decent PostgresSQL distribution for W2K, which > of course I'll make available in Installation form. However, if I can't get > this sucker going, its not going to happen. > > Thanks in advance, > Gary > > - Original Message - > From: "Matthew" <[EMAIL PROTECTED]> > To: "'Alfred Perlstein '" <[EMAIL PROTECTED]>; "'Gary MacDougall '" > <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Saturday, November 11, 2000 1:29 PM > Subject: RE: [HACKERS] cygwin gcc problem. > > > > I sucessfully compiled 7.0.2 on Win 2000 recently. I had a lot of > problems > > when I first installed cygwin and I select default text type of DOS. When > i > > removed cygwin, and changed that option during install it all worked (I'm > > not sure if I swited it from DOS to Unix, or from Unix to DOS). I'm not > > sure that's the problem you are having but it helped me. > > > > -Original Message- > > From: Alfred Perlstein > > To: Gary MacDougall > > Cc: [EMAIL PROTECTED] > > Sent: 11/11/00 1:31 PM > > Subject: Re: [HACKERS] cygwin gcc problem. > > > > * Gary MacDougall <[EMAIL PROTECTED]> [00 11:28] wrote: > > > I'm trying to compile postgresql on Windows 2000. I've followed the > > directions accordingly. > > > > > > When I run the "configure" script, and I get the following error > > message: > > > > > > > > > configure: error installation or configuration problem: C compiler > > cannot creat > > > e executables. > > > > > > If anyone has any clues, I'd greatly appreciate the assistance. > > > > I think you need to ask on the cygwin lists. If you're compiling > > this on Windows 2000 you already need a compiler to compile it. > > > > I would just find the binary distribution and install that. > > > > -Alfred > >
Re: [HACKERS] Syslog Facility Patch
OK, I don't like it (it just says "syntax error"), but here is an
improved version. I also switched to strcasecmp...
Index: doc/src/sgml/runtime.sgml
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/doc/src/sgml/runtime.sgml,v
retrieving revision 1.33
diff -c -r1.33 runtime.sgml
*** doc/src/sgml/runtime.sgml 2000/11/10 16:32:09 1.33
--- doc/src/sgml/runtime.sgml 2000/11/12 19:59:10
***
*** 822,827
--- 822,839
+ SYSLOG_FACILITY (string)
+
+
+ If the SYSLOG option is set to 1 or greater, this option determines
+ the syslog facility used. You may choose
+ from LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7.
+ the default is LOCAL0
+
+
+
+
+
TRACE_NOTIFY (boolean)
Index: src/backend/utils/error/elog.c
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/utils/error/elog.c,v
retrieving revision 1.65
diff -c -r1.65 elog.c
*** src/backend/utils/error/elog.c 2000/10/30 06:48:36 1.65
--- src/backend/utils/error/elog.c 2000/11/12 19:59:13
***
*** 58,63
--- 58,64
* ... in theory anyway
*/
int Use_syslog = 0;
+ char *Syslog_facility = "LOCAL0";
static void write_syslog(int level, const char *line);
***
*** 620,625
--- 621,627
static bool openlog_done = false;
static unsigned long seq = 0;
+ static int syslog_fac = LOG_LOCAL0;
int len = strlen(line);
if (Use_syslog == 0)
***
*** 627,633
if (!openlog_done)
{
! openlog("postgres", LOG_PID | LOG_NDELAY, LOG_LOCAL0);
openlog_done = true;
}
--- 629,651
if (!openlog_done)
{
! if (strcasecmp(Syslog_facility,"LOCAL0") == 0)
! syslog_fac = LOG_LOCAL0;
! if (strcasecmp(Syslog_facility,"LOCAL1") == 0)
! syslog_fac = LOG_LOCAL1;
! if (strcasecmp(Syslog_facility,"LOCAL2") == 0)
! syslog_fac = LOG_LOCAL2;
! if (strcasecmp(Syslog_facility,"LOCAL3") == 0)
! syslog_fac = LOG_LOCAL3;
! if (strcasecmp(Syslog_facility,"LOCAL4") == 0)
! syslog_fac = LOG_LOCAL4;
! if (strcasecmp(Syslog_facility,"LOCAL5") == 0)
! syslog_fac = LOG_LOCAL5;
! if (strcasecmp(Syslog_facility,"LOCAL6") == 0)
! syslog_fac = LOG_LOCAL6;
! if (strcasecmp(Syslog_facility,"LOCAL7") == 0)
! syslog_fac = LOG_LOCAL7;
! openlog("postgres", LOG_PID | LOG_NDELAY, syslog_fac);
openlog_done = true;
}
Index: src/backend/utils/misc/guc.c
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/utils/misc/guc.c,v
retrieving revision 1.16
diff -c -r1.16 guc.c
*** src/backend/utils/misc/guc.c2000/11/09 11:25:59 1.16
--- src/backend/utils/misc/guc.c2000/11/12 19:59:15
***
*** 39,44
--- 39,48
extern int CheckPointTimeout;
extern int XLOGbuffers;
extern int XLOG_DEBUG;
+ #ifdef ENABLE_SYSLOG
+ extern char * Syslog_facility;
+ bool check_facility(const char *facility);
+ #endif
/*
* Debugging options
***
*** 303,308
--- 307,315
{"unix_socket_group", PGC_POSTMASTER, &Unix_socket_group,
"", NULL},
+ #ifdef ENABLE_SYSLOG
+ {"syslog_facility", PGC_SIGHUP, &Syslog_facility, "LOCAL0",
+check_facility},
+ #endif
{NULL, 0, NULL, NULL, NULL}
};
***
*** 807,809
--- 814,832
if (*cp == '-')
*cp = '_';
}
+ #ifdef ENABLE_SYSLOG
+ bool check_facility(const char *facility)
+ {
+ if (strcasecmp(facility,"LOCAL0") == 0) return true;
+ if (strcasecmp(facility,"LOCAL1") == 0) return true;
+ if (strcasecmp(facility,"LOCAL2") == 0) return true;
+ if (strcasecmp(facility,"LOCAL3") == 0) return true;
+ if (strcasecmp(facility,"LOCAL4") == 0) return true;
+ if (strcasecmp(facility,"LOCAL5") == 0) return true;
+ if (strcasecmp(facility,"LOCAL6") == 0) return true;
+ if (strcasecmp(facility,"LOCAL7") == 0) return true;
+ fprintf(stderr,"invalid syslog_facility %s\n",facility);
+ elog(FATAL,"invalid syslog_facility %s",facility);
+ return false;
+ }
+ #endif
* Peter Eisentraut <[EMAIL PROTECTED]> [001112 12:18]:
> Larry Rosenman writes:
>
> > Here is a patch for allowing the syslog facility to be set.
>
> I think you want to check for invalid values, like "L
Re: [HACKERS] Syslog Facility Patch
* Larry Rosenman <[EMAIL PROTECTED]> [001112 14:02]: > OK, I don't like it (it just says "syntax error"), but here is an > improved version. I also switched to strcasecmp... In looking at this some more, it appears that *SOMETHING* is not allowing messages from set_config_option() in /src/backend/utils/misc/guc.c out WHEN WE ARE DEALING WITH syslog type stuff and we are reading it from the postgresql.conf file. I'm not sure how to deal with this.. I set syslog=2 then syslog_facility to some invalid value, and all I get is the syntax error message, not the "option rejects value" message. Anyone got any ideas? Oh, delete the elog() and fprintf() before you commit my patch (in check_facility() in guc.c), please. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 (voice) Internet: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Re: [HACKERS] Syslog Facility Patch
* Larry Rosenman <[EMAIL PROTECTED]> [001112 15:41]: > * Larry Rosenman <[EMAIL PROTECTED]> [001112 14:02]: > > OK, I don't like it (it just says "syntax error"), but here is an > > improved version. I also switched to strcasecmp... > In looking at this some more, it appears that *SOMETHING* is not > allowing messages from set_config_option() in > /src/backend/utils/misc/guc.c out WHEN WE ARE DEALING WITH syslog type > stuff and we are reading it from the postgresql.conf file. I'm not > sure how to deal with this.. I set syslog=2 then syslog_facility to > some invalid value, and all I get is the syntax error message, not the > "option rejects value" message. > > Anyone got any ideas? > > Oh, delete the elog() and fprintf() before you commit my patch (in > check_facility() in guc.c), please. Oh, more, if I give an invalid value on the command line, we get the right message out. So, it appears to be a conf file issue. I'm no (f)lex guru, nor do I totally understand the startup stuff. I feel the patch (modulo the killing of the elog() and fprintf() is valuable. I think I am the first to use the string parse_hook, so this is probably the first time we've had this issue. Any help would be appreciated. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 (voice) Internet: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Re: [HACKERS] Syslog Facility Patch
Here is a cleaned up patch, without the elog() and fprintf(), and some
minor formatting fixups.
Index: doc/src/sgml/runtime.sgml
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/doc/src/sgml/runtime.sgml,v
retrieving revision 1.33
diff -c -r1.33 runtime.sgml
*** doc/src/sgml/runtime.sgml 2000/11/10 16:32:09 1.33
--- doc/src/sgml/runtime.sgml 2000/11/12 23:02:17
***
*** 822,827
--- 822,839
+ SYSLOG_FACILITY (string)
+
+
+ If the SYSLOG option is set to 1 or greater, this option determines
+ the syslog facility used. You may choose
+ from LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7.
+ the default is LOCAL0
+
+
+
+
+
TRACE_NOTIFY (boolean)
Index: src/backend/utils/error/elog.c
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/utils/error/elog.c,v
retrieving revision 1.65
diff -c -r1.65 elog.c
*** src/backend/utils/error/elog.c 2000/10/30 06:48:36 1.65
--- src/backend/utils/error/elog.c 2000/11/12 23:02:20
***
*** 58,63
--- 58,64
* ... in theory anyway
*/
int Use_syslog = 0;
+ char *Syslog_facility = "LOCAL0";
static void write_syslog(int level, const char *line);
***
*** 620,625
--- 621,627
static bool openlog_done = false;
static unsigned long seq = 0;
+ static int syslog_fac = LOG_LOCAL0;
int len = strlen(line);
if (Use_syslog == 0)
***
*** 627,633
if (!openlog_done)
{
! openlog("postgres", LOG_PID | LOG_NDELAY, LOG_LOCAL0);
openlog_done = true;
}
--- 629,651
if (!openlog_done)
{
! if (strcasecmp(Syslog_facility,"LOCAL0") == 0)
! syslog_fac = LOG_LOCAL0;
! if (strcasecmp(Syslog_facility,"LOCAL1") == 0)
! syslog_fac = LOG_LOCAL1;
! if (strcasecmp(Syslog_facility,"LOCAL2") == 0)
! syslog_fac = LOG_LOCAL2;
! if (strcasecmp(Syslog_facility,"LOCAL3") == 0)
! syslog_fac = LOG_LOCAL3;
! if (strcasecmp(Syslog_facility,"LOCAL4") == 0)
! syslog_fac = LOG_LOCAL4;
! if (strcasecmp(Syslog_facility,"LOCAL5") == 0)
! syslog_fac = LOG_LOCAL5;
! if (strcasecmp(Syslog_facility,"LOCAL6") == 0)
! syslog_fac = LOG_LOCAL6;
! if (strcasecmp(Syslog_facility,"LOCAL7") == 0)
! syslog_fac = LOG_LOCAL7;
! openlog("postgres", LOG_PID | LOG_NDELAY, syslog_fac);
openlog_done = true;
}
Index: src/backend/utils/misc/guc.c
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/utils/misc/guc.c,v
retrieving revision 1.16
diff -c -r1.16 guc.c
*** src/backend/utils/misc/guc.c2000/11/09 11:25:59 1.16
--- src/backend/utils/misc/guc.c2000/11/12 23:02:22
***
*** 39,44
--- 39,48
extern int CheckPointTimeout;
extern int XLOGbuffers;
extern int XLOG_DEBUG;
+ #ifdef ENABLE_SYSLOG
+ extern char *Syslog_facility;
+bool check_facility(const char *facility);
+ #endif
/*
* Debugging options
***
*** 303,308
--- 307,316
{"unix_socket_group", PGC_POSTMASTER, &Unix_socket_group,
"", NULL},
+ #ifdef ENABLE_SYSLOG
+ {"syslog_facility", PGC_SIGHUP, &Syslog_facility,
+ "LOCAL0", check_facility},
+ #endif
{NULL, 0, NULL, NULL, NULL}
};
***
*** 807,809
--- 815,832
if (*cp == '-')
*cp = '_';
}
+ #ifdef ENABLE_SYSLOG
+ bool
+ check_facility(const char *facility)
+ {
+ if (strcasecmp(facility,"LOCAL0") == 0) return true;
+ if (strcasecmp(facility,"LOCAL1") == 0) return true;
+ if (strcasecmp(facility,"LOCAL2") == 0) return true;
+ if (strcasecmp(facility,"LOCAL3") == 0) return true;
+ if (strcasecmp(facility,"LOCAL4") == 0) return true;
+ if (strcasecmp(facility,"LOCAL5") == 0) return true;
+ if (strcasecmp(facility,"LOCAL6") == 0) return true;
+ if (strcasecmp(facility,"LOCAL7") == 0) return true;
+ return false;
+ }
+ #endif
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 (voice) Internet: [EMAIL PROTECTED]
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
[HACKERS] 7.0.2 -> 7.0.3 problem
I just upgraded to 7.0.3 and tried to start the backend like
/usr/local/pgsql/bin/postmaster -B 256 -o '-S 10240 -s' -D
/usr/local/pgsql/data -i > /usr/local/pgsql/postgres.log 2>&1 &
.. as I've done with 7.0.2, it failed to start and got this in my
postgresql.log :
DEBUG: Data Base System is starting up at Sun Nov 12 18:20:04 2000
FATAL 2: Read("/usr/local/pgsql/data/pg_control") failed: 2
FATAL 2: Read("/usr/local/pgsql/data/pg_control") failed: 2
Startup failed - abort
The only compilation change I made was to increase BLCKSZ to 32k (which has
been running in a production 7.0.2 environment for quite some time).
So what's up? Just to make sure I made the permissions 777 all the way down
to pg_control but it had no effect.
Hmm, I just re-installed 7.0.2 and I get the same error with it -- not good.
My development server, which is virtually the same, did fine when I
installed 7.0.3 so I'm guessing it's not a problem across the board..
I also notice in the log that it's Read("/usr/local/pgsql/data/pg_control")
that's failing and when I move pg_control out of the way, it's Open() that
fails..
I did nothing but stop the postmaster, compile and install 7.0.3 and start
the postmaster. then compiled and installed 7.0.2 again and all of the
sudden the 7.0.2 or 7.0.3 backend doesn't start -- it makes no sense.
As always, any help is appreciated. Thanks!
-Mitch
RE: [HACKERS] 7.0.2 -> 7.0.3 problem
Title: RE: [HACKERS] 7.0.2 -> 7.0.3 problem
You have to dump/initdb/reload if you change the block size. Simply recompiling is not going to work.
Cheers...
MikeA
-Original Message-
From: Mitch Vincent
To: [EMAIL PROTECTED]
Sent: 11-13-00 12:57 AM
Subject: [HACKERS] 7.0.2 -> 7.0.3 problem
I just upgraded to 7.0.3 and tried to start the backend like
/usr/local/pgsql/bin/postmaster -B 256 -o '-S 10240 -s' -D
/usr/local/pgsql/data -i > /usr/local/pgsql/postgres.log 2>&1 &
.. as I've done with 7.0.2, it failed to start and got this in my
postgresql.log :
DEBUG: Data Base System is starting up at Sun Nov 12 18:20:04 2000
FATAL 2: Read("/usr/local/pgsql/data/pg_control") failed: 2
FATAL 2: Read("/usr/local/pgsql/data/pg_control") failed: 2
Startup failed - abort
The only compilation change I made was to increase BLCKSZ to 32k (which
has
been running in a production 7.0.2 environment for quite some time).
So what's up? Just to make sure I made the permissions 777 all the way
down
to pg_control but it had no effect.
Hmm, I just re-installed 7.0.2 and I get the same error with it -- not
good.
My development server, which is virtually the same, did fine when I
installed 7.0.3 so I'm guessing it's not a problem across the board..
I also notice in the log that it's
Read("/usr/local/pgsql/data/pg_control")
that's failing and when I move pg_control out of the way, it's Open()
that
fails..
I did nothing but stop the postmaster, compile and install 7.0.3 and
start
the postmaster. then compiled and installed 7.0.2 again and all of the
sudden the 7.0.2 or 7.0.3 backend doesn't start -- it makes no sense.
As always, any help is appreciated. Thanks!
-Mitch
Re: [HACKERS] 7.0.2 -> 7.0.3 problem
By the way, what is pg_control and what does it do?
-Mitch
- Original Message -
From: "Michael Ansley" <[EMAIL PROTECTED]>
To: "'Mitch Vincent '" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Sunday, November 12, 2000 4:02 PM
Subject: RE: [HACKERS] 7.0.2 -> 7.0.3 problem
> You have to dump/initdb/reload if you change the block size. Simply
> recompiling is not going to work.
>
> Cheers...
>
>
> MikeA
>
> -Original Message-
> From: Mitch Vincent
> To: [EMAIL PROTECTED]
> Sent: 11-13-00 12:57 AM
> Subject: [HACKERS] 7.0.2 -> 7.0.3 problem
>
> I just upgraded to 7.0.3 and tried to start the backend like
>
> /usr/local/pgsql/bin/postmaster -B 256 -o '-S 10240 -s' -D
> /usr/local/pgsql/data -i > /usr/local/pgsql/postgres.log 2>&1 &
>
> .. as I've done with 7.0.2, it failed to start and got this in my
> postgresql.log :
>
> DEBUG: Data Base System is starting up at Sun Nov 12 18:20:04 2000
> FATAL 2: Read("/usr/local/pgsql/data/pg_control") failed: 2
> FATAL 2: Read("/usr/local/pgsql/data/pg_control") failed: 2
> Startup failed - abort
>
> The only compilation change I made was to increase BLCKSZ to 32k (which
> has
> been running in a production 7.0.2 environment for quite some time).
>
> So what's up? Just to make sure I made the permissions 777 all the way
> down
> to pg_control but it had no effect.
>
>
>
> Hmm, I just re-installed 7.0.2 and I get the same error with it -- not
> good.
>
> My development server, which is virtually the same, did fine when I
> installed 7.0.3 so I'm guessing it's not a problem across the board..
>
> I also notice in the log that it's
> Read("/usr/local/pgsql/data/pg_control")
> that's failing and when I move pg_control out of the way, it's Open()
> that
> fails..
>
> I did nothing but stop the postmaster, compile and install 7.0.3 and
> start
> the postmaster. then compiled and installed 7.0.2 again and all of the
> sudden the 7.0.2 or 7.0.3 backend doesn't start -- it makes no sense.
>
> As always, any help is appreciated. Thanks!
>
> -Mitch
>
Re: [HACKERS] can't insert "³\" as varchar in7.0.2 and 7.1
> Sorry if I post in the wrong list, but I've been tortured by the > problem for quite sometime. > > I've been tring for several combinations, say > > BACKEND FRONTEND > > MULE_INTERNAL EUC_TW > BIG5 > EUC_LATIN1 > EUC_TWEUC_TW > BIG5 > EUC_JP > .. > . > > None of them can use varchar as fields, and insert "³\" into the row. > Can anyone help? What is "³\" anyway? Is this a valid member of BIG5 or EUC_TW or whatver? BTW, there is no such an encoding EUC_LATIN1. -- Tatsuo Ishii
Re: [HACKERS] Syslog Facility Patch
Ok, You guys are probably tired of me, BUT, here is another one, that
adds the facility to set the program name used in syslog.
(this includes the other ones).
One gotcha, the parser doesn't like special characters in strings.
For example, i tried to use pg-test, and if failed the parse coming
from the postgresql.conf file.
I don't think it's a showstopper..
Comments?
Index: doc/src/sgml/runtime.sgml
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/doc/src/sgml/runtime.sgml,v
retrieving revision 1.33
diff -c -r1.33 runtime.sgml
*** doc/src/sgml/runtime.sgml 2000/11/10 16:32:09 1.33
--- doc/src/sgml/runtime.sgml 2000/11/13 01:15:34
***
*** 822,827
--- 822,851
+ SYSLOG_FACILITY (string)
+
+
+ If the SYSLOG option is set to 1 or greater, this option determines
+ the syslog facility used. You may choose
+ from LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7.
+ the default is LOCAL0
+
+
+
+
+
+ SYSLOG_PROGID (string)
+
+
+ If the SYSLOG option is set to 1 or greater, this option determines
+ the program id used to identify PostgreSQL messages
+ in syslog log messages. The default is
+ postgres.
+
+
+
+
+
TRACE_NOTIFY (boolean)
Index: src/backend/utils/error/elog.c
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/utils/error/elog.c,v
retrieving revision 1.65
diff -c -r1.65 elog.c
*** src/backend/utils/error/elog.c 2000/10/30 06:48:36 1.65
--- src/backend/utils/error/elog.c 2000/11/13 01:15:37
***
*** 58,63
--- 58,65
* ... in theory anyway
*/
int Use_syslog = 0;
+ char *Syslog_facility = "LOCAL0";
+ char *Syslog_progid = "postgres";
static void write_syslog(int level, const char *line);
***
*** 620,625
--- 622,628
static bool openlog_done = false;
static unsigned long seq = 0;
+ static int syslog_fac = LOG_LOCAL0;
int len = strlen(line);
if (Use_syslog == 0)
***
*** 627,633
if (!openlog_done)
{
! openlog("postgres", LOG_PID | LOG_NDELAY, LOG_LOCAL0);
openlog_done = true;
}
--- 630,652
if (!openlog_done)
{
! if (strcasecmp(Syslog_facility,"LOCAL0") == 0)
! syslog_fac = LOG_LOCAL0;
! if (strcasecmp(Syslog_facility,"LOCAL1") == 0)
! syslog_fac = LOG_LOCAL1;
! if (strcasecmp(Syslog_facility,"LOCAL2") == 0)
! syslog_fac = LOG_LOCAL2;
! if (strcasecmp(Syslog_facility,"LOCAL3") == 0)
! syslog_fac = LOG_LOCAL3;
! if (strcasecmp(Syslog_facility,"LOCAL4") == 0)
! syslog_fac = LOG_LOCAL4;
! if (strcasecmp(Syslog_facility,"LOCAL5") == 0)
! syslog_fac = LOG_LOCAL5;
! if (strcasecmp(Syslog_facility,"LOCAL6") == 0)
! syslog_fac = LOG_LOCAL6;
! if (strcasecmp(Syslog_facility,"LOCAL7") == 0)
! syslog_fac = LOG_LOCAL7;
! openlog(Syslog_progid, LOG_PID | LOG_NDELAY, syslog_fac);
openlog_done = true;
}
Index: src/backend/utils/misc/guc.c
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/backend/utils/misc/guc.c,v
retrieving revision 1.16
diff -c -r1.16 guc.c
*** src/backend/utils/misc/guc.c2000/11/09 11:25:59 1.16
--- src/backend/utils/misc/guc.c2000/11/13 01:15:38
***
*** 39,44
--- 39,49
extern int CheckPointTimeout;
extern int XLOGbuffers;
extern int XLOG_DEBUG;
+ #ifdef ENABLE_SYSLOG
+ extern char *Syslog_facility;
+ extern char *Syslog_progid;
+bool check_facility(const char *facility);
+ #endif
/*
* Debugging options
***
*** 303,308
--- 308,319
{"unix_socket_group", PGC_POSTMASTER, &Unix_socket_group,
"", NULL},
+ #ifdef ENABLE_SYSLOG
+ {"syslog_facility", PGC_SIGHUP, &Syslog_facility,
+ "LOCAL0", check_facility},
+ {"syslog_progid", PGC_SIGHUP, &Syslog_progid,
+ "postgres", NULL},
+ #endif
{NULL, 0, NULL, NULL, NULL}
};
***
*** 807,809
--- 818,835
if (*cp == '-')
*cp = '_';
}
+ #ifdef ENABLE_SYSLOG
+ bool
+ check_facility(const char *facility)
+ {
+ if (strcasecmp(facility,"LOCAL0") == 0) return true;
+
[HACKERS] Pl/Sql Error (may be..... )
I attach(create language) language PL/pgSQL in PG and
create test function (cut it from help ) :
--ðÒÏÓÔÏ ÓËÌÅÉÔØ ÓÔÒÏËÉ × ÏÄÎÕ
CREATE FUNCTION ct1(text, text) RETURNS text AS '
BEGIN
RETURN $1 || $2;
END;
' LANGUAGE 'plpgsql';
So that is my log :
pvic@ses:~ > pslq
stoage
bash: pslq: command not
found
pvic@ses:~ > psql
storage
Welcome to the POSTGRESQL interactive sql
monitor:
Please read the file COPYRIGHT for copyright terms of
POSTGRESQL
[PostgreSQL 7.0.2 on i686-pc-linux-gnu, compiled by gcc
egcs-2.91.66]
type \? for help on slash
commands
type \q to
quit
type \g or terminate with semicolon to execute
query
You are currently connected to the database:
storage
storage=> select
ct1('ddd','ddd');
ERROR: plpgsql: cache lookup from pg_proc
failed
Can anyone tell me how correct this error and/or its my mistake
or PG bug ?
Thanks in advance.
Vic (AKA MorDoor)
Re: [HACKERS] 7.0.2 -> 7.0.3 problem - anyone? - Fixed!
"Mitch Vincent" <[EMAIL PROTECTED]> writes: > It wasn't PostgreSQL, it was me of course! > Seeing as it was so long ago, I forgot that the BLCKSZ on the production > server wasn't 32k, it was 31k (for whatever reason).. When I set the BLCKSZ > lower than that and tried to start the backend it told me that the database > was initialized with a BLCKSZ of 31k, strange that it didn't say that when I > compiled with a BLCKSZ of 32k but regardless of all that it was my stupidity > that was the problem, nothing more.. Hmm, there is a test specifically designed to catch this mistake in backend/access/transam/xlog.c: the initdb-time BLCKSZ is stored in pg_control, and we have if (ControlFile->blcksz != BLCKSZ) elog(STOP, "database was initialized with BLCKSZ %d,\n\tbut the backend was compiled with BLCKSZ %d.\n\tlooks like you need to initdb.", ControlFile->blcksz, BLCKSZ); But I haven't stress-tested it. From your report, it sounds like something may blow up before control gets to this point if the compiled BLCKSZ is larger than the value used by initdb :-( regards, tom lane
Re: [HACKERS] 7.0.2 -> 7.0.3 problem - anyone? - Fixed!
I said: > if (ControlFile->blcksz != BLCKSZ) > elog(STOP, "database was initialized with BLCKSZ %d,\n\tbut the backend was >compiled with BLCKSZ %d.\n\tlooks like you need to initdb.", ControlFile-> blcksz, BLCKSZ); > But I haven't stress-tested it. From your report, it sounds like > something may blow up before control gets to this point if the compiled > BLCKSZ is larger than the value used by initdb :-( Oh ... duh! Three statements before the above test, we read in the pg_control data with if (read(fd, ControlFile, BLCKSZ) != BLCKSZ) elog(STOP, "Read(\"%s\") failed: %d", ControlFilePath, errno); Now pg_control is only a one-block file anyway. So if it was written with a smaller BLCKSZ than the backend is expecting, the read() will indeed not read as many bytes as the code is expecting --- whereupon it fails with this not-so-informative error message instead of the one that would be useful. Easy to fix, now that we've had our noses rubbed in the problem. Thanks for the report, and sorry you were confused for awhile... regards, tom lane
[HACKERS] PHPBuilder article -- Postgres vs MySQL
Thought this may be of interest to some... http://www.phpbuilder.com/columns/tim20001112.php3 Michael Fork - CCNA - MCP - A+ Network Support - Toledo Internet Access - Toledo Ohio
Re: [HACKERS] 7.0.2 -> 7.0.3 problem - anyone?
I realize it's Sunday night and not many people will be checking their
email, however I must ask one final time before I take some drastic measures
(erasing the data directory and initdb 'ing, then restoring the data from
last night's backup, losing an entire day's worth of data) -- does anyone
have any ideas on how I might be able to fix the problems outlined below?
I'm nearly positive that I shouldn't have had to dump/restore or initdb
again, since I made the same changes on another machine with the same
databases, data and BLCKSZ (an upgrade to 7.0.3 without an initdb or
anything), which went flawlessly.
Thanks to anyone who could even offer a guess, I've guessed all I can and
none of my guesses have paid off.. BTW, one might be lead to believe that
this is a permission problem, it's not, I'm positive of that. The same user
was accessing the same file seconds before I upgraded, that and the fact
that I changed permissions to 777 all the way down the tree to make sure..
-Mitch
> You have to dump/initdb/reload if you change the block size. Simply
> recompiling is not going to work.
>
> Cheers...
>
>
> MikeA
>
> -Original Message-
> From: Mitch Vincent
> To: [EMAIL PROTECTED]
> Sent: 11-13-00 12:57 AM
> Subject: [HACKERS] 7.0.2 -> 7.0.3 problem
>
> I just upgraded to 7.0.3 and tried to start the backend like
>
> /usr/local/pgsql/bin/postmaster -B 256 -o '-S 10240 -s' -D
> /usr/local/pgsql/data -i > /usr/local/pgsql/postgres.log 2>&1 &
>
> .. as I've done with 7.0.2, it failed to start and got this in my
> postgresql.log :
>
> DEBUG: Data Base System is starting up at Sun Nov 12 18:20:04 2000
> FATAL 2: Read("/usr/local/pgsql/data/pg_control") failed: 2
> FATAL 2: Read("/usr/local/pgsql/data/pg_control") failed: 2
> Startup failed - abort
>
> The only compilation change I made was to increase BLCKSZ to 32k (which
> has
> been running in a production 7.0.2 environment for quite some time).
>
> So what's up? Just to make sure I made the permissions 777 all the way
> down
> to pg_control but it had no effect.
>
>
>
> Hmm, I just re-installed 7.0.2 and I get the same error with it -- not
> good.
>
> My development server, which is virtually the same, did fine when I
> installed 7.0.3 so I'm guessing it's not a problem across the board..
>
> I also notice in the log that it's
> Read("/usr/local/pgsql/data/pg_control")
> that's failing and when I move pg_control out of the way, it's Open()
> that
> fails..
>
> I did nothing but stop the postmaster, compile and install 7.0.3 and
> start
> the postmaster. then compiled and installed 7.0.2 again and all of the
> sudden the 7.0.2 or 7.0.3 backend doesn't start -- it makes no sense.
>
> As always, any help is appreciated. Thanks!
>
> -Mitch
>
Re: [HACKERS] 7.0.2 -> 7.0.3 problem - anyone?
Block size can not be changes without dump/reload. If you think it
worked once, you are wrong. Sorry. The page headers have to be written
at the start of every block.
[ Charset ISO-8859-1 unsupported, converting... ]
> I realize it's Sunday night and not many people will be checking their
> email, however I must ask one final time before I take some drastic measures
> (erasing the data directory and initdb 'ing, then restoring the data from
> last night's backup, losing an entire day's worth of data) -- does anyone
> have any ideas on how I might be able to fix the problems outlined below?
>
> I'm nearly positive that I shouldn't have had to dump/restore or initdb
> again, since I made the same changes on another machine with the same
> databases, data and BLCKSZ (an upgrade to 7.0.3 without an initdb or
> anything), which went flawlessly.
>
> Thanks to anyone who could even offer a guess, I've guessed all I can and
> none of my guesses have paid off.. BTW, one might be lead to believe that
> this is a permission problem, it's not, I'm positive of that. The same user
> was accessing the same file seconds before I upgraded, that and the fact
> that I changed permissions to 777 all the way down the tree to make sure..
>
> -Mitch
>
> > You have to dump/initdb/reload if you change the block size. Simply
> > recompiling is not going to work.
> >
> > Cheers...
> >
> >
> > MikeA
> >
> > -Original Message-
> > From: Mitch Vincent
> > To: [EMAIL PROTECTED]
> > Sent: 11-13-00 12:57 AM
> > Subject: [HACKERS] 7.0.2 -> 7.0.3 problem
> >
> > I just upgraded to 7.0.3 and tried to start the backend like
> >
> > /usr/local/pgsql/bin/postmaster -B 256 -o '-S 10240 -s' -D
> > /usr/local/pgsql/data -i > /usr/local/pgsql/postgres.log 2>&1 &
> >
> > .. as I've done with 7.0.2, it failed to start and got this in my
> > postgresql.log :
> >
> > DEBUG: Data Base System is starting up at Sun Nov 12 18:20:04 2000
> > FATAL 2: Read("/usr/local/pgsql/data/pg_control") failed: 2
> > FATAL 2: Read("/usr/local/pgsql/data/pg_control") failed: 2
> > Startup failed - abort
> >
> > The only compilation change I made was to increase BLCKSZ to 32k (which
> > has
> > been running in a production 7.0.2 environment for quite some time).
> >
> > So what's up? Just to make sure I made the permissions 777 all the way
> > down
> > to pg_control but it had no effect.
> >
> >
> >
> > Hmm, I just re-installed 7.0.2 and I get the same error with it -- not
> > good.
> >
> > My development server, which is virtually the same, did fine when I
> > installed 7.0.3 so I'm guessing it's not a problem across the board..
> >
> > I also notice in the log that it's
> > Read("/usr/local/pgsql/data/pg_control")
> > that's failing and when I move pg_control out of the way, it's Open()
> > that
> > fails..
> >
> > I did nothing but stop the postmaster, compile and install 7.0.3 and
> > start
> > the postmaster. then compiled and installed 7.0.2 again and all of the
> > sudden the 7.0.2 or 7.0.3 backend doesn't start -- it makes no sense.
> >
> > As always, any help is appreciated. Thanks!
> >
> > -Mitch
> >
>
>
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] 7.0.2 -> 7.0.3 problem - anyone?
I think I might have explained this wrong..
Ok, both databases had a BLCKSZ of 32k before the upgrade (in 7.0.2), one
database that I upgraded first to 7.0.3 went flawlessly, it started, I can
do every operation fine and it's BLCKSZ is 32k (so the BLCKSZ never changed
between the installs, it is exactly as it was before).. I used the exact
same procedure for my production database and it doesn't start..
If I have to dump and reload in this situation, that's fine.. You absolutely
know more than I do about PostgreSQL but I know what I did on the
development machine and it didn't have these problems -- that's why I didn't
think any dump and/or reload was needed...
When I went back to 7.0.2, I shouldn't have had to dump and restore, should
I? I never did an initdb on the 7.0.3 installation so the data (and
virtually everything else as far as data is concerned was the same as when I
was running 7.0.2
Knowing all the above, do you still think a dump and reload was required? If
so that's fine, I just need to know..
-Mitch
- Original Message -
From: "Bruce Momjian" <[EMAIL PROTECTED]>
To: "Mitch Vincent" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Sunday, November 12, 2000 6:34 PM
Subject: Re: [HACKERS] 7.0.2 -> 7.0.3 problem - anyone?
> Block size can not be changes without dump/reload. If you think it
> worked once, you are wrong. Sorry. The page headers have to be written
> at the start of every block.
>
>
> [ Charset ISO-8859-1 unsupported, converting... ]
> > I realize it's Sunday night and not many people will be checking their
> > email, however I must ask one final time before I take some drastic
measures
> > (erasing the data directory and initdb 'ing, then restoring the data
from
> > last night's backup, losing an entire day's worth of data) -- does
anyone
> > have any ideas on how I might be able to fix the problems outlined
below?
> >
> > I'm nearly positive that I shouldn't have had to dump/restore or initdb
> > again, since I made the same changes on another machine with the same
> > databases, data and BLCKSZ (an upgrade to 7.0.3 without an initdb or
> > anything), which went flawlessly.
> >
> > Thanks to anyone who could even offer a guess, I've guessed all I can
and
> > none of my guesses have paid off.. BTW, one might be lead to believe
that
> > this is a permission problem, it's not, I'm positive of that. The same
user
> > was accessing the same file seconds before I upgraded, that and the fact
> > that I changed permissions to 777 all the way down the tree to make
sure..
> >
> > -Mitch
> >
> > > You have to dump/initdb/reload if you change the block size. Simply
> > > recompiling is not going to work.
> > >
> > > Cheers...
> > >
> > >
> > > MikeA
> > >
> > > -Original Message-
> > > From: Mitch Vincent
> > > To: [EMAIL PROTECTED]
> > > Sent: 11-13-00 12:57 AM
> > > Subject: [HACKERS] 7.0.2 -> 7.0.3 problem
> > >
> > > I just upgraded to 7.0.3 and tried to start the backend like
> > >
> > > /usr/local/pgsql/bin/postmaster -B 256 -o '-S 10240 -s' -D
> > > /usr/local/pgsql/data -i > /usr/local/pgsql/postgres.log 2>&1 &
> > >
> > > .. as I've done with 7.0.2, it failed to start and got this in my
> > > postgresql.log :
> > >
> > > DEBUG: Data Base System is starting up at Sun Nov 12 18:20:04 2000
> > > FATAL 2: Read("/usr/local/pgsql/data/pg_control") failed: 2
> > > FATAL 2: Read("/usr/local/pgsql/data/pg_control") failed: 2
> > > Startup failed - abort
> > >
> > > The only compilation change I made was to increase BLCKSZ to 32k
(which
> > > has
> > > been running in a production 7.0.2 environment for quite some time).
> > >
> > > So what's up? Just to make sure I made the permissions 777 all the way
> > > down
> > > to pg_control but it had no effect.
> > >
> > >
> > >
> > > Hmm, I just re-installed 7.0.2 and I get the same error with it -- not
> > > good.
> > >
> > > My development server, which is virtually the same, did fine when I
> > > installed 7.0.3 so I'm guessing it's not a problem across the board..
> > >
> > > I also notice in the log that it's
> > > Read("/usr/local/pgsql/data/pg_control")
> > > that's failing and when I move pg_control out of the way, it's Open()
> > > that
> > > fails..
> > >
> > > I did nothing but stop the postmaster, compile and install 7.0.3 and
> > > start
> > > the postmaster. then compiled and installed 7.0.2 again and all of the
> > > sudden the 7.0.2 or 7.0.3 backend doesn't start -- it makes no sense.
> > >
> > > As always, any help is appreciated. Thanks!
> > >
> > > -Mitch
> > >
> >
> >
>
>
> --
> Bruce Momjian| http://candle.pha.pa.us
> [EMAIL PROTECTED] | (610) 853-3000
> + If your life is a hard drive, | 830 Blythe Avenue
> + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
>
Re: [HACKERS] 7.0.2 -> 7.0.3 problem - anyone?
[ Charset ISO-8859-1 unsupported, converting... ] > I think I might have explained this wrong.. > > Ok, both databases had a BLCKSZ of 32k before the upgrade (in 7.0.2), one > database that I upgraded first to 7.0.3 went flawlessly, it started, I can > do every operation fine and it's BLCKSZ is 32k (so the BLCKSZ never changed > between the installs, it is exactly as it was before).. I used the exact > same procedure for my production database and it doesn't start.. > > If I have to dump and reload in this situation, that's fine.. You absolutely > know more than I do about PostgreSQL but I know what I did on the > development machine and it didn't have these problems -- that's why I didn't > think any dump and/or reload was needed... > > When I went back to 7.0.2, I shouldn't have had to dump and restore, should > I? I never did an initdb on the 7.0.3 installation so the data (and > virtually everything else as far as data is concerned was the same as when I > was running 7.0.2 > > Knowing all the above, do you still think a dump and reload was required? If > so that's fine, I just need to know.. You are correct. It does not need a dump/restore. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] 7.0.2 -> 7.0.3 problem - anyone? - Fixed!
It wasn't PostgreSQL, it was me of course! Seeing as it was so long ago, I forgot that the BLCKSZ on the production server wasn't 32k, it was 31k (for whatever reason).. When I set the BLCKSZ lower than that and tried to start the backend it told me that the database was initialized with a BLCKSZ of 31k, strange that it didn't say that when I compiled with a BLCKSZ of 32k but regardless of all that it was my stupidity that was the problem, nothing more.. My apologies for wasting everyone's time, file this problem in the "stupid user" category. Thanks to all, I'm off to sit in the corner for a while... -Mitch - Original Message - From: "Bruce Momjian" <[EMAIL PROTECTED]> To: "Mitch Vincent" <[EMAIL PROTECTED]> Sent: Sunday, November 12, 2000 6:47 PM Subject: Re: [HACKERS] 7.0.2 -> 7.0.3 problem - anyone? > Quite strange. There isn't much in 7.0.3 that would cause that. > > > [ Charset ISO-8859-1 unsupported, converting... ] > > > > > You are correct. It does not need a dump/restore. > > > > Excellent, my apologies for not being clear before... Do you have any other > > ideas as to what might have caused this problem? > > > > -Mitch > > > > > > > -- > Bruce Momjian| http://candle.pha.pa.us > [EMAIL PROTECTED] | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 >
[HACKERS] [RELEASE ANNOUNCEMENT] v7.0.3 *Final* now Available
After a couple of pre-release tarballs, the PostgreSQL Developers are proud to announce v7.0.3, our most stable release yet. There have been *several* fixes in this release, from v7.0.2, but, being a minor release, there have been *no* changes that will require a dump/restore to happen ... download the source, compile it and plug-n-play ... Due to a last minute fix of a bug by Tom Lane that prevents a crash of the backend, it is recommended that if you have downloaded one of the pre-release 7.0.3 tarballs, you download this version and upgrade, to be sure you have the fix. If anyone has any problems, please report bugs to [EMAIL PROTECTED], or submit a but through our handy web interface available at http://www.postgresql.org ... Changes --- Jdbc fixes (Peter) Large object fix (Tom) Fix lean in COPY WITH OIDS leak (Tom) Fix backwards-index-scan (Tom) Fix SELECT ... FOR UPDATE so it checks for duplicate keys (Hiroshi) Add --enable-syslog to configure (Marc) Fix abort transaction at backend exit in rare cases (Tom) Fix for psql \l+ when multi-byte enabled (Tatsuo) Allow PL/pgSQL to accept non ascii identifiers (Tatsuo) Make vacuum always flush buffers (Tom) Fix to allow cancel while waiting for a lock (Hiroshi) Fix for memory aloocation problem in user authentication code (Tom) Remove bogus use of int4out() (Tom) Fixes for multiple subqueries in COALESCE or BETWEEN (Tom) Fix for failure of triggers on heap open in certain cases (Jeroen van Vianen) Fix for erroneous selectivity of not-equals (Tom) Fix for erroneous use of strcmp() (Tom) Fix for bug where storage manager accesses items beyond end of file (Tom) Fix to include kernel errno message in all smgr elog messages (Tom) Fix for '.' not in PATH at build time (SL Baur) Fix for out-of-file-descriptors error (Tom) Fix to make pg_dump dump 'iscachable' flag for functions (Tom) Fix for subselect in targetlist of Append node (Tom) Fix for mergejoin plans (Tom) Fix TRUNCATE failure on relations with indexes (Tom) Avoid database-wide restart on write error (Hiroshi) Fix nodeMaterial to honor chgParam by recomputing its output (Tom) Fix VACUUM problem with moving chain of update tuples when source and destination of a tuple lie on the same page (Tom) Fix user.c CommandCounterIncrement (Tom) Fix for AM/PM boundary problem in to_char() (Karel Zak) Fix TIME aggregate handling (Tom) Fix to_char() to avoid coredump on NULL input (Tom) Buffer fix (Tom) Fix for inserting/copying longer multibyte strings into char() data types (Tatsuo) Fix for crash of backend, on abort (Tom)
