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.
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,
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
***
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
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
* 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
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
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 21
.. as I've done with 7.0.2, it failed to start and got this in my
postgresql.log :
DEBUG: Data Base System is
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
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
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
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
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
[ 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
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
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 ...
16 matches
Mail list logo
