Re: [HACKERS] Detecting corrupted pages earlier

2003-02-18 Thread Kevin Brown
Tom Lane wrote:
 The cases I've been able to study look like the header and a lot of the
 following page data have been overwritten with garbage --- when it made
 any sense at all, it looked like the contents of non-Postgres files (eg,
 plain text), which is why I mentioned the possibility of disks writing
 data to the wrong sector.

That also sounds suspiciously like the behavior of certain filesystems
(Reiserfs, for one) after a crash when the filesystem prior to the
crash was highly active with writes.  Had the sites that reported this
experienced OS crashes or power interruptions?


-- 
Kevin Brown   [EMAIL PROTECTED]

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



Re: [HACKERS] Group by, count, order by and limit

2003-02-18 Thread Christoph Haller

 Consider this query on a large table with lots of different IDs:

 SELECT id FROM my_table GROUP BY id ORDER BY count(id) LIMIT 10;

 It has an index on id.  Obviously, the index helps to evaluate
count(id)
 for a given value of id, but count()s for all the `id's should be
 evaluated, so sort() will take most of the time.

 Is there a way to improve performance of this query?  If not, please
 give some indication to do a workaround on the source itself, so
perhaps
 I may be able to come out with a patch.

Is there a difference in performance if you re-write it as

SELECT id, count(id) FROM my_table GROUP BY id ORDER BY 2 LIMIT 10 ;

?

Regards, Christoph



---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly



Re: [HACKERS] pg environment? metadata?

2003-02-18 Thread Christoph Haller
 
  I was wondering what kind of functions/constants exist in Postgre to
dig
 up
  metadata. I barely scratched the surface of Oracle but I know you
find
  things like user_tables there that can be used to extract info about
your
  tables. What I'm looking for is some kind of functions to extract
column
  names, possibly data types, etc. And by that I don't mean console
 commands,
  sql statements that will do the job with tcp/ip.
 
  Moreover, are there any ANSI standards for this kind of thing? Or
each one
  to his own?
 
Refer to the System Catalogs chapter within the Developer's Guide
section
of the documentation. In addition, if you start a psql session with the
-E option,
you will see how all these \d commands are generated.
I would love to hear there is a standard about system catalogs, but I've
never heard
of one and I doubt there will be one ever in the future.

Regards, Christoph



---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly



Re: [HACKERS] pg environment? metadata?

2003-02-18 Thread Bruno Wolff III
On Tue, Feb 18, 2003 at 13:13:30 +0100,
  Christoph Haller [EMAIL PROTECTED] wrote:
  
   Moreover, are there any ANSI standards for this kind of thing? Or
 each one
   to his own?

Based on discussions in the past that I have loosely followed, I believe
there is some kind of standard and that views implementing some of this
standard are slated to go into 7.4.

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly



Re: [HACKERS] Brain dump: btree collapsing

2003-02-18 Thread Curtis Faith
 tom lane wrote:
  Hm.  A single lock that must be grabbed for operations anywhere in 
  the index is a concurrency bottleneck.

I replied a bit later: 
 I don't think it would be that bad.  It's not a lock but a
 mutex that would only be held for relatively brief duration. 
 It looks like tens or a few hundred instructions at most 
 covered by the mutex and only during scans that cross page boundaries.
 
 Unless you were talking about a 16 to 64 way SMP box, I don't
 think there would be much actual contention since there would 
 have to be contention for the same index at the same time and 
 depending on the number of keys per page, very little of the 
 run time is spent on the lock transition for traversal across 
 pages as compared to all the other stuff that would be going on.


tom also presciently wrote:
 But maybe we could avoid that

After sleeping on it a bit, it occurs to me that you are again correct;
the mutex is not required to do what I suggested. It is simply a matter
of assuring that during the page traversal the lock is either obtained
or the process added to the waiters queue before the current page lock
is released. This will ensure than any process trying to obtain an
exclusive or superexclusive lock will wait or fail an immediate lock
acquisition.


traversal pseudo code:

if the next page lock can be obtained immediately

grab it

release the current page lock

else if we would have to wait

add current process to waiters queue

release current page lock

sleep on the lock

end if

end traversal pseudo code


Like the current release before next page acquisition method, this won't
cause deadlocks with other scanners going in the opposite direction or
with concurrently inserting processes since the current page lock is
released before sleeping.

If this change is made then my original suggestion, that the merge
process attempt a non-deadlocking acquisition of all the locks with a
drop of all locks and a retry if any of the attempts would have caused a
wait, should work fine.

If the traversal code is changed as per above, a merging VACUUM process
is guaranteed to either run into the lock held by the scanning process
on the current page or the next page.

This has the potential side benefit of permitting the simplification of
the scan code in the case where the lock is obtained immediately. Since
the scanning process would know that no inserting process has added
pages to the tree because of a split, it wouldn't have to check for
newly inserted pages to the right of the next page. I don't know how
much work is involved in this check but if it is significant it could be
eliminated in this case, one which is the most likely case in many
scenarios.

What do you think?

- Curtis




---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



Re: [HACKERS] pg environment? metadata?

2003-02-18 Thread Christopher Kings-Lynne
 On Tue, Feb 18, 2003 at 13:13:30 +0100,
   Christoph Haller [EMAIL PROTECTED] wrote:
   
Moreover, are there any ANSI standards for this kind of thing? Or
  each one
to his own?

 Based on discussions in the past that I have loosely followed, I believe
 there is some kind of standard and that views implementing some of this
 standard are slated to go into 7.4.

Well, if you're referring to the standard INFORMATION_SCHEMA, it is
already in 7.4 and it is standard.  You can't inspect it to find out
postgres-specific information tho.  You can actually grab the
information_schema.sql from 7.4 CVS and install it into 7.3 to create a
new 'information_schema' quite happily though.

Regards,

Chris



---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



Re: [HACKERS] Detecting corrupted pages earlier

2003-02-18 Thread Tom Lane
Kevin Brown [EMAIL PROTECTED] writes:
 Tom Lane wrote:
 The cases I've been able to study look like the header and a lot of the
 following page data have been overwritten with garbage --- when it made
 any sense at all, it looked like the contents of non-Postgres files (eg,
 plain text), which is why I mentioned the possibility of disks writing
 data to the wrong sector.

 That also sounds suspiciously like the behavior of certain filesystems
 (Reiserfs, for one) after a crash when the filesystem prior to the
 crash was highly active with writes.

Isn't reiserfs supposed to be more crash-resistant than ext2, rather
than less so?

 Had the sites that reported this
 experienced OS crashes or power interruptions?

Can't recall whether they admitted to such or not.

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



Re: FW: [HACKERS] Changing the default configuration (was Re:

2003-02-18 Thread Justin Clift
Hi everyone,

Just looked on the IBM website for info relating to shared memory and 
IPC limits in AIX, and found a few useful-looking documents:

The Interprocess Communication (IPC) Overview
http://www-1.ibm.com/support/docview.wss?rs=0context=SWG10q=shmgetuid=aix15f11dd1d98f3551f85256816006a001dloc=en_UScs=utf-8cc=uslang=en#1.1
This document defines the interprocess communication (IPC) and is 
applicable to AIX versions 3.2.x and 4.x.

Lots of the stuff here is very intro-level, but some still looks useful.


vmtune Parameters
http://www-1.ibm.com/support/docview.wss?rs=0context=SWG10q=shmgetuid=aix16934e2f123d4ab3785256816006a0252loc=en_UScs=utf-8cc=uslang=en
This document discusses the vmtune  command used to modify the Virtual 
Memory Manager (VMM) parameters that control the behavior of the memory 
management subsystem. This information applies to AIX Versions 4.x.


And an obscure reference to the AIX shmget(2) manpage says that there is 
a non-tunable maximum shared-memory segment size of 256MB:

http://www.unidata.ucar.edu/packages/mcidas/780/mcx/workstation.html#aix

Hope some of this is useful.

Regards and best wishes,

Justin Clift

--
My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there.
- Indira Gandhi


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


[HACKERS] [Fwd: [postgis-users] Postgis-0.7.4 + PSQL-7.3.1- installation]

2003-02-18 Thread Paul Ramsey
Hi guys,
There seems to be quite a laundry list of things which have to be 
patched or otherwise massaged in order to get a cygwin build. Did these 
get fixed before 7.3.2 rolled out the door?
Paul



 Original Message 
Subject: [postgis-users] Postgis-0.7.4 + PSQL-7.3.1- installation
Date: Tue, 18 Feb 2003 15:58:35 +0100
From: Barbara Olga Kastelliz [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED],	PostGIS Users Discussion 
[EMAIL PROTECTED]
To: 'PostGIS Users Discussion' [EMAIL PROTECTED]

Hello,
I have recently installed postgresql-7.3.1 with postgis-0.7.4,
on Windows 2000. Many thanks to the archiv and the group.
what had to be done, can be found in the archiv, but in different mails.

1. file: pstgresql/src/include/optimizer/cost.h: DLLIMPORT has to be 
added in
line:
extern DLLIMPORT double cpu_index_tuple_cost

2. compiling of postgresql:
postgresql-7.2.3-gcc3.patch
applying the patch with the executable patch is not necessary, the files
	/usr/share/postgresql/src/makefiles/Makefile.win	and
	/usr/share/postgresql/src/template/win to
 have to look like that: (archiv, mail form Assefa Yewondwossen, Jan 9th,
2003):

# $Header: /cvsroot/pgsql-server/src/makefiles/Makefile.win,v 1.18 
2002/09/05
18:28:46 petere Exp $
LDFLAGS+= -g
DLLTOOL= dlltool
DLLWRAP= dllwrap
DLLLIBS= -L/usr/local/lib -lcygipc -lcrypt
BE_DLLLIBS= -L$(top_builddir)/src/backend -lpostgres
DLLINIT = $(top_builddir)/src/utils/dllinit.o
MK_NO_LORDER=true
MAKE_DLL=true
# linking with -lm or -lc causes program to crash
# (see http://sources.redhat.com/cygwin/faq/faq.html#SEC110)
LIBS:=$(filter-out -lm -lc, $(LIBS))

AROPT = crs
DLSUFFIX = .dll
CFLAGS_SL =

%.dll: %.o
	$(DLLTOOL) --export-all --output-def $*.def $
	$(DLLWRAP) -o $@ --def $*.def $ $(DLLINIT) $(SHLIB_LINK)
	rm -f $*.def

ifneq (,$(findstring backend,$(subdir)))
ifeq (,$(findstring conversion_procs,$(subdir)))
override CPPFLAGS+= -DBUILDING_DLL
endif
endif

ifneq (,$(findstring ecpg/lib,$(subdir)))
override CPPFLAGS+= -DBUILDING_DLL
endif

# required by Python headers
ifneq (,$(findstring src/pl/plpython,$(subdir)))
override CPPFLAGS+= -DUSE_DL_IMPORT
endif



#file: /usr/share/postgresql/src/template/win:

CFLAGS=-O2
SRCH_LIB=/usr/local/lib
LIBS=-lcygipc



next: configuring postgresql with:

$ LDFLAGS=-L/usr/local/lib ./configure --enable-multibyte
--with-CXX --with-perl --prefix=/usr --sysconfdir=/etc
--docdir=/usr/doc/postgresql-$version

I have no idea, if --with-perl is necessary, but
without it, I was not able to compile postgresql because I got the Error,
not able to make executables.
to the /etc directory I added the folder postgresql, there I copied
libpostgis.a and libpostgres.a,
maybe it had no effect on the result?
$ make

3.) Postgis installation

in the postgis makefile this line had to be added:
SHLIB_LINK := $(LDFLAGS) ../../src/backend/libpostgres.a
makefile:
.
#---
# Add libraries that libpq depends (or might depend) on into the
# shared library link.  (The order in which you list them here doesn't
# matter.)

# next line added
SHLIB_LINK := $(LDFLAGS) ../../src/backend/libpostgres.a
#---



$ make
$ make install

in the resulting file postgis.sql I had to replace:
$libdir/postgis.dll
with the absolute path to the postgis.dll file:
/usr/share/postgresql/contrib/postgis/postgis.dll
again I don't know wether this was because of a misconfiguration in my case,
or if this occurs more often, but it worked.

hope this will help somebody,
greetings,
barbara



___
postgis-users mailing list
[EMAIL PROTECTED]
http://postgis.refractions.net/mailman/listinfo/postgis-users



---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html


Re: [HACKERS] location of the configuration files

2003-02-18 Thread scott.marlowe
On Sat, 15 Feb 2003, Curt Sampson wrote:

 On Fri, 14 Feb 2003, scott.marlowe wrote:
 
  Asking for everything in a directory with the name local in it to be
  shared is kind of counter intuitive to me.
 
 Not really. If you install a particular program that doesn't come with
 the OS on one machine on your site, why would you not want to install it
 separately on all of the others?
 
 Typically, I want my favourite non-OS utilities on all machines, not
 just one. (Even if I don't use them on all machines.) Thus /usr/local is
 for site-local stuff.

Good point.  Of course, in apache, it's quite easy to use the -f switch to 
pick the file you're running on.  so, with a 

httpd -f /usr/local/apache/conf/`uname -a|cut -d   -f 2`.conf

I can pick and choose the file to run.  So, yes, I would gladly use it in 
a cluster, and all the files would be in one place, easy to backup.


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly



[HACKERS] New Feature - Project

2003-02-18 Thread afterz
Hello.
I am a student of Tuiuti University and I want to develop a
project with PostgreSQL.

My idea is to create clients for PostgreSQL that receive
messages from the server(PostgreSQL) according to events
occured into the database.
At this point I just tought that these events could be like
triggers.

For doing that I want to create a new task into PostgreSQL
to test the rules determined by the users and send them
messages it's required.

When and what data to be sent the user would tell,
according to the rules...
It is like bringing the information to the user.

Is it possible, and will I be able to do it in a short
time?

Thanks.
Ricardo K. Costa


Don't E-Mail, ZipMail! http://www.zipmail.com/

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org



Re: [HACKERS] deadlock in REINDEX

2003-02-18 Thread Olleg Samoylov
On Tue, 18 Feb 2003, Gavin Sherry wrote:

GSPerhaps the change that needs to be made is:
GS
GSif(IsUnderPostmaster)
GS elog(ERROR,You cannot run REINDEX INDEX in multi-user mode);
GS
GSto ReindexIndex() or some other appropriate place (with a better error
GSmessage).
GS
GSGavin

It is incorrect. In PostgreSQL REINDEX must be routing (PostgreSQL 7.3.1
Documentation 8.3. Routine Reindexing).

-- 
Olleg Samoylov


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



Re: [HACKERS] function to return pg_user.usesysid

2003-02-18 Thread Olleg Samoylov
Hi all,

Also need add function, returned GetSessionUserId() too.

On 7 Feb 2003, Dr. Ernst Molitor wrote:

DEMrecord offers saving a few bytes per record, so I wrote a _very small_
DEMadd-on to directly access the usesysid information, using the function
DEMGetUserId().

-- 
Olleg Samoylov


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org



Re: [HACKERS] Detecting corrupted pages earlier

2003-02-18 Thread Greg Copeland
On Mon, 2003-02-17 at 22:04, Tom Lane wrote:
 Curt Sampson [EMAIL PROTECTED] writes:
  On Mon, 17 Feb 2003, Tom Lane wrote:
  Postgres has a bad habit of becoming very confused if the page header of
  a page on disk has become corrupted.
 
  What typically causes this corruption?
 
 Well, I'd like to know that too.  I have seen some cases that were
 identified as hardware problems (disk wrote data to wrong sector, RAM
 dropped some bits, etc).  I'm not convinced that that's the whole story,
 but I have nothing to chew on that could lead to identifying a software
 bug.
 
  If it's any kind of a serious problem, maybe it would be worth keeping
  a CRC of the header at the end of the page somewhere.
 
 See past discussions about keeping CRCs of page contents.  Ultimately
 I think it's a significant expenditure of CPU for very marginal returns
 --- the layers underneath us are supposed to keep their own CRCs or
 other cross-checks, and a very substantial chunk of the problem seems
 to be bad RAM, against which occasional software CRC checks aren't 
 especially useful.

This is exactly why magic numbers or simple algorithmic bit patterns
are commonly used.  If the magic number or bit pattern doesn't match
it's page number accordingly, you know something is wrong.  Storage cost
tends to be slightly and CPU overhead low.

I agree with you that a CRC is seems overkill for little return.

Regards,

-- 
Greg Copeland [EMAIL PROTECTED]
Copeland Computer Consulting


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org



Re: [HACKERS] psql and readline

2003-02-18 Thread Ross J. Reedstrom
On Sat, Feb 15, 2003 at 03:10:19PM -0600, Ross J. Reedstrom wrote:
 On Fri, Feb 14, 2003 at 11:32:02AM -0500, Tom Lane wrote:
  Patrick Welche [EMAIL PROTECTED] writes:
   On Thu, Feb 13, 2003 at 10:25:52AM -0500, Tom Lane wrote:
   Well, is that a bug in your wrapper?  Or must we add a configure test
   for the presence of replace_history_entry()?
  
   Good question. Easiest for now for me would be add a configure test.
  
  Okay with me --- Ross, can you handle that?

O.K., I found the 'editline' wrapper around 'libedit' that provides
a subset of readline functionality, and used that for testing. On my
Debian Linux systems, editline installs readline compatability headers
(readline.h, history.h) into /usr/include/editline/, so I added tests
for those into configure.in, and src/include/pg_config.h.in, and usage
in src/bin/psql/input.h

I added a test for replace_history_entry() to configure.in, and usage
of it to src/bin/psql/command.c. As you may recall, the original purpose
of this patch was to deal with the interaction of '\e' with the history
buffer.  I implemented replacing the '\e' entry in the buffer with the
query as returned by the edit session and sent to the backend. If the
replace_history_entry function is missing, I now just push the edited
entry onto the history stack, leaving the '\e' in place as well.

Tested on systems with readline, editline, and --without-readline.

Since the patch has now grown to 25 lines, I've posted it over to PATCHES.

Ross

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html



Re: [HACKERS] psql and readline

2003-02-18 Thread Ross J. Reedstrom
On Mon, Feb 17, 2003 at 12:05:20AM +0100, Peter Eisentraut wrote:
 Ross J. Reedstrom writes:
 
 I don't think this is what we were out for.  We've certainly been running
 with libedit for a long time without anyone ever mentioning
 /usr/include/editline.  I suggest this part is taken out.

Well, I found a set of systems that install libedit (and editline) in that
location (i.e. Debian Linux). I couldn't test on the standard version of
that system without either this, or hacking a symlink into /usr/include.

Yes, BSD systems that install libedit directly in /usr/include (or into
readline), like Patrick's,  don't need it, but mine do. Is there some
reason we _shouldn't_ support this configuration?

Ross

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



[HACKERS] Group by count() and indexes

2003-02-18 Thread Anuradha Ratnaweera

Consider the following query on a large table with lots of different
`id's:

SELECT id FROM my_table GROUP BY id ORDER BY count(id) LIMIT 10;

It has an (usually unique) index on id.  Obviously, the index helps to
evaluate count(id) for a given value of id, but count()s for all the
`id's should be evaluated, so sort() will take most of the time.

Is there a way to improve performance of this query?  If not, please
give some indication to do a workaround on the source itself, so perhaps
I may be able to work out a patch.

Thanks in advance.

Anuradha

-- 

Debian GNU/Linux (kernel 2.4.21-pre4)

It is contrary to reasoning to say that there is a vacuum or space in
which there is absolutely nothing.
-- Descartes


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



[HACKERS] PGRPROC

2003-02-18 Thread Sumaira Ali
if pgproc is used to represent a process and proclock represents a process and its locks of interest, then why does pgproc contain the following information about locks?

/*
* XLOG location of first XLOG record written by this backend's
* current transaction. If backend is not in a transaction or hasn't
* yet modified anything, logRec.xrecoff is zero.
*/
XLogRecPtr logRec;
/* Info about LWLock the process is currently waiting for, if any. */
bool lwWaiting; /* true if waiting for an LW lock */
bool lwExclusive; /* true if waiting for exclusive access */
struct PGPROC *lwWaitLink; /* next waiter for same LW lock */
/* Info about lock the process is currently waiting for, if any. */
/* waitLock and waitHolder are NULL if not currently waiting. */
LOCK *waitLock; /* Lock object we're sleeping on ... */
PROCLOCK *waitHolder; /* Per-holder info for awaited lock */
LOCKMODE waitLockMode; /* type of lock we're waiting for */
LOCKMASK heldLocks; /* bitmask for lock types already held on
* this lock object by this backend */
SHM_QUEUE procHolders; /* list of PROCLOCK objects for locks held
* or awaited by this backend */
};MSN 8 with e-mail virus protection service:  2 months FREE*


[HACKERS] [Fwd: [JDBC] 7.3.2 psql error!] GLIBC_2.3 not found

2003-02-18 Thread Dave Cramer
I received this in my inbox, can anyone comment on it

-Forwarded Message-

From: Felipe Schnack [EMAIL PROTECTED]
Subject: [JDBC] 7.3.2 psql  error!
Date: 18 Feb 2003 15:54:29 -0300

  I just compiled psql version 7.3.2 in a redhat 7.3 box and I get this
error:
  psql: /lib/i686/libc.so.6: version `GLIBC_2.3' not found (required by
psql)
  I have to update glibc? How? No rpms are avaliable, how the configure
script haven't detected this problem?
-- 

Felipe Schnack
Analista de Sistemas
[EMAIL PROTECTED]
Cel.: (51)91287530
Linux Counter #281893

Centro Universitário Ritter dos Reis
http://www.ritterdosreis.br
[EMAIL PROTECTED]
Fone/Fax.: (51)32303341


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org
-- 
Dave Cramer [EMAIL PROTECTED]
Cramer Consulting


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



Re: [HACKERS] Version 7.2.3 Vacuum abnormality

2003-02-18 Thread Andrew Sullivan
On Mon, Feb 17, 2003 at 05:42:21PM -0500, Tom Lane wrote:
 Andrew Sullivan [EMAIL PROTECTED] writes:
  On Thu, Feb 13, 2003 at 03:27:01PM +1000, Paul L Daniels wrote:
 
  http://archives.postgresql.org/pgsql-hackers/2002-11/msg00486.php
 
 The mechanism I described in the above-referenced message only occurs
 for nailed-in-cache system tables.  Given Daniels' report (and one or

And for ones that have been truncated?  I found this reference:

http://groups.google.ca/groups?hl=enlr=ie=UTF-8threadm=200301251026.14193.mallah%40trade-india.comrnum=5prev=/groups%3Fq%3DUninitialized%2Bpage%2Bgroup:comp.databases.postgresql.*%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3D200301251026.14193.mallah%2540trade-india.com%26rnum%3D5

(Sorry about the long line.  I'm still having no luck with
archives.postgresql.org).

A

-- 

Andrew Sullivan 204-4141 Yonge Street
Liberty RMS   Toronto, Ontario Canada
[EMAIL PROTECTED]  M2P 2A8
 +1 416 646 3304 x110


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



Re: [HACKERS] Detecting corrupted pages earlier

2003-02-18 Thread Tom Lane
Hiroshi Inoue [EMAIL PROTECTED] writes:
 Tom Lane wrote:
 I'm thinking of modifying ReadBuffer() so that it errors out if the

 What does the *error out* mean ?

Mark the buffer as having an I/O error and then elog(ERROR).

 Is there a way to make our way around the pages ?

If the header is corrupt, I don't think so.  You'd need at the very
least to fix the bad header fields (particularly pd_lower) before you
could safely try to examine tuples.  (In the cases that I've seen,
some or all of the line pointers are clobbered too, making it even less
likely that any useful data can be extracted automatically.)

Basically I'd rather have accesses to the clobbered page fail with
elog(ERROR) than with more drastic errors.  Right now, the least
dangerous result you are likely to get is elog(FATAL) out of the clog
code, and you can easily get a PANIC or backend coredump instead.

 IMHO CRC isn't sufficient because CRC could be calculated
 even for (silently) corrupted pages.

Yeah, it seems a great expense for only marginal additional protection.

regards, tom lane

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly



Re: [HACKERS] Version 7.2.3 Vacuum abnormality

2003-02-18 Thread Tom Lane
Andrew Sullivan [EMAIL PROTECTED] writes:
 On Mon, Feb 17, 2003 at 05:42:21PM -0500, Tom Lane wrote:
 The mechanism I described in the above-referenced message only occurs
 for nailed-in-cache system tables.  Given Daniels' report (and one or

 And for ones that have been truncated?  I found this reference:

 
http://groups.google.ca/groups?hl=enlr=ie=UTF-8threadm=200301251026.14193.mallah%40trade-india.comrnum=5prev=/groups%3Fq%3DUninitialized%2Bpage%2Bgroup:comp.databases.postgresql.*%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3D200301251026.14193.mallah%2540trade-india.com%26rnum%3D5

Sigh, I must be losing brain cells faster than I thought.  I completely
forgot about the TRUNCATE version of the problem.

Of course, if the complainant hasn't done TRUNCATE either, then we may
still have an issue ...

regards, tom lane

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly



[HACKERS] Real-world usage example

2003-02-18 Thread Bruce Badger
I use a version control system called StORE which uses a relational
database as it's back end.  I use StORE with PostgreSQL, others use it
with DB2, Oracle, etc 

I mention StORE here because it struck me that it may be a useful source
of real-world information about how PostgreSQL performs relative to
other DBMSs.  StORE databases all use the same Schema, and some are
replicated such that they contain the same data too.

PostgreSQL is the most popular database for StORE users, and is used for
a central Smalltalk community repository (StORE is a Smalltalk specific
version control system).  The public StORE repository is accessed across
the Internet by people with Modems, WiFi, T1 and LAN connections.

There have been a number of people comment on how PostgreSQL performs as
a StORE repository - some good comments, some not so good.  Either way,
given the varied use of StORE, the feedback may yield valuable
information.

The place to look for feedback from StORE users is the news group
comp.lang.smalltalk.  For example:
http://groups.google.com/groups?q=postgres+group:comp.lang.smalltalkhl=enlr=ie=UTF-8oe=UTF-8scoring=d

I hope this is useful.

All the best,
Bruce

BTW, I wrote the PostgreSQL driver for VisualWorks Smalltalk which is
how all StORE + PostgreSQL users access their databases.



---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



Re: [HACKERS] Real-world usage example

2003-02-18 Thread Justin Clift
Bruce Badger wrote:
snip

There have been a number of people comment on how PostgreSQL performs as
a StORE repository - some good comments, some not so good.  Either way,
given the varied use of StORE, the feedback may yield valuable
information.

The place to look for feedback from StORE users is the news group
comp.lang.smalltalk.  For example:
http://groups.google.com/groups?q=postgres+group:comp.lang.smalltalkhl=enlr=ie=UTF-8oe=UTF-8scoring=d

I hope this is useful.


Yep, it definitely is.  We're looking for places to be PostgreSQL Case 
Studies at present, so it's probably worth Carol Ioanni (CC'd, she's 
becoming our Case Study Expert) to join that mailing list and ask there.

Thanks heaps Bruce.

Regards and best wishes,

Justin Clift


All the best,
	Bruce

BTW, I wrote the PostgreSQL driver for VisualWorks Smalltalk which is
how all StORE + PostgreSQL users access their databases.


--
My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there.
- Indira Gandhi


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly



Re: [HACKERS] Hard problem with concurrency

2003-02-18 Thread Ron Mayer
Christopher Kings-Lynne wrote:

*sigh* It's just like a standard to come up with a totally new syntax for a
feature that no-one has except MySQL who use a different syntax :)

You sure? :)

   http://otn.oracle.com/products/oracle9i/daily/Aug24.html

 MERGE INTO SALES_FACT D
 USING SALES_JUL01 S
 ON (D.TIME_ID = S.TIME_ID
AND D.STORE_ID = S.STORE_ID
AND D.REGION_ID = S.REGION_ID)
 WHEN MATCHED THEN
UPDATE
 SET d_parts = d_parts + s_parts,
  d_sales_amt = d_sales_amt + s_sales_amt,
  d_tax_amt = d_tax_amt + s_tax_amt,
  d_discount = d_discount + s_discount
  WHEN NOT MATCHED THEN
 INSERT (D.TIME_ID ,D.STORE_ID ,D.REGION_ID,
D.PARTS ,D.SALES_AMT ,D.TAX_AMT ,D.DISCOUNT)
 VALUES (
S.TIME_ID ,S.STORE_ID ,S.REGION_ID,
S.PARTS ,S.SALES_AMT ,S.TAX_AMT ,S.DISCOUNT);

For those who last played with 8X, they have a couple of other
new features in 9i.  This is the best doc I saw talking about them.

 http://www.oracle-base.com/Articles/9i/SQLNewFeatures9i.asp



---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



Re: [HACKERS] psql and readline

2003-02-18 Thread Bruce Momjian
Ross J. Reedstrom wrote:
 On Wed, Feb 19, 2003 at 12:03:44AM +0100, Peter Eisentraut wrote:
  Ross J. Reedstrom writes:
  
   Yes, BSD systems that install libedit directly in /usr/include (or into
   readline), like Patrick's,  don't need it, but mine do. Is there some
   reason we _shouldn't_ support this configuration?
  
  I don't like adding code to support every configuration that someone
  dreamed up but no one actually needs.  Readline installs the header files
  into readline/readline.h and if someone thinks they can change that they
  deserve to pay the price.  The configure script is already slow enough
  without this.
 
 Hmm, isn't this exactly what configure is  for? To find out where this
 particular system installs all the bits and pieces? Note that even without
 the test for editline/readline.h, the existing configure looks in two
 placesi for readline functionality, so doesn't match your comment,
 above. As for 'someone changing that' paying the price, I think it's
 reasonable for an incomplete compatability library to install into a
 different location: if it claims to be readline/readline.h, it better
 support the entire API, in my book.
 
 Regardless of all of the above, I'm willing to let this part go. Note that
 I can no longer easily test libedit functionality in that case, however.
 I leave it up to Bruce (or whomever applies the patch)

Configure is for such tests --- you are right, and we already test two
places.  I doubt there is any measurable change in testing 10 locations.
Just allowing you to test libedit is enough to justify the addition.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly



[HACKERS] translation stats

2003-02-18 Thread Dennis Björklund
What is the translation stats on

  http://webmail.postgresql.org/~petere/nls.php

based on? I've not updated my translation in a long time (since 7.3.0)  
and it's still at 100% (except the big file that wasn't 100% before).  
Seems strange that there havn't been any new or changed strings since
then. Not that I'm complaining, no changes is nice :-)

-- 
/Dennis


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



Re: [HACKERS] Group by, count, order by and limit

2003-02-18 Thread Bruno Wolff III
On Tue, Feb 18, 2003 at 10:26:46 +0600,
  Anuradha Ratnaweera [EMAIL PROTECTED] wrote:
 
 My 3rd attempt to post ...
 
 Consider this query on a large table with lots of different IDs:
 
 SELECT id FROM my_table GROUP BY id ORDER BY count(id) LIMIT 10;
 
 It has an index on id.  Obviously, the index helps to evaluate count(id)
 for a given value of id, but count()s for all the `id's should be
 evaluated, so sort() will take most of the time.
 
 Is there a way to improve performance of this query?  If not, please
 give some indication to do a workaround on the source itself, so perhaps
 I may be able to come out with a patch.

In 7.4 there is a hash method that can be used for aggregates. This
may help a lot in your case if there aren't a lot of distict IDs.
7.4 is a long way from even a beta, but you still might want to play with
it to see if it will solve your problem down the road.

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



Re: [HACKERS] Detecting corrupted pages earlier

2003-02-18 Thread Hannu Krosing
Tom Lane kirjutas T, 18.02.2003 kell 17:21:
 Kevin Brown [EMAIL PROTECTED] writes:
  Tom Lane wrote:
  The cases I've been able to study look like the header and a lot of the
  following page data have been overwritten with garbage --- when it made
  any sense at all, it looked like the contents of non-Postgres files (eg,
  plain text), which is why I mentioned the possibility of disks writing
  data to the wrong sector.
 
  That also sounds suspiciously like the behavior of certain filesystems
  (Reiserfs, for one) after a crash when the filesystem prior to the
  crash was highly active with writes.

I was bitten by it about a year ago as well.

 Isn't reiserfs supposed to be more crash-resistant than ext2, rather
 than less so?

It's supposed to be, but when it is run in (default?)
metadata-only-logging mode, then you can well get perfectly good
metadata with unallocated (zero-filled) data pages. There had been some
more severe errors as well.

-
Hannu


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



Re: [HACKERS] Please apply patch

2003-02-18 Thread Bruce Momjian

Patch applied.  Thanks.

---


Teodor Sigaev wrote:
 Please apply patches for contrib/ltree.
 
 ltree_73.patch.gz - for 7.3 :
   Fix ~ operation bug: eg '1.1.1' ~ '*.1'
 
 ltree_74.patch.gz - for current CVS
 Fix ~ operation bug: eg '1.1.1' ~ '*.1'
 Add ? operation
 Optimize index storage
 
 Last change needs drop/create all ltree indexes, so only for 7.4
 
 Thank you.
 
 -- 
 Teodor Sigaev
 [EMAIL PROTECTED]
 

[ application/gzip is not supported, skipping... ]

[ application/gzip is not supported, skipping... ]

 
 ---(end of broadcast)---
 TIP 4: Don't 'kill -9' the postmaster

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


[HACKERS] Another trip

2003-02-18 Thread Bruce Momjian
I am leaving in 36 hours for another trip, this time to China and Japan.
I will have connectivity in both countries, but I am not sure how much
free time I will have.

I have no public speaking events on this trip, just meetings with
companies using PostgreSQL in Asia.  I will return March 4.

I should mention that a Japanese magazine did a poll, and PostgreSQL is
the #3 database in Japan with 9%, behind Oracle and MS-SQL, and ahead of
DB2 and Informix.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [HACKERS] WAL replay logic (was Re: [PERFORM] Mount options f

2003-02-18 Thread Vadim Mikheev
So if you do this, do you still need to store that information in
pg_control at all?
 
  Yes: to speeds up the recovery process.

 If it's going to slow down the performance of my database when not doing
 recovery (because I have to write two files for every transaction,
 rather than one)

Control file is not updated for every transaction, only on a few special
events
like checkpoint.

Vadim



---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly


Re: [HACKERS] Detecting corrupted pages earlier

2003-02-18 Thread Hiroshi Inoue
Tom Lane wrote:
(B 
(B Hiroshi Inoue [EMAIL PROTECTED] writes:
(B  Tom Lane wrote:
(B  I'm thinking of modifying ReadBuffer() so that it errors out if the
(B 
(B  What does the *error out* mean ?
(B 
(B Mark the buffer as having an I/O error and then elog(ERROR).
(B 
(B  Is there a way to make our way around the pages ?
(B 
(B If the header is corrupt, I don't think so.
(B
(BWhat I asked is how to read all other sane pages.
(BOnce pages are corrupted users would copy the sane data ASAP.
(B
(Bregards,
(BHiroshi Inoue
(Bhttp://www.geocities.jp/inocchichichi/psqlodbc/
(B
(B---(end of broadcast)---
(BTIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Hard problem with concurrency

2003-02-18 Thread Ron Mayer

FWIW, that's the approach O*'s taking.
   http://otn.oracle.com/products/oracle9i/daily/Aug24.html

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Peter Eisentraut
Sent: Tuesday, February 18, 2003 11:02 AM
To: Christopher Kings-Lynne
Cc: Tom Lane; Hackers
Subject: Re: [HACKERS] Hard problem with concurrency 


Christopher Kings-Lynne writes:

 REPLACE INTO anyone? ;)

The upcoming SQL 200x standard includes a MERGE command that appears to
fulfill that purpose.

-- 
Peter Eisentraut   [EMAIL PROTECTED]


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org


Re: [HACKERS] Hard problem with concurrency

2003-02-18 Thread Hannu Krosing
Peter Eisentraut kirjutas T, 18.02.2003 kell 21:02:
 Christopher Kings-Lynne writes:
 
  REPLACE INTO anyone? ;)
 
 The upcoming SQL 200x standard includes a MERGE command that appears to
 fulfill that purpose.

Where is this upcoming standard available on net ?


Hannu


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html


Re: [HACKERS] Hard problem with concurrency

2003-02-18 Thread Peter Eisentraut
Hannu Krosing writes:

 Where is this upcoming standard available on net ?

Near ftp://sqlstandards.org/SC32/WG3/Progression_Documents/FCD

-- 
Peter Eisentraut   [EMAIL PROTECTED]


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [HACKERS] Hard problem with concurrency

2003-02-18 Thread Christopher Kings-Lynne
  REPLACE INTO anyone? ;)

 The upcoming SQL 200x standard includes a MERGE command that appears to
 fulfill that purpose.

Is there somewhere that I can read that spec?

Or can you just post the MERGE syntax for us?

*sigh* It's just like a standard to come up with a totally new syntax for a
feature that no-one has except MySQL who use a different syntax :)

Thanks,

Chris


---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org


Re: [HACKERS] WAL replay logic (was Re: [PERFORM] Mount options for

2003-02-18 Thread Bruce Momjian

Uh, not sure.  Does it guard against corrupt WAL records?

---

Curt Sampson wrote:
 On Tue, 18 Feb 2003, Bruce Momjian wrote:
 
 
  Added to TODO:
 
  * Allow WAL information to recover corrupted pg_controldata
 ...
Using pg_control to get the checkpoint position speeds up the
recovery process, but to handle possible corruption of pg_control,
we should actually implement the reading of existing log segments
in reverse order -- newest to oldest -- in order to find the last
checkpoint. This has not been implemented, yet.
 
 So if you do this, do you still need to store that information in
 pg_control at all?
 
 cjs
 -- 
 Curt Sampson  [EMAIL PROTECTED]   +81 90 7737 2974   http://www.netbsd.org
 Don't you know, in this new Dark Age, we're all light.  --XTC
 
 ---(end of broadcast)---
 TIP 5: Have you checked our extensive FAQ?
 
 http://www.postgresql.org/users-lounge/docs/faq.html
 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org


Re: [HACKERS] WAL replay logic (was Re: [PERFORM] Mount options f

2003-02-18 Thread Mikheev, Vadim
   Added to TODO:
  
 * Allow WAL information to recover corrupted pg_controldata
  ...
 Using pg_control to get the checkpoint position 
 speeds up the
 recovery process, but to handle possible 
 corruption of pg_control,
 we should actually implement the reading of 
 existing log segments
 in reverse order -- newest to oldest -- in order 
 to find the last
 checkpoint. This has not been implemented, yet.
  
  So if you do this, do you still need to store that information in
  pg_control at all?

Yes: to speeds up the recovery process.

Vadim


_
Sector Data, LLC, is not affiliated with Sector, Inc., or SIAC

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [HACKERS] PGRPROC

2003-02-18 Thread Bruce Momjian

The proclock is structure links locks and procs, either for locks held,
or procs waiting for locks.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [HACKERS] psql and readline

2003-02-18 Thread Peter Eisentraut
Ross J. Reedstrom writes:

 Yes, BSD systems that install libedit directly in /usr/include (or into
 readline), like Patrick's,  don't need it, but mine do. Is there some
 reason we _shouldn't_ support this configuration?

I don't like adding code to support every configuration that someone
dreamed up but no one actually needs.  Readline installs the header files
into readline/readline.h and if someone thinks they can change that they
deserve to pay the price.  The configure script is already slow enough
without this.

-- 
Peter Eisentraut   [EMAIL PROTECTED]


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html


Re: [HACKERS] Hard problem with concurrency

2003-02-18 Thread Bruce Momjian

URL added to develepers FAQ.

---

Peter Eisentraut wrote:
 Hannu Krosing writes:
 
  Where is this upcoming standard available on net ?
 
 Near ftp://sqlstandards.org/SC32/WG3/Progression_Documents/FCD
 
 -- 
 Peter Eisentraut   [EMAIL PROTECTED]
 
 
 ---(end of broadcast)---
 TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly


[HACKERS] The last configuration file patch (I hope!) This one does it all.

2003-02-18 Thread mlw
PostgreSQL Extended Configuration Patch
Mohawk Software, 2003
This patch enables PostgreSQL to be far more flexible in
its configuration methodology.
Specifically, It adds two more command line parameters, -C
which specifies either the location of the postgres
configuration file or a directory containing the configuration
files, and -R which directs PostgreSQL to write its runtime
process ID to a standard file which can be used by control
scripts to control PostgreSQL.
A patched version of PostgreSQL will function as:

--- Configuration file ---
postmaster -C /etc/postgres/postgresql.conf
This will direct the postmaster program to use the
configuration file /etc/postgres/postgresql.conf
--- Configuration Directory ---
postmaster -C /etc/postgres
This will direct the postmaster program to search the
directory /etc/postgres for the standard configuration
file names: postgresql.conf, pg_hba.conf, and pg_ident.conf.
--- Run-time process ID ---
postmaster -R /var/run/postmaster.pid
This will direct PostgreSQL to write its process ID number
to a file, /var/run/postgresql.conf
--- postgresql.conf  options ---
Within the configuration file there  are five  additional
parameters: include, hba_conf,ident_conf, data_dir, and
runtime_pidfile.
They are used as:
include = '/etc/postgres/debug.conf'
data_dir = '/vol01/postgres'
hba_conf = '/etc/postgres/pg_hba_conf'
ident_conf = '/etc/postgres/pg_ident.conf'
runtime_pidfile = '/var/run/postgresql.conf'
The -D option on the command line overrides the data_dir
in the configuration file.
The -R option on the command line overrides the
runtime_pidfile in the configuration file.
If no hba_conf and/or ident_conf setting is specified, the default
$PGDATA/pg_hba.conf and/or $PGDATA/pg_ident.conf will be used.
If the -C option specifies a diretcory, pg_hba.conf and pg_ident.conf
files must be in the specified directory.
This patch is intended to move the PostgreSQL configuration out of the
data directory so that it can be modified and backed up.
This patch is also useful for running multiple servers with the same
parameters:
postmaster -C /etc/postgres/postgresql.conf -D /VOL01/postgres -p 5432
postmaster -C /etc/postgres/postgresql.conf -D /VOL02/postgres -p 5433
To apply the patch, enter your PostgreSQL source directory, and run:

cat pgec-PGVERSON.patch | patch -p 1



diff -u -r postgresql-7.3.2/src/backend/libpq/hba.c 
postgresql-7.3.2.ec/src/backend/libpq/hba.c
--- postgresql-7.3.2/src/backend/libpq/hba.cSat Dec 14 13:49:43 2002
+++ postgresql-7.3.2.ec/src/backend/libpq/hba.c Mon Feb 17 15:05:58 2003
@@ -35,6 +35,7 @@
 #include miscadmin.h
 #include nodes/pg_list.h
 #include storage/fd.h
+#include utils/guc.h
 
 
 #define IDENT_USERNAME_MAX 512
@@ -837,10 +838,22 @@
if (hba_lines)
free_lines(hba_lines);
 
-   /* Put together the full pathname to the config file. */
-   bufsize = (strlen(DataDir) + strlen(CONF_FILE) + 2) * sizeof(char);
-   conf_file = (char *) palloc(bufsize);
-   snprintf(conf_file, bufsize, %s/%s, DataDir, CONF_FILE);
+   /* Explicit HBA in config file */
+   if(explicit_hbafile  strlen(explicit_hbafile))
+   {
+   bufsize = strlen(explicit_hbafile)+1;
+   conf_file = (char *) palloc(bufsize);
+   strcpy(conf_file, explicit_hbafile);
+   }
+   else
+   {
+   char *confloc = (explicit_isdir) ? explicit_pgconfig : DataDir;
+   /* put together the full pathname to the config file */
+   bufsize = (strlen(confloc) + strlen(CONF_FILE) + 2) * sizeof(char);
+   conf_file = (char *) palloc(bufsize);
+   snprintf(conf_file, bufsize, %s/%s, confloc, CONF_FILE);
+   }
+   /* printf(hba_conf: %s\n, conf_file); */
 
file = AllocateFile(conf_file, r);
if (file == NULL)
@@ -979,10 +992,22 @@
if (ident_lines)
free_lines(ident_lines);
 
-   /* put together the full pathname to the map file */
-   bufsize = (strlen(DataDir) + strlen(USERMAP_FILE) + 2) * sizeof(char);
-   map_file = (char *) palloc(bufsize);
-   snprintf(map_file, bufsize, %s/%s, DataDir, USERMAP_FILE);
+   /* Explicit IDENT in config file */
+   if(explicit_identfile  strlen(explicit_identfile))
+   {
+   bufsize = strlen(explicit_identfile)+1;
+   map_file = (char *) palloc(bufsize);
+   strcpy(map_file, explicit_identfile);
+   }
+   else
+   {
+   /* put together the full pathname to the map file */
+   char *confloc = (explicit_isdir) ? explicit_pgconfig : DataDir;
+   bufsize = (strlen(confloc) + strlen(USERMAP_FILE) + 2) * sizeof(char);
+   map_file = (char *) palloc(bufsize);
+   snprintf(map_file, bufsize, %s/%s, confloc, USERMAP_FILE);
+   }
+   /* printf(ident_conf: %s\n, map_file); */
 
file = AllocateFile(map_file, r);
if (file 

Re: [HACKERS] WAL replay logic (was Re: [PERFORM] Mount options f

2003-02-18 Thread Curt Sampson
On Tue, 18 Feb 2003, Mikheev, Vadim wrote:

   So if you do this, do you still need to store that information in
   pg_control at all?

 Yes: to speeds up the recovery process.

If it's going to slow down the performance of my database when not doing
recovery (because I have to write two files for every transaction,
rather than one), I couldn't care less about speeding up the recovery
process.

As far as Bruce's question goes, what kind of corruption can happen to
the log files? We write a full block at a time, I guess, so it might
make sense to checksum it to verify that the block was not partially
written.

cjs
-- 
Curt Sampson  [EMAIL PROTECTED]   +81 90 7737 2974   http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light.  --XTC

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [HACKERS] location of the configuration files

2003-02-18 Thread Bruce Momjian

I have a new idea.  You know how we have search_path where you can
specify multiple schema names.  What if we allow the config_dirs/-C to
specify multiple directories to search for config files.  That way, we
can use only one variable, and we can allow people to place different
config files in different directories.

---

Andrew Sullivan wrote:
 On Sun, Feb 16, 2003 at 12:16:44AM -0500, Tom Lane wrote:
  Nor will I buy an argument that only a few developers have need for test
  installations.  Ordinary users will want to do that anytime they are
  doing preliminary tests on a new PG version before migrating their
  production database to it.  To the extent that you make manual selection
  of a nonstandard data_dir location more difficult and error-prone, you
  are hurting them too.
 
 Not only that.  For safety's sake, you may need to run multiple
 postmasters on one machine (so that database user X can't DoS
 database user Y, for instance).  And making that sort of
 production-grade work more difficult and error-prone would also be
 bad.
 
 A
 
 -- 
 
 Andrew Sullivan 204-4141 Yonge Street
 Liberty RMS   Toronto, Ontario Canada
 [EMAIL PROTECTED]  M2P 2A8
  +1 416 646 3304 x110
 
 
 ---(end of broadcast)---
 TIP 2: you can get off all lists at once with the unregister command
 (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org


Re: [HACKERS] The last configuration file patch (I hope!) This one

2003-02-18 Thread Neil Conway
On Tue, 2003-02-18 at 21:43, mlw wrote:
 This patch enables PostgreSQL to be far more flexible in
 its configuration methodology.

Without weighing in on the configuration debate, one thing this patch
definitely needs to do is update the documentation.

Cheers,

Neil
-- 
Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC




---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly


Re: [HACKERS] new version of btree_gist

2003-02-18 Thread Bruce Momjian

Patch applied.  Thanks.

---


Oleg Bartunov wrote:
 Bruce,
 
 we just released new version of contrib/btree_gist
 (7.3 and current CVS) with support of int8, float4, float8
 in addition to int4. Thanks Janko Richter for contribution.
 Could you, please, download entire archive (12Kb) from
 http://www.sai.msu.su/~megera/postgres/gist/btree_gist/btree_gist.tar.gz
 
   Regards,
   Oleg
 _
 Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
 Sternberg Astronomical Institute, Moscow University (Russia)
 Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/
 phone: +007(095)939-16-83, +007(095)939-23-83
 
 
 
 ---(end of broadcast)---
 TIP 2: you can get off all lists at once with the unregister command
 (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster