Hi,
Do you have "MYSITE_MYSITE" user at your database.
Please login to the database directly (I mean, without any pgbouncer and
check once.
select* from pg_user where usename ~~* 'MYSITE_MYSITE'; And also please
check your's pgbouncer.ini admin users list also.
Best Regards,
Dinesh
manojadinesh
On Tue, Oct 2, 2012 at 5:27 PM, Phoenix Kiula wrote:
> On Tue, Oct 2, 2012 at 11:29 AM, Phoenix Kiula
> wrote:
>> On Tue, Oct 2, 2012 at 12:59 AM, Phoenix Kiula
>> wrote:
Could you please check permission of /var/run/pgbouncer/ directory. If
pgbouncer directory does not have "postgre
On Tue, Oct 2, 2012 at 11:29 AM, Phoenix Kiula wrote:
> On Tue, Oct 2, 2012 at 12:59 AM, Phoenix Kiula
> wrote:
>>> Could you please check permission of /var/run/pgbouncer/ directory. If
>>> pgbouncer directory does not have "postgres" user permissions,please assign
>>> it and then start the pgb
On Tue, Oct 2, 2012 at 12:59 AM, Phoenix Kiula wrote:
>> Could you please check permission of /var/run/pgbouncer/ directory. If
>> pgbouncer directory does not have "postgres" user permissions,please assign
>> it and then start the pgbouncer.
>
>
> The /var/run/pgbouncer/ directory has
>
>chow
> Could you please check permission of /var/run/pgbouncer/ directory. If
> pgbouncer directory does not have "postgres" user permissions,please assign
> it and then start the pgbouncer.
The /var/run/pgbouncer/ directory has
chown -R postgres:postgres ..
The port number everywhere is already
On Mon, Oct 1, 2012 at 3:56 PM, Phoenix Kiula wrote:
> Hi,
>
> - PG 9.0.10
> - Pgbouncer version 1.4.2
>
> Not long ago, during the last server reboot for us, we had fixed the
> really painful (and largely mysterious) process of setting up
> pgbouncer.
>
> File permissions and other mysteries
Hi All,
Acting on a customer's report I analyzed this bug, and have found a fix
for it. It is not a critical error, but it definitely is a bug, and can have
security implications.
This error is raised from syslogger.c, and since this sub-process is not
responsible for any backend communic
On Sat, Oct 25, 2008 at 6:12 PM, Ati Rosselet <[EMAIL PROTECTED]> wrote:
> I'm still getting a lot of these entries in my eventlog whenever I have a
> reasonably large amount of logging:
>
> Event Type:Error
> Event Source:PostgreSQL
> Event Category:None
> Event ID:0
> Date:
gsql-general@postgresql.org
> Subject: Re: [GENERAL] again... (win32 logging errors)
>
> Ati Rosselet wrote:
> > I'm still getting a lot of these entries in my eventlog whenever I
> > have a reasonably large amount of logging:
> >
> > Event Type:Error
Ati Rosselet wrote:
I'm still getting a lot of these entries in my eventlog whenever I
have a reasonably large amount of logging:
Event Type:Error
Event Source:PostgreSQL
Event Category:None
Event ID:0
Date:10/22/2008
Time:9:36:28 AM
User:N/A
Computer:
ly endorse content contained within this transmission.
> From: [EMAIL PROTECTED]
> To: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] again...
> Date: Sun, 26 Oct 2008 11:47:24 -0400
>
>
> - Original Message -
> From: "Scott Marlowe" <[EMAIL PRO
- Original Message -
From: "Scott Marlowe" <[EMAIL PROTECTED]>
To: "Ati Rosselet" <[EMAIL PROTECTED]>
Cc:
Sent: Saturday, October 25, 2008 12:04 PM
Subject: Re: [GENERAL] again...
On Sat, Oct 25, 2008 at 9:12 AM, Ati Rosselet <[EMAIL PROTECTED]&g
I wish... no such luck. No virus scanner on the back end (nothing gets on
the server except the database :))
It seems to be a race condition where the old file is closed before the new
file is opened, and the logging attempt fails right at that time. The new
file is created just fine, and from th
On Sat, Oct 25, 2008 at 9:12 AM, Ati Rosselet <[EMAIL PROTECTED]> wrote:
> I'm still getting a lot of these entries in my eventlog whenever I have a
> reasonably large amount of logging:
>
> Event Type:Error
> Event Source:PostgreSQL
> Event Category:None
> Event ID:0
> Date:
=?UTF-8?B?5p2O5b2mIElhbiBMaQ==?= <[EMAIL PROTECTED]> writes:
> I have tables with one or several varchar(n) columns(utf8, n<=200)
> which I believe those tables' row length will not exceed the page
> length. Will it helps to the performance that I turn off TOAST of
> those 'short' varchar() colu
On Mon, 12 Jul 2004 20:31:15 +0200, Florian G. Pflug <[EMAIL PROTECTED]> wrote:
> Hi
>
> We have again experienced data-corruption using 7.4.2 on an XFS Filesystem
> on top of a software-raid (md) raid-1.
>
> After a server crash last night (It was a rather strange crash - The machine
> was still p
FYI, I have seen the SW linux raid not detect failed drives and cause
filesystem corruption on many occasions. I would reccomend staying
away from it. Maybe what you describe is a problem with PG but, i
doubt it.
On Jul 12, 2004, at 12:31 PM, Florian G. Pflug wrote:
Hi
We have again experienc
On Wednesday 27 August 2003 08:39, Juris Krumins wrote:
> Couple a weeks ago (19.08.03 Subject: Temporaty tables) I've posted message
> with question about errors I'm getting while using create temporaty table
> command.
> So I'm start digging in src code as Tom Lane did and found about 4 places
>
> > When the postmaster dies, init will automatically
> > respawn it, much the same as getty, or xdm, etc.
> > Now, since init will be starting the postmaster,
> > the /etc/rc.d/init.d script should be removed and
> > the links to it in /etc/rc.d/rc[whatever].d should
> > also be removed (or yo
On Fri, 8 Oct 1999, Doran L. Barton wrote:
> Not long ago, Ted Nolan SRI Augusta GA proclaimed...
> > Hmm, perhaps I'm missing something, but since the postmaster doesnt go
> > into the background by default, couldn't you just run a script
> > with a loop creating postmasters as they die? Someth
Not long ago, Mike Mascari proclaimed...
> According to the INSTALL document which came with
> the distribution (possibly the following remark has
> been removed in recent versions?), for RedHat Linux:
>
>
> In RedHat Linux edit file /etc/initt
--- Michael Simms <[EMAIL PROTECTED]> wrote:
> >
> > I posted this question before and got no good
> responses. I'm posting it
> > again out of pure desperation.
> >
> > I've got a Postgres 6.5.1 server running on a
> RedHat (i386) 5.2 box.
> > PostgreSQL was compiled from source with no
> speci
Not long ago, Ted Nolan SRI Augusta GA proclaimed...
> Hmm, perhaps I'm missing something, but since the postmaster doesnt go
> into the background by default, couldn't you just run a script
> with a loop creating postmasters as they die? Something like:
>
> #! /bin/sh
>
> while :
> do
>
In message <[EMAIL PROTECTED]>you write:
>
>Call this script postmasterangel.sh (as in guardian angel) and run it
>instead of the postmaster. Change the postmaster line in here to be
>your postmaster boot configuration options.
>
>
>This runs under linux. It will probably work under most un*x
>fla
24 matches
Mail list logo
