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
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
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
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
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
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'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
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:
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
--
29 matches
Mail list logo
