You are absolutely right. I hate it when I get turned around. Thank you very
much for the assistance.
Chris
--( Forwarded letter 1 follows )-
Date: Thu, 13 May 2004 07:57:38 -0700 (PDT)
To: chris.hoover
Cc: [EMAIL PROTECTED]
From: [EMAIL PROTECTED]
Subject: Re
#ifdef __STDC__
extern int accept(int, struct sockaddr *, Psocklen_t);
#else /* __STDC__ */
extern int accept();
Regards,
Laurens
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 13, 2004 4:43 PM
To: Laurens Wagemakers
Cc: '[EMAIL PROTECTED]'
Subject:
Laurens Wagemakers <[EMAIL PROTECTED]> writes:
> extern int accept(int, struct sockaddr *, Psocklen_t);
Hmm. The comments in configure have
# Solaris 7 and 8 have arg3 as 'void *' (disguised as 'Psocklen_t'
# which is *not* 'socklen_t *'). If we detect that, then we assume
# 'int' as the result
We are currently on version 7.3.3 and I was thinking of upgrading. Is
the 7.4.2 version considered a stable version?
I read some info regarding changes to the system tables. Can someone
touch on how this might affect us?
Do I need to restore my database with this upgrade?
Thanks so much,
Jodi K
On Thu, 13 May 2004, Jodi Kanter wrote:
> We are currently on version 7.3.3 and I was thinking of upgrading. Is
> the 7.4.2 version considered a stable version?
> I read some info regarding changes to the system tables. Can someone
> touch on how this might affect us?
> Do I need to restore my dat
Hi all,
An old issue (14 mar 2002).
Got the error now on Solaris 9 (Checking types of arguments for accept()...
configure: error: could not > determine argument types)
Did anyone solve this yet ?
Regards,
Laurens
---(end of broadcast)---
TIP 5
Laurens Wagemakers <[EMAIL PROTECTED]> writes:
> [ configure generated a zero-size GNUmakefile ]
> ./configure delivered following error signals:
> configure: warning: TCL/TK support disabled; tcl shell is not in your path
> sed: command garbled: [EMAIL PROTECTED]@%gcc (GCC) 3.3.2 (several times)
Hai Tom,
I just talked to the developers and we can use 7.1 now.
So know I'm compiling 7.1.3 on Solaris as stated in my other mail however
when I run ./configure I get:
Checking types of arguments for accept()...
configure: error: could not > determine argument types)
Regards,
Laurens
-
I need some help understanding and creating foreign keys in postgresql.
Here is an example of what I am trying to do:
I have table 1 with:
table1_id serial unique
table1_col1 varchar
I have table2 with:
table2_id serial unique
table1_id integer
table2_col1 varchar
When I try to create the forei
Laurens Wagemakers <[EMAIL PROTECTED]> writes:
> So know I'm compiling 7.1.3 on Solaris as stated in my other mail however
> when I run ./configure I get:
> Checking types of arguments for accept()...
> configure: error: could not > determine argument types)
Hmph. AFAICS we haven't changed tha
On Thu, 13 May 2004, CHRIS HOOVER wrote:
> I need some help understanding and creating foreign keys in postgresql.
>
> Here is an example of what I am trying to do:
>
> I have table 1 with:
> table1_id serial unique
> table1_col1 varchar
>
> I have table2 with:
> table2_id serial unique
> table1_i
Hello all,
Rather new on Postgresql so maybe it's simple to solve this:
Machine: Solaris 9 32 bits
Gnumake: 3.80
Gcc: 3.3.2
Postgresql: 7.0.1 (need old version for compatibility)
Downloaded and extracted it.
in src directory
./configure
gmake
Then nothing happens GNUmakefile size is 0
Did I f
This is somthing I wish more of us did on the lists. The list archives
have solutions and workarounds for every variety of problem but very few
summary emails exist. A good example of this practice is in the
sun-managers mailling list. The original poster sends a "SUMMARY" reply
to the list with
Bjoern Metzdorf wrote:
Hi,
at first, many thanks for your valuable replies. On my quest for the
ultimate hardware platform I'll try to summarize the things I learned.
-
This is what I am considering the ultimate platform for postgresql:
James Thornton wrote:
This is what I am considering the ultimate platform for postgresql:
Hardware:
Tyan Thunder K8QS board
2-4 x Opteron 848 in NUMA mode
4-8 GB RAM (DDR400 ECC Registered 1 GB modules, 2 for each processor)
LSI Megaraid 320-2 with 256 MB cache ram and battery backup
6 x 36GB SCSI
Bjoern Metzdorf wrote:
You might also consider configuring the Postgres data drives for a
RAID 10 SAME configuration as described in the Oracle paper "Optimal
Storage Configuration Made Easy"
(http://otn.oracle.com/deploy/availability/pdf/oow2000_same.pdf). Has
anyone delved into this before?
O
I see you've got an LSI Megaraid card with oodles of Cache. However, don't underestimate the power of the software RAID implementation that Red Hat Linux comes with.
We're using RHE 2.1 and I can recommend Red Hat Enterprise Linux if you want an excellent implementation of software RAID. In
Hadley Willan wrote:
To answer question 1, if you use software raid the chunk size is part of
the /etc/raidtab file that is used on initial container creation. 4KB is
the standard and a LARGE chunk size of 1MB may affect performance if
you're not writing down to blocks in that size continuously.
One big caveat re. the "SAME" striping strategy, is that readahead can
really hurt an OLTP you.
Mind you, if you're going from a few disks to a caching array with many
disks, it'll be hard to not have a big improvement
But if you push the envelope of the array with a "SAME" configuration,
read
19 matches
Mail list logo