On tor, 2010-09-23 at 20:55 -0700, Evan Rempel wrote:
> I am running Postgresql 8.3 and would like to get postgres to
> NOT wrap the syslog lines. Is ther any configuration to do this.
> Perhaps I can wrap them at a very large line number?
PostgreSQL 8.4 increased the line length.
--
Sent via
On Fri, Sep 24, 2010 at 7:55 AM, Evan Rempel wrote:
> I am running Postgresql 8.3 and would like to get postgres to
> NOT wrap the syslog lines. Is ther any configuration to do this.
> Perhaps I can wrap them at a very large line number?
>
> The problem is that we want a program to analyze the lo
Evan Rempel writes:
> I am running Postgresql 8.3 and would like to get postgres to
> NOT wrap the syslog lines. Is ther any configuration to do this.
> Perhaps I can wrap them at a very large line number?
The problem we're up against is explained in src/backend/utils/error/elog.c:
* Ou
I am running Postgresql 8.3 and would like to get postgres to
NOT wrap the syslog lines. Is ther any configuration to do this.
Perhaps I can wrap them at a very large line number?
The problem is that we want a program to analyze the logs for us, and with the
line breaks it
is very difficult, alth
On Samstag, 26. Januar 2008 paul rivers wrote:
> Anyway, that's my experience with this, hope it helps.
Dear Paul, thanks a lot for the very detailed information. I'm more
relaxed now as it seems to be possible to do everything I wanted,
although I'm concerned that 5.000 inserted lines per secon
Michael Monnerie wrote:
Dear list,
I shall build up a central syslog server able to do 5.000 log lines per
second peak, 1.000 sustained. I found some pages describing current
syslog-ng with magic "log to file then insert":
http://ben.muppethouse.com/SYSLOG-DOC.html
http://www.kdough.net/docs/sys
Dear list,
I shall build up a central syslog server able to do 5.000 log lines per
second peak, 1.000 sustained. I found some pages describing current
syslog-ng with magic "log to file then insert":
http://ben.muppethouse.com/SYSLOG-DOC.html
http://www.kdough.net/docs/syslog_postgresql/
But accor
On Mittwoch, 18. Juli 2007 Alvaro Herrera wrote:
> Postgres does not split entries. They are split by infelicities in
> the underlying facilities used (pipes). There's ongoing work to fix
> this problem. In the meantime, I think you could work around it by
> using syslog instead of redirect_stde
Michael Monnerie wrote:
> On Freitag, 29. Juni 2007 Michael Monnerie wrote:
> > I have most entries split over several lines:
> >
> > Jun 29 19:56:40 db.xxx.xxx postgres[10640]: [5-1] DB=XXX U=XXX
> > H=1.1.1.1 16854186.2190 idleLOG: Verbindungsende: Sitzungszeit:
> > 0:01:22.10 Jun 29 19:56:40 db
On Freitag, 29. Juni 2007 Michael Monnerie wrote:
> I have most entries split over several lines:
>
> Jun 29 19:56:40 db.xxx.xxx postgres[10640]: [5-1] DB=XXX U=XXX
> H=1.1.1.1 16854186.2190 idleLOG: Verbindungsende: Sitzungszeit:
> 0:01:22.10 Jun 29 19:56:40 db.xxx.xxx postgres[10640]: [5-2]
> B
I have most entries split over several lines:
Jun 29 19:56:40 db.xxx.xxx postgres[10640]: [5-1] DB=XXX U=XXX H=1.1.1.1
16854186.2190 idleLOG: Verbindungsende: Sitzungszeit: 0:01:22.10
Jun 29 19:56:40 db.xxx.xxx postgres[10640]: [5-2] Benutzer=xxx Datenbank=
Host=1.1.1.1 port=23640
Is it p
On Mon, 15 Mar 2004, Bruce Momjian wrote:
> scott.marlowe wrote:
> > On Thu, 11 Mar 2004, Christopher Kings-Lynne wrote:
> >
> > > > You could also consider not using syslog at all: let the postmaster
> > > > output to its stderr, and pipe that into a log-rotation program.
> > > > I believe some
scott.marlowe wrote:
> On Thu, 11 Mar 2004, Christopher Kings-Lynne wrote:
>
> > > You could also consider not using syslog at all: let the postmaster
> > > output to its stderr, and pipe that into a log-rotation program.
> > > I believe some people use Apache's log rotator for this with good
> >
ECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Christopher
Kings-Lynne
Sent: Thursday, March 11, 2004 12:35 PM
To: Tom Lane
Cc: Greg Spiegelberg; PgSQL Performance ML; Postgres Admin List
Subject: Re: [PERFORM] [ADMIN] syslog slowing the database?
> You could also consider not using syslog at all:
Not an option I'm afraid. PostgreSQL just jams and stops logging after
the first rotation...
Are you using a copy truncate method to rotate the logs? In RedHat add
the keyword COPYTRUCATE to your /etc/logrotate.d/syslog file.
Sincerely,
Joshua D. Drake
I know some people use this in produc
You could also consider not using syslog at all: let the postmaster
output to its stderr, and pipe that into a log-rotation program.
I believe some people use Apache's log rotator for this with good
results.
Not an option I'm afraid. PostgreSQL just jams and stops logging after
the first rotation
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> You could also consider not using syslog at all: let the postmaster
>> output to its stderr, and pipe that into a log-rotation program.
>> I believe some people use Apache's log rotator for this with good
>> results.
> Not an option I'm afraid
On Thu, Mar 11, 2004 at 09:34:54 +0800,
Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote:
> >You could also consider not using syslog at all: let the postmaster
> >output to its stderr, and pipe that into a log-rotation program.
> >I believe some people use Apache's log rotator for this with goo
Tom Lane wrote:
Greg Spiegelberg <[EMAIL PROTECTED]> writes:
If the log and database were on the same disk I'd be okay with the
current workaround. If the ``-'' gave me near the same performance as
turning syslog off I'd be okay with that too. However, neither of these
are the case so there has
Greg Spiegelberg <[EMAIL PROTECTED]> writes:
> If the log and database were on the same disk I'd be okay with the
> current workaround. If the ``-'' gave me near the same performance as
> turning syslog off I'd be okay with that too. However, neither of these
> are the case so there has to be som
On Wed, 2004-03-10 at 12:09, Gavin M. Roy wrote:
> Might want to look at metalog, it does delayed writes, though ultimately
> your issue is io bound and there's not much you can do to reduce io if
> you want to keep syslog logging your pgsql queries and such.
Yeah, but syslog with fsync() after
Tom Lane wrote:
Greg Spiegelberg <[EMAIL PROTECTED]> writes:
I turned syslog back on and the restore slowed down again. Turned
it off and it sped right back up.
We have heard reports before of syslog being quite slow. What platform
are you on exactly? Does Richard's suggestion of turning off sy
Tom Lane wrote:
Greg Spiegelberg <[EMAIL PROTECTED]> writes:
I turned syslog back on and the restore slowed down again. Turned
it off and it sped right back up.
We have heard reports before of syslog being quite slow. What platform
are you on exactly? Does Richard's suggestion of turning off
Might want to look at metalog, it does delayed writes, though ultimately
your issue is io bound and there's not much you can do to reduce io if
you want to keep syslog logging your pgsql queries and such.
Tom Lane wrote:
Greg Spiegelberg <[EMAIL PROTECTED]> writes:
I turned syslog back on an
Greg Spiegelberg <[EMAIL PROTECTED]> writes:
> I turned syslog back on and the restore slowed down again. Turned
> it off and it sped right back up.
We have heard reports before of syslog being quite slow. What platform
are you on exactly? Does Richard's suggestion of turning off syslog's
fsync
I've been waiting all day for a pg_restore to finish on a test system
identically configured as our production in hardware and software
with the exception prod is 7.3.5 and test is 7.4.1.
The file it's restoring from is about 8GB uncompressed from a
"pg_dump -b -F t" and after 2 hours the directory
I'm back with more on the funky glibc-syslog-Postgres deadlocking behavior:
> It's really too bad that your gdb backtrace didn't show anything past
> the write_syslog level (which is an elog subroutine). If we could see
> whether the elog had been issued from a signal handler, and if so what
> it
> It looks to me like the guy doing VACUUM is simply waiting for the other
> guy to release a page-level lock. The other guy is running a deferred
> trigger and so I'd expect him to be holding one or two page-level locks,
> on the page or pages containing the tuple or tuples passed to the
> trigge
"Arthur Ward" <[EMAIL PROTECTED]> writes:
> An idea just popped into my head, though. Perhaps I can create procedures
> in plpgsql and plpython which do nothing but spew notices (which would in
> turn be sent to syslog), and run one or two copies to see if they'll die
> on their own given sufficien
"Arthur Ward" <[EMAIL PROTECTED]> writes:
> I'm back with more on the funky glibc-syslog-Postgres deadlocking behavior:
It looks to me like the guy doing VACUUM is simply waiting for the other
guy to release a page-level lock. The other guy is running a deferred
trigger and so I'd expect him to b
> A checkpoint would also have reason to wait for a page-level lock, if
> the stuck backend was holding one. I am wondering though if the stuck
> condition consistently happens while trying to fire a trigger? That
> would be very interesting ... not sure what it'd mean though ...
Hmm. I'm really
"Arthur Ward" <[EMAIL PROTECTED]> writes:
>> It looks to me like the guy doing VACUUM is simply waiting for the other
>> guy to release a page-level lock. The other guy is running a deferred
>> trigger and so I'd expect him to be holding one or two page-level locks,
>> on the page or pages contain
> It's really too bad that your gdb backtrace didn't show anything past
> the write_syslog level (which is an elog subroutine). If we could see
> whether the elog had been issued from a signal handler, and if so what
> it had interrupted, we'd have an idea whether this is a known syslog
> deficien
[EMAIL PROTECTED] writes:
> Neither of those make a whole lot of sense to me, though:
> 1. The Postgresql backend shouldn't be getting any signals (at least none
> external to Postgresql).
Hm. Postgres does sometimes issue elog messages from inside a signal
handler. I doubt that it would do so w
>> And the other:
>> 19720 pts/2S 0:04 postgres: award Trucking [local] UPDATE
>> (gdb) bt
>> #0 0x4021cec6 in sigsuspend () from /lib/libc.so.6
>> #1 0x424b6218 in __pthread_wait_for_restart_signal ()
>>from /lib/libpthread.so.0
>> #2 0x424b79a0 in __pthread_alt_lock () from /lib/l
"Arthur Ward" <[EMAIL PROTECTED]> writes:
> FWIW, since I already went to the trouble (and for the sake of people
> searching the archives in the future), here's what I was seeing in the
> backtraces after rebuilding this afternoon:
> This process:
> 19763 pts/2S 0:00 postgres: checkpoint
> "Arthur Ward" <[EMAIL PROTECTED]> writes:
>> I'm encountering strange hangs in postgresql backends at random
>> moments. They seem to be associated with attempts to issue log entries
>> via syslog. I have run backtraces on the hung backends a few times,
>> and they routinely trace into system lib
""Arthur Ward"" <[EMAIL PROTECTED]> writes:
> I'm encountering strange hangs in postgresql backends at random moments.
> They seem to be associated with attempts to issue log entries via syslog.
> I have run backtraces on the hung backends a few times, and they routinely
> trace into system librari
"Arthur Ward" <[EMAIL PROTECTED]> writes:
> I'm encountering strange hangs in postgresql backends at random moments.
> They seem to be associated with attempts to issue log entries via syslog.
> I have run backtraces on the hung backends a few times, and they routinely
> trace into system libraries
I'm encountering strange hangs in postgresql backends at random moments.
They seem to be associated with attempts to issue log entries via syslog.
I have run backtraces on the hung backends a few times, and they routinely
trace into system libraries where it looks like a stuck syslog call. So
far,
Larry Rosenman <[EMAIL PROTECTED]> writes:
> Hackers: Is there any reason to NOT make --enable-syslog the default
> any more?
> I.E. can we change the sense of it to be --disable-syslog and have
> USE_SYSLOG defined by default?
I thought we'd agreed to do that already; at least Peter had indica
On 14 Mar 2002 21:17:05 +
"Oliver Elphick" <[EMAIL PROTECTED]> wrote:
> On Thu, 2002-03-14 at 20:13, Jie Liang wrote:
> > I did everything as you did, however, when start the postmaster,
> > I got following:
> > FATAL 1:'syslog' is not a valid option name.
>
> Then you haven't configured
On Thu, 2002-03-14 at 20:13, Jie Liang wrote:
> I did everything as you did, however, when start the postmaster,
> I got following:
> FATAL 1: 'syslog' is not a valid option name.
Then you haven't configured postgresql with --enable-syslog. (That
message comes from src/backend/utils/misc/gu
TECTED]'; pgsql-sql
Subject: Re: [ADMIN] Syslog
Jie Liang wrote:
> I did, it didn't work.
>
> Jie Liang
Works for me. Did you change postgresql.conf? Here's what mine looks like.
#
# Syslog
#
# requires ENABLE_SYSLOG
syslog = 1 # range 0-2
Jie Liang wrote:
> I did, it didn't work.
>
> Jie Liang
Works for me. Did you change postgresql.conf? Here's what mine looks like.
#
# Syslog
#
# requires ENABLE_SYSLOG
syslog = 1 # range 0-2
syslog_facility = 'LOCAL0'
syslog_ident = 'postgres'
From the online docs:
On 14 Mar 2002 at 10:48, Joe Conway wrote:
> Jie Liang wrote:
> > In postgresql.conf:
> > # Syslog
> > # requires ENABLE_SYSLOG
> > How to do it?
> > My OS is FreeBSD4.5
> > I installed Postgres-7.2
> >
> >
> > Urgent!
Try not to think that your message is more important than any othe
I did, it didn't work.
Jie Liang
-Original Message-
From: Joe Conway [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 14, 2002 10:49 AM
To: Jie Liang
Cc: '[EMAIL PROTECTED]'; pgsql-sql
Subject: Re: [ADMIN] Syslog
Jie Liang wrote:
> In postgresql.conf:
> #
Jie Liang wrote:
> In postgresql.conf:
> # Syslog
> # requires ENABLE_SYSLOG
> How to do it?
> My OS is FreeBSD4.5
> I installed Postgres-7.2
>
>
> Urgent!
>
I think you need to make sure that PostgreSQL was built with
--enable-syslog during configure.
Joe
--
In postgresql.conf:
# Syslog
# requires ENABLE_SYSLOG
How to do it?
My OS is FreeBSD4.5
I installed Postgres-7.2
Urgent!
Thanks!
Jie Liang
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.or
49 matches
Mail list logo
