Thread: Logging
Hey, I've set my pg_options file to write log messages, but it only logs to /var/log/messages instead of /var/log/postgresql wich remains empty. Why is that and how can i change it? Maybe it's a sylog question, but beeing new to it and all i can't really figure things out. I've installed the 7.0.3-1 rpm on an RedHat 6.2 system. Thanks, Anders,
"Anders R. Sveen" wrote: > I've set my pg_options file to write log messages, but it only logs to > /var/log/messages instead of /var/log/postgresql wich remains empty. > Why is that and how can i change it? Maybe it's a sylog question, but > beeing new to it and all i can't really figure things out. You need to edit /etc/syslog.conf to direct the output of PostgreSQL to the file you wish to hold the log. The facility used by default in 7.0.3 is local0, so a line: local0.* /var/log/postgresql will do what you expect. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Hi all,
We've run into an odd problem here. We had a db that we upgraded to PG7
without problems. We then dumped that db via pgdump and restored it to a
different server. The odd part is that the restored database had at least
one view from the original db that magically turned into a table (not a
view) in the new db. This broke some of our code that accesses the db (I
can't remember exactly why off hand) so I had to delete the table and
recreate it as a view by hand.
Has anyone else seen this? It smells like a bug to me.
--Rainer
"Anders R. Sveen" wrote: >Hey, > >I've set my pg_options file to write log messages, but it only logs to >/var/log/messages instead of /var/log/postgresql wich remains empty. > >Why is that and how can i change it? Maybe it's a sylog question, but >beeing new to it and all i can't really figure things out. The docs say: Messages printed to syslog use the log facility LOG_LOCAL0. You need to configure syslogd to send those messages to postgresql; edit /etc/syslog.conf (see the man page for syslogd and syslog.conf) to contain something like: local0.* -/var/log/postgresql You may want to change this to be more selective... -- Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C ======================================== "Can two walk together, except they be agreed?" Amos 3:3
Rainer - sorry for the late reply, I haven't been at work for a few days! Yeah, we've seen this happen before (on an old 6.3.2 database). At first I just noticed the view wasn't working and re-ran our 'create view' script against the database. This fixed the view but had a knock-on effect and screwed up another view (actually the next view when listing tables etc. in the database using '\d')! It wasn't until I did a table listing that I noticed that Postgres was listing the view as a table and - as you did - I dropped the view as a table, then rebuilt it from our 'create view' script and everything was OK. Never did find out why though?!! As you say, it does smell like a bug. Paul M. Breen, Software Engineer - Computer Park Ltd. Tel: (01536) 417155 Email: pbreen@computerpark.co.uk On Tue, 21 Nov 2000, Rainer Mager wrote: > Hi all, > > We've run into an odd problem here. We had a db that we upgraded to PG7 > without problems. We then dumped that db via pgdump and restored it to a > different server. The odd part is that the restored database had at least > one view from the original db that magically turned into a table (not a > view) in the new db. This broke some of our code that accesses the db (I > can't remember exactly why off hand) so I had to delete the table and > recreate it as a view by hand. > Has anyone else seen this? It smells like a bug to me. > > --Rainer >
Hi all,
We're having some pretty serious problems with transactions via JDBC. We're
running on Linux with PG 7.0.3 and Sun's 1.2.2 Java VM.
The issue is that we have a reasonably large number of connections to our
database (as much as 80 simultaneously although the problem happens even at
around 30). What happens is that we have a transaction that 1) deletes all
items from a table for a given user ID, 2) inserts in the new items for that
user ID. This is wrapped in a single transaction. The problem is that
sometimes, the insert fails because the delete didn't actually delete
(apparently). I've put in debugging info and doing a query before and after
the delete bears this out, this is, the delete sometimes doesn't delete.
I've also looked at the postgres logs but it is very difficult to tell
where 1 connectios transaction starts compared to a differenct connection. I
think it would be useful if all lines were labeled with some sort of
connection ID.
Any way, has anyone seen anything like this? And before you ask, yes, we're
quite sure the code properly starts and ends a connection (well, we think
we're sure anyway ;-).
The only possibility I've been able to come up with is if we're
inadvertantly using the same JDBC connection more than once at a time. I've
looked into this a lot and it does not seem to be the case.
Any help would be GREATLY appreciated.
Thanks in advance.
--Rainer