On Fri, Jul 08, 2005 at 05:16:27PM -0700, Bailey, Larry wrote:
>
> Thanks but it is still prompting for a password.
Let's back up a bit: what problem are you trying to solve? Do you
want the user to be able to log in without entering a password? If
so then see "Client Authentication" in the doc
Bailey, Larry wrote:
Thanks but it is still prompting for a password.
Does your pg_hba.conf require a password?
Sincerely,
Joshua D. Drake
Larry Bailey
Sr. Oracle DBA
First American Real Estate Solution
(714) 701-3347
[EMAIL PROTECTED]
-Original Message-
From: Joshua D. Drake [m
Thanks but it is still prompting for a password.
Larry Bailey
Sr. Oracle DBA
First American Real Estate Solution
(714) 701-3347
[EMAIL PROTECTED]
-Original Message-
From: Joshua D. Drake [mailto:[EMAIL PROTECTED]
Sent: Friday, July 08, 2005 5:10 PM
To: Bailey, Larry
Cc: pgsql-performan
On Fri, Jul 08, 2005 at 05:09:48PM -0700, Joshua D. Drake wrote:
> Bailey, Larry wrote:
> >I created a user with a password. That newly created user now have
> >tables and indexes. I want to ALTER that user to exclude the password.
> >How is this accomplished without dropping and recreating the use
Bailey, Larry wrote:
I created a user with a password. That newly created user now have
tables and indexes. I want to ALTER that user to exclude the password.
How is this accomplished without dropping and recreating the users?
Never tried to go backwards before but:
alter user foo with encrypt
I created a user with a password. That newly created user now have
tables and indexes. I want to ALTER that user to exclude the password.
How is this accomplished without dropping and recreating the users?
Larry Bailey
Sr. Oracle DBA
First American Real Estate Solution
(714) 701-3347
[EMAIL PROTEC
Enrico Weigelt wrote:
Bruno Wolff III wrote:
This gets brought up a lot. The problem is that the index doesn't include
information about whether the current transaction can see the referenced
row. Putting this information in the index will add significant overhead
to every update and the opinio
> Stuart,
>
> > I'm putting together a road map on how our systems can scale as our
load
> > increases. As part of this, I need to look into setting up some fast
> > read only mirrors of our database. We should have more than enough
RAM
> > to fit everything into memory. I would like to find out i
Ian Westmacott <[EMAIL PROTECTED]> writes:
> If I make the single configuration change of setting
> vacuum_cost_delay=1000, each iteration in analyze_thread takes
> much longer, of course. But what I also see is that the CPU
> usage of the connections for writer_thread and reader_thread
> spike up
Stuart,
> I'm putting together a road map on how our systems can scale as our load
> increases. As part of this, I need to look into setting up some fast
> read only mirrors of our database. We should have more than enough RAM
> to fit everything into memory. I would like to find out if I could
>
* David Gagnon <[EMAIL PROTECTED]> wrote:
> FOR inventoryTransaction IN
>SELECT DISTINCT IRNUM, IRAENUM, IRSTATUT, IRSENS, IRSOURCE,
> IRDATE, IRQTE
>FROM IR
>WHERE IRNUM = ANY (requestIds) and IRYPNUM = companyId
>LOOP
hmm. you probably could create the query dynamic
I am beginning to look at Postgres 8, and am particularly
interested in cost-based vacuum/analyze. I'm hoping someone
can shed some light on the behavior I am seeing.
Suppose there are three threads:
writer_thread
every 1/15 second do
BEGIN TRANSACTION
COPY table1 FROM stdin
..
Linux(Debian) + Java + PostgreSQL = Fastest
2005/7/8, Mark Lewis <[EMAIL PROTECTED]>:
> On Fri, 2005-07-08 at 16:43 +0200, Enrico Weigelt wrote:
> > * PFC <[EMAIL PROTECTED]> wrote:
> >
> >
> > > For Python it's the reverse : the MySQL driver is slow and dumb,
> > > and the postgres driv
On Fri, 2005-07-08 at 16:43 +0200, Enrico Weigelt wrote:
> * PFC <[EMAIL PROTECTED]> wrote:
>
>
> > For Python it's the reverse : the MySQL driver is slow and dumb,
> > and the postgres driver (psycopg 2) is super fast, handles all
> > quoting,
> > and knows about type conversions, i
* PFC <[EMAIL PROTECTED]> wrote:
> For Python it's the reverse : the MySQL driver is slow and dumb,
> and the postgres driver (psycopg 2) is super fast, handles all
> quoting,
> and knows about type conversions, it will automatically convert a
> Python List into a postgres Arra
* Bruno Wolff III <[EMAIL PROTECTED]> wrote:
> This gets brought up a lot. The problem is that the index doesn't include
> information about whether the current transaction can see the referenced
> row. Putting this information in the index will add significant overhead
> to every update and the
* Klint Gore <[EMAIL PROTECTED]> wrote:
> Turn on statement logging. I've seen delphi interfaces do extra queries
> on system tables to find some structure information.
I'm already using statement logging of all queries taking longer
than 200ms. It seems that only the INSERT takes such a time.
> If I could get and deploy some SSD (Solid State Disk) devices that
> would make this sort of thing *actually safe,* I'd expect that to be a
> pretty fabulous improvement, at least for write-heavy database
> activity.
Not nearly as much as you would expect. For the price of the SSD and a
SCSI con
18 matches
Mail list logo