Thread: Createlang problem.
I have a problem installing the plpgsql language in my database. I've looked over previous post but was unable to find a solution. I do the following Createlang -U pgsql plpgsql template1 Createlang then prompts me for a password, I assume for the pgsql user. I then enter the password only to be prompted again and again continuously. I have my pg_hba.conf file configured as follows Local all md5 Host sameuser md5 I had to change this to: Local all trust Then createlang worked just fine, however I still would like to know what the problem is and if I might have something miss configured. I'm running postgresql version 7.2.1 on FreeBSD 4.6.2 installed from the latest FreeBSD port. Thanks in advance for any insights those of you on this list might have. Regards, Theo ============================================== Theodore A. Jencks -DigitaLFacet, Inc.- TEL 925-362-0015 P.O. Box 242 CEL 510-915-2226 Alamo, CA FAX 925-362-8995 94507 thjencks@digitalfacet.com http://www.digitalfacet.com
"Theodore A. Jencks" <tjencks@digitalfacet.com> writes:
> Createlang then prompts me for a password, I assume for the pgsql user.
> I then enter the password only to be prompted again and again
> continuously.
How much is "continuously"? I seem to recall that createlang issues
three or four commands in separate psql calls, so three or four entries
of the password would be needed.
In general, password auth is a pain in the neck for admins. Consider ident.
regards, tom lane
In an attempt to review a machine for optimal OLTP configuration of
Postgres box, turned WAL debug to 1 and ran under load for 24 hours. That
resulted in a 67+ meg postmaster logfile. But I'm not sure how to
interpret the results. Without going through the 700,000+ lines, the basic
info looks like this:
INSERT @ 7/2838581988: prev 7/2838573716; xprev 7/2838573716; xid 38868268;
bkpb
1: Btree - insert: node 18720/20077; tid 219/75
INSERT @ 7/2838590260: prev 7/2838581988; xprev 7/2838581988; xid 38868268;
bkpb
1: Btree - insert: node 18720/11144803; tid 201/94
INSERT @ 7/2838598532: prev 7/2838590260; xprev 7/2838590260; xid 38868268:
Heap
- update: node 18720/19299; tid 431/8; new 431/21
XLogFlush: rqst 7/2838540592; wrt 7/2838593536; flsh 7/2838524040
XLogFlush: rqst 7/2838557172; wrt 7/2838598740; flsh 7/2838598740
XLogFlush: rqst 7/2838565444; wrt 7/2838598740; flsh 7/2838598740
XLogFlush: rqst 7/2838573716; wrt 7/2838598740; flsh 7/2838598740
I know in general that I'm looking at inserts into the log buffers and
flushes of the buffers to permanent storage. I also know that a bad
situation is one where all buffers fill up and an insert must wait for a
flush. How can I examine this output to know if that is happening? Also,
is there anything else I can look for within this data to tell me if I have
a configuration problem that could use some tuning?
FYI:
version
-------------------------------------------------------------
PostgreSQL 7.1.2 on i686-pc-linux-gnu, compiled by GCC 2.96
Thanks for any help that can be provided.
Marc Mitchell - Senior Application Architect
Enterprise Information Solutions, Inc.
Downers Grove, IL 60515
marcm@eisolution.com
Marc Mitchell wrote: > In an attempt to review a machine for optimal OLTP configuration of > Postgres box, turned WAL debug to 1 and ran under load for 24 hours. That > resulted in a 67+ meg postmaster logfile. But I'm not sure how to > interpret the results. Without going through the 700,000+ lines, the basic > info looks like this: > > > INSERT @ 7/2838581988: prev 7/2838573716; xprev 7/2838573716; xid 38868268; > bkpb > 1: Btree - insert: node 18720/20077; tid 219/75 > INSERT @ 7/2838590260: prev 7/2838581988; xprev 7/2838581988; xid 38868268; > bkpb > 1: Btree - insert: node 18720/11144803; tid 201/94 > INSERT @ 7/2838598532: prev 7/2838590260; xprev 7/2838590260; xid 38868268: > Heap > - update: node 18720/19299; tid 431/8; new 431/21 > XLogFlush: rqst 7/2838540592; wrt 7/2838593536; flsh 7/2838524040 > XLogFlush: rqst 7/2838557172; wrt 7/2838598740; flsh 7/2838598740 > XLogFlush: rqst 7/2838565444; wrt 7/2838598740; flsh 7/2838598740 > XLogFlush: rqst 7/2838573716; wrt 7/2838598740; flsh 7/2838598740 > > > I know in general that I'm looking at inserts into the log buffers and > flushes of the buffers to permanent storage. I also know that a bad > situation is one where all buffers fill up and an insert must wait for a > flush. How can I examine this output to know if that is happening? Also, > is there anything else I can look for within this data to tell me if I have > a configuration problem that could use some tuning? Add timestamps to the logs. See my article on Hardware performance tuning on the techdocs.postgresql.org site. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
On Thu, Aug 29, 2002 at 04:03:09PM -0400, Bruce Momjian wrote:
>
> Add timestamps to the logs. See my article on Hardware performance
> tuning on the techdocs.postgresql.org site.
But please note that adding the timestamp itself imposes a
performance penalty, because you have to call to get the time of day
for every log write.
A
--
----
Andrew Sullivan 204-4141 Yonge Street
Liberty RMS Toronto, Ontario Canada
<andrew@libertyrms.info> M2P 2A8
+1 416 646 3304 x110
Andrew Sullivan wrote: > On Thu, Aug 29, 2002 at 04:03:09PM -0400, Bruce Momjian wrote: > > > > Add timestamps to the logs. See my article on Hardware performance > > tuning on the techdocs.postgresql.org site. > > But please note that adding the timestamp itself imposes a > performance penalty, because you have to call to get the time of day > for every log write. There is a TODO item to add a GUC option and complain if checkpoints happen more frequenly than X seconds. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073