Don Drake [EMAIL PROTECTED] writes:
My server is crashing on a delete statement.
Here's the error message in the log file:
LOG: 0: received fast shutdown request
LOCATION: pmdie, postmaster.c:1736
That says that something sent the postmaster a SIGINT signal.
I think it's highly
=?UTF-8?B?SmFyb3PFgmF3IFBhxYJrYQ==?= [EMAIL PROTECTED] writes:
We are running PostgreSQL server version 7.4.6 on RedHat 9 (Shrike) on
single Pentium 4 (2.66 GHz) box with SCSI disc and 512 MB RAM.
Our database contains several tables (small size) and one special table
with ~100 records
...
2) Is there some (performance) difference between BEFORE and AFTER
triggers? I believe there's no measurable difference.
BEFORE triggers might be faster, because you get a chance to reject the
record before it is inserted into table. Common practice is to put
validity checks into
Well, a vacuum on the entire DB seemed to have cleaned things up.
No other user was logged into the server, and I certainly did not send
the signal.
I did clean up the serverlog file by truncating it ( serverlog)
while the DB was running, I don't think it liked that since it crashed
the DB.
by Truncating the serverlog do you mean the data_log (as in my case)
log file of the postgresql sever ?. If thats the file you truncated
than i think its not a good habit..since you might need it at some
point of time for some debugging purpose in production.
You could use something like assuming
I am running 8.0.1 on a desktop xp system and a AS4 redhat system.
The redhat will be my production server in a week or so and it is returning
slower the my desk top?
I understand about the perc cards on the Dell (redhat) but my Dell 2 proc
box runs much faster (MSSQL) then my desktop, so I am
Aditya wrote:
We have not, AFAICT, had any problems with the traffic over NFS as far as
reliability -- I'm sure there is a performance penalty, but the reliability
and scalability gains more than offset that.
My experience agrees with yours. However we did find one gotcha -- see
the thread
Here is the config for the AS4 server.
# -
# PostgreSQL configuration file
# -
#
# This file consists of lines of the form:
#
# name = value
#
# (The '=' is optional.) White space may be used. Comments are introduced
# with '#' anywhere
Aditya wrote:
On Mon, Apr 11, 2005 at 10:59:51AM -0700, Joe Conway wrote:
Any particular reason? Our NetApp technical rep advised nfs over iSCSI,
IIRC because of performance.
I would mount the Netapp volume(s) as a block level device on my server
using
iSCSI (vs. a file-based device like NFS) so
Neil Conway wrote:
Keith Worthington wrote:
- Seq Scan on tbl_current (cost=0.00..1775.57 rows=76457
width=31) (actual time=22.870..25.024 rows=605 loops=1)
This rowcount is way off -- have you run ANALYZE recently?
-Neil
---(end of
On Mon, Apr 11, 2005 at 10:59:51AM -0700, Joe Conway wrote:
FWIW, if I were to do this anew, I would probably opt for iSCSI over GigE
with
a NetApp.
Any particular reason? Our NetApp technical rep advised nfs over iSCSI,
IIRC because of performance.
I would mount the Netapp volume(s) as
11 matches
Mail list logo
