dx k9 writes:
> I just tried initdb with the -A pam option and no -W. As expected, I
> can't log into the instance. There is a MD5 hash and postgres still
> defaults to password authentication even though I did not use the -W.
> Is this a bug?
No. initdb is not intended to set up any possible
I just tried initdb with the -A pam option and no -W. As expected, I can't log
into the instance. There is a MD5 hash and postgres still defaults to
password authentication even though I did not use the -W. Is this a bug?
And I can't log into it because I have no idea what password it us
Hi,
What option can I use with initdb to use PAM for the postgres user as the
authentication type, regarding version 8.35? If I use -W during the
initialization, I end up with a md5 hash in the postgres login account, but I
want it using PAM. How can I get rid of the MD5 hash once it's ther
On Tue, Jan 13, 2009 at 3:35 PM, Scott Whitney wrote:
> Thanks for all the information, guys. I think Tom was right. Our application
> was doing a couple of full vacs at the same time. It's weird that we didn't
> run into this in the past.
>
> You're all absolutely right about the upgrading, but i
Thanks for all the information, guys. I think Tom was right. Our application
was doing a couple of full vacs at the same time. It's weird that we didn't
run into this in the past.
You're all absolutely right about the upgrading, but in our environment,
it's not 2-3 minutes. It's 2-3 weeks. I've go
On Tue, Jan 13, 2009 at 10:37 AM, Scott Whitney wrote:
> It ended up locking up about 250 customer databases until I restarted the
> postmaster. This is version 8.1.4. Upgrading right now (even to a minor rev)
> is not really an option. This box has been up and running for 306 days. This
> postgr
Tom Lane wrote:
> "Scott Whitney" writes:
> > It ended up locking up about 250 customer databases until I restarted the
> > postmaster. This is version 8.1.4. Upgrading right now (even to a minor rev)
> > is not really an option.
>
> Not related to the immediate problem, but: you really need to
Hi All,
I am a developer of a product that uses a postgresql database (currently
version 8.2.3.1). We dump the database using pg_dumpall. We are
finding data corruption in the dump files about twice a month with a few
thousand installations. I have been able to track down the data
corruption
"Scott Whitney" writes:
> Last night, I got this:
> Jan 13 03:31:28 db01 postgres[23537]: [140-2] DETAIL: Process 23537 waits
> for AccessShareLock on relation 1260 of database 0; blocked by process
> 8.
> Jan 13 03:31:28 db01 postgres[23537]: [140-3] Process 8 waits for
> AccessShareL
I'm about to begin researching this, but I thought I'd throw this out there
and see if there are any quick responses.
Last night, I got this:
Jan 13 03:31:28 db01 postgres[23537]: [140-2] DETAIL: Process 23537 waits
for AccessShareLock on relation 1260 of database 0; blocked by process
8.
Ja
10 matches
Mail list logo
