Re: [ADMIN] [GENERAL] Server and Client configuration.

[Albe Laurenz]

Jayakumar_Mukundaraju wrote:
> 
> I am new to Postgresql Database. My setup is backend is postgresql
> database, frontend is Java(JDBC). I installed the postgres in windows
> platform. Now I want to setup server and client configuration. Kindly
> guide me how to set the configuration parameters, in server and client
> machines. Waiting for your fav reply.

These should contain all you need:
http://www.postgresql.org/docs/current/static/index.html
http://jdbc.postgresql.org/documentation/82/index.html
http://jdbc.postgresql.org/development/privateapi/index.html

Yours,
Laurenz Albe

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [GENERAL] [PERFORM] [ADMIN] Postgres VS Oracle

[Andrew Kelly]

On Mon, 2007-06-18 at 13:02 -0400, Jonah H. Harris wrote:
> On 6/18/07, Andreas Kostyrka <[EMAIL PROTECTED]> wrote:
> > As a cynic, I might ask, what Oracle is fearing?
> 
> As a realist, I might ask, how many times do we have to answer this
> type of anti-commercial-database flamewar-starting question?
> 

As a nudist, I think I have to answer, "About every 9 weeks, it would
seem".

Andy

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [ADMIN] How to restore updated records

[Jim Nasby]

Your best bet on something like this is probably going to be  
contacting a company that does PostgreSQL support and inquiring about  
data recovery. EnterpriseDB and Command Prompt both employ folks who  
could probably accomplish this; I think OmniTI might as well. There's  
probably a few others.


On Jun 12, 2007, at 11:19 AM, [EMAIL PROTECTED] wrote:



No, I do not have WAL archiving.
I hope some one have done the hacking in postmaster.
If no one have done this, my idea was to change the vacuum
(or make e new copy).
I am not familiar with pg code, but as I know by running
vacuum, pg marks deleted records as free, and my idea was to
mark this records as real record in the database (if it is
possible).

regards,
ivan.


Ivan,

if you have configured WAL archiving, you may want to
look at


http://www.postgresql.org/docs/8.1/static/backup-online.html,

especially paragraph '23.3..4. Timelines'.

List: Maybe someone already hacked the postmaster to
extract deleted records?!

HTH, Oliver.

-Ursprungliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag von
[EMAIL PROTECTED]
Gesendet: Montag, 11. Juni 2007 19:35
An: pgsql-admin@postgresql.org
Betreff: [ADMIN] How to restore updated records



Hi all.
Sorry for my problem.
I am using pg on ~100 servers fro 5 y. without any
problems,
but this time I make a big mistake.

A have a table tasks with about 2 records.
The table have ID as pk and some other fields.

I typed : update tasks set c1='sss';
instead update tasks setc1='sss' where id=10;

And the pg updated all my table tasks.

I do not have any backup on this table.
Exists any way to restore the data>
After the mistake I stopped to execute any commands to
this
database and also I DO NOT HAVE running vacuum, vacuum
analyze ot vacuum full analyze on this table.

I know pg stores the old copy of data, but I do not have
any
idea how to restore this deleted records.

Pls., point me to any solution for this problem.

Many thanks and best regards,
ivan.

-

SCENA - Единственото БЕЗПЛАТНО списание за мобилни
комуникации и технологии.
http://www.bgscena.com/


---(end of
broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

---(end of
broadcast)---
TIP 7: You can help support the PostgreSQL project by
donating at

http://www.postgresql.org/about/donate








-

SCENA - Единственото БЕЗПЛАТНО списание за мобилни комуникации и  
технологии.

http://www.bgscena.com/


---(end of  
broadcast)---

TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate



--
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)



---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq

Re: [ADMIN] Table size

[Jim Nasby]

On Jun 14, 2007, at 8:16 AM, Michael Fuhr wrote:

On Thu, Jun 14, 2007 at 06:10:15PM +0530, Shyam Sunder Rai wrote:

How can I calculate a table size in postgres ?


To find the size of an existing table use pg_relation_size() or
pg_total_relation_size() (8.1 and later; in earlier versions use
the functions in contrib/dbsize).


If you don't need an exact size, you can also look at  
pg_class.relpages, which is the size of a relation in pages. The  
relation_size functions actually read the size off the filesystem,  
which seems to be quite a bit slower if you're dealing with more than  
a few files.

--
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)



---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [ADMIN] How to restore updated records

[Aleksander Kmetec - INTERA]

About 2 years ago a new guy at our company deleted all contents of a table on a development server and I managed to 
restore them by changing the XID value with pg_resetxlog.


You can get last chackpoint's XID by running pg_controldata; then use pg_resetxlog -x and try different values. You'll 
need to repeat the "copy from backup - change XID - start postmaster" cycle a few times; but it should be doable in less 
than an hour.


Regards,
Aleksander

Jim Nasby wrote:
Your best bet on something like this is probably going to be contacting 
a company that does PostgreSQL support and inquiring about data 
recovery. EnterpriseDB and Command Prompt both employ folks who could 
probably accomplish this; I think OmniTI might as well. There's probably 
a few others.


On Jun 12, 2007, at 11:19 AM, [EMAIL PROTECTED] wrote:



No, I do not have WAL archiving.
I hope some one have done the hacking in postmaster.
If no one have done this, my idea was to change the vacuum
(or make e new copy).
I am not familiar with pg code, but as I know by running
vacuum, pg marks deleted records as free, and my idea was to
mark this records as real record in the database (if it is
possible).

regards,
ivan.



---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [pgsql-advocacy] [PERFORM] [ADMIN] Postgres VS Oracle

[Carol Walter]

I don't want to add gas to the flamewar, but I gotta ask.  What is in  
the the 90 to 95% referred to in this email.


Carol
On Jun 18, 2007, at 1:17 PM, Joshua D. Drake wrote:


Jonah H. Harris wrote:

On 6/18/07, Andreas Kostyrka <[EMAIL PROTECTED]> wrote:

As a cynic, I might ask, what Oracle is fearing?

As a realist, I might ask, how many times do we have to answer this
type of anti-commercial-database flamewar-starting question?


Depends? How many times are you going to antagonize the people that  
ask?


1. It has *nothing* to do with anti-commercial. It is anti- 
proprietary which is perfectly legitimate.


2. Oracle, Microsoft, and IBM have a "lot" to fear in the sense of  
a database like PostgreSQL. We can compete in 90-95% of cases where  
people would traditionally purchase a proprietary system for many,  
many thousands (if not hundreds of thousands) of dollars.


Sincerely,

Joshua D. Drake

--

  === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/ 
donate

PostgreSQL Replication: http://www.commandprompt.com/products/


---(end of  
broadcast)---

TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that  
your

  message can get through to the mailing list cleanly



---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match

Re: [pgsql-advocacy] [PERFORM] [ADMIN] Postgres VS Oracle

[Achilleas Mantzios]

Στις Τρίτη 19 Ιούνιος 2007 15:39, ο/η Carol Walter έγραψε:
> I don't want to add gas to the flamewar, but I gotta ask.  What is in
> the the 90 to 95% referred to in this email.

short answer: all cases, possibly except when running a Bank or something 
similar.

>
> Carol
>
> On Jun 18, 2007, at 1:17 PM, Joshua D. Drake wrote:
> > Jonah H. Harris wrote:
> >> On 6/18/07, Andreas Kostyrka <[EMAIL PROTECTED]> wrote:
> >>> As a cynic, I might ask, what Oracle is fearing?
> >>
> >> As a realist, I might ask, how many times do we have to answer this
> >> type of anti-commercial-database flamewar-starting question?
> >
> > Depends? How many times are you going to antagonize the people that
> > ask?
> >
> > 1. It has *nothing* to do with anti-commercial. It is anti-
> > proprietary which is perfectly legitimate.
> >
> > 2. Oracle, Microsoft, and IBM have a "lot" to fear in the sense of
> > a database like PostgreSQL. We can compete in 90-95% of cases where
> > people would traditionally purchase a proprietary system for many,
> > many thousands (if not hundreds of thousands) of dollars.
> >
> > Sincerely,
> >
> > Joshua D. Drake
> >
> > --
> >
> >   === The PostgreSQL Company: Command Prompt, Inc. ===
> > Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
> > Providing the most comprehensive  PostgreSQL solutions since 1997
> >  http://www.commandprompt.com/
> >
> > Donate to the PostgreSQL Project: http://www.postgresql.org/about/
> > donate
> > PostgreSQL Replication: http://www.commandprompt.com/products/
> >
> >
> > ---(end of
> > broadcast)---
> > TIP 1: if posting/reading through Usenet, please send an appropriate
> >   subscribe-nomail command to [EMAIL PROTECTED] so that
> > your
> >   message can get through to the mailing list cleanly
>
> ---(end of broadcast)---
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>choose an index scan if your joining column's datatypes do not
>match

-- 
Achilleas Mantzios

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Re: [GENERAL] [PERFORM] [ADMIN] Postgres VS Oracle

[Geoffrey]

Andrew Kelly wrote:

On Mon, 2007-06-18 at 13:02 -0400, Jonah H. Harris wrote:

On 6/18/07, Andreas Kostyrka <[EMAIL PROTECTED]> wrote:

As a cynic, I might ask, what Oracle is fearing?

As a realist, I might ask, how many times do we have to answer this
type of anti-commercial-database flamewar-starting question?



As a nudist, I think I have to answer, "About every 9 weeks, it would
seem".


Jeese!  You could have warned us to shield our eyes!

--
Until later, Geoffrey

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
 - Benjamin Franklin

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [pgsql-advocacy] [PERFORM] [ADMIN] Postgres VS Oracle

[Jim Nasby]

Can we please trim this down to just advocacy?

On Jun 18, 2007, at 1:17 PM, Joshua D. Drake wrote:


Jonah H. Harris wrote:

On 6/18/07, Andreas Kostyrka <[EMAIL PROTECTED]> wrote:

As a cynic, I might ask, what Oracle is fearing?

As a realist, I might ask, how many times do we have to answer this
type of anti-commercial-database flamewar-starting question?


Depends? How many times are you going to antagonize the people that  
ask?


1. It has *nothing* to do with anti-commercial. It is anti- 
proprietary which is perfectly legitimate.


2. Oracle, Microsoft, and IBM have a "lot" to fear in the sense of  
a database like PostgreSQL. We can compete in 90-95% of cases where  
people would traditionally purchase a proprietary system for many,  
many thousands (if not hundreds of thousands) of dollars.


Sincerely,

Joshua D. Drake

--

  === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/ 
donate

PostgreSQL Replication: http://www.commandprompt.com/products/


---(end of  
broadcast)---

TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that  
your

  message can get through to the mailing list cleanly



--
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)



---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match

Re: [ADMIN] [pgsql-advocacy] [PERFORM] Postgres VS Oracle

[Chris Browne]

[EMAIL PROTECTED] (Carol Walter) writes:
> I don't want to add gas to the flamewar, but I gotta ask.  What is in
> the the 90 to 95% referred to in this email.

I'd say, look at the Oracle feature set for things that it has that
PostgreSQL doesn't.

Four that come to mind:

- ORAC = multimaster replication
- Integration with hardware vendors' High Availability systems
- Full fledged table partitioning
- Windowing functions (SQL:2003 stuff, used in OLAP)

These are features Truly Needed for a relatively small percentage of
systems.  They're typically NOT needed for:

 - departmental applications that operate during office hours
 - light weight web apps that aren't challenging the limits of
   the most expensive hardware
 - any application where reliability requirements do not warrant
   spending $1M to make it more reliable
 - applications that make relatively unsophisticated use of data
   (e.g. - it's not worth the analysis to figure out a partitioning
   design, and nobody's running queries so sophisticated that they
   need windowing analytics)

I expect both of those lists are incomplete, but those are big enough
lists to, I think, justify the claim, at least in loose terms.

The most important point is that third one, I think: 
  "any application where reliability requirements do not warrant
  spending $1M to make it more reliable"

Adopting ORAC and/or other HA technologies makes it necessary to spend
a Big Pile Of Money, on hardware and the humans to administer it.

Any system whose importance is not sufficient to warrant *actually
spending* an extra $1M on improving its reliability is *certain* NOT
to benefit from either ORAC or HA, because you can't get any relevant
benefits without spending pretty big money.  Maybe the number is lower
than $1M, but I think that's the right order of magnitude.
-- 
output = reverse("ofni.secnanifxunil" "@" "enworbbc")
http://linuxdatabases.info/info/nonrdbms.html
"One disk to rule them all,  One disk to find  them. One disk to bring
them all and in the darkness grind them. In  the Land of Redmond where
the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [ADMIN] [pgsql-advocacy] [PERFORM] Postgres VS Oracle

[Chris Browne]

[EMAIL PROTECTED] (Achilleas Mantzios) writes:
>> I don't want to add gas to the flamewar, but I gotta ask.  What is in
>> the the 90 to 95% referred to in this email.
>
> short answer: all cases, possibly except when running a Bank or something 
> similar.

No, it's not to do with what enterprise you're running; the question
is what functionality is missing.

At the simplest level, I'd say that there are Oracle (+DB2) feature
sets that *are compelling*, particularly in the High Availability
area.

However, those feature sets are ones that require spending a Big Pile
Of Money (BPOM) to enable them.  

For instance, ORAC (multimaster replication) requires buying a bunch
of servers and spending a BPOM configuring and administering them.

If you haven't got the BPOM, or your application isn't so "mission
critical" as to justify budgeting a BPOM, then, simply put, you won't
be using ORAC functionality, and that discards one of the major
justifications for buying Oracle.

*NO* small business has that BPOM to spend on this, so *NO* database
operated by a small business can possibly justify "buying Oracle
because of ORAC."

There will be a lot of "departmental" sorts of applications that:

- Aren't that mission critical

- Don't have data models so sophisticated as to require the "features
  at the edges" of the big name commercial DBMSes (e.g. - partitioning,
  OLAP/Windowing features) that PostgreSQL currently lacks
   
and those two categorizations, it seems to me, likely define a
frontier that allow a whole lot of databases to fall into the "don't
need the Expensive Guys" region.
-- 
"cbbrowne","@","cbbrowne.com"
http://www3.sympatico.ca/cbbrowne/oses.html
Rules of the Evil Overlord #219. "I will be selective in the hiring of
assassins.   Anyone who  attempts to  strike down  the hero  the first
instant his back is turned will not even be considered for the job."


---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [ADMIN] Explained by known hardware failures, or keep looking?

[Kevin Grittner]

>>> On Tue, Jun 19, 2007 at  8:07 AM, in message <[EMAIL PROTECTED]>,
Chander Ganesan <[EMAIL PROTECTED]> wrote: 
> Kevin Grittner wrote:
>>  
>> weekly maintenance process which builds a new version of a table based on 
>> records retention rules.  It is built under a temporary name; then the 
>> previous version of the table is dropped and the new table is renamed.  This 
>> leaves a fraction of a second during which queries may fail on the missing 
>> table, but it seems to be better than the alternatives.  (If a query doesn't 
>> complete within 20 seconds, it is an error for the users of these tables, 
>> since our web app times out.  The alternatives which blocked rather than 
>> giving outright errors blocked for more than 20.25 seconds, so this 
>> alternative generates the fewest errors from a user perspective.)
> 
> With PostgreSQL 8.2 you have the ability to dynamically add and remove 
> child tables, so you could create a "blank" parent table and make the 
> data table its child, built the new data table, and then simply change 
> the inheritance (remove the old child and add the new child).  
> Applications would not need to change (since PostgreSQL's inheritance 
> rules would have the same "parent" table name, and only the child would 
> change).
> 
> That would give you a much, much, much smaller window of unavailability 
 
I'm curious what the "much, much, much smaller" amount of time would be.
Our current technique seems to result in between 80 ms and 250 ms of
"down time" around our weekly maintenance.  Even though our site gets
about two million hits a day, we usually don't see any queries trying to
touch this table during the replacement.  On a bad day we might see five
errors, which would result in the users getting a "try again" sort of message
in their browsers.

It would be totally unacceptable, by the way, for there to be any window of
time during which the table appeared empty -- an error would be much
preferred.  This means that we would either need to bracket the inheritance
changes within a transaction or add the new table as a child (with mostly
duplicate rows) before dropping the old one.  Either would be OK -- does
one sound more promising than the other?  Is there any chance that using
this technique would have a negative impact on performance?  (Many of
these queries join a large number of tables and also use several correlated
subqueries.)
 
-Kevin
 


---(end of broadcast)---
TIP 6: explain analyze is your friend

[ADMIN] Postgres8.2 - turning off BINGLOG/PARSELOG

[Mario Splivalo]

I'm finaly switching to 8.2. I notice that ugly 'feature' from pg8.1 has
been fixed: logging the parametars of prepared statements. It's a bit
ugly, but it's there :)

But now in my log i have BINDLOG, PARSELOG and others, and my log looks
realy cloged. Here is an example. I'm calling the
'create_mo_sms_message' function via JDBC, and this is the log entry:

2007-06-19 16:22:15.553 CEST [4596]  BINDLOG:  duration:
0.023 ms  bind S_1: BEGIN
2007-06-19 16:22:15.553 CEST [4596]  BEGINLOG:  duration:
0.010 ms  execute S_1: BEGIN
2007-06-19 16:22:15.553 CEST [4596]  PARSELOG:  duration:
0.165 ms  parse : select * from create_mo_sms_message($1, $2,
$3, $4, $5, $6, $7, $8, $9, $10, $11) as result
2007-06-19 16:22:15.553 CEST [4596]  BINDLOG:  duration:
0.292 ms  bind : select * from create_mo_sms_message($1, $2,
$3, $4, $5, $6, $7, $8, $9, $10, $11) as result
2007-06-19 16:22:15.553 CEST [4596]  BINDDETAIL:
parameters: $1 = NULL, $2 = 'a9369fa8-2bd9-41f0-a325-cd0fe62fbe46', $3 =
'+3859811', $4 = 'PULITZER-1', $5 = 'memo Ovo je moja mala
probetina...', $6 = '2007-06-19 14:22:15.547', $7 = NULL, $8 = NULL, $9
= '127.0.0.1', $10 = 'tele2', $11 = NULL
2007-06-19 16:22:15.554 CEST [4596]  SELECTNOTICE:
__internal__determine_operator_id: Operator_mark >tele2< does not
exists!
2007-06-19 16:22:15.554 CEST [4596]  SELECTCONTEXT:
PL/pgSQL function "create_mo_sms_message" line 24 at assignment
2007-06-19 16:22:15.554 CEST [4596]  SELECTNOTICE:
CREATE_MO: Operator_id could not be guessed...
2007-06-19 16:22:15.554 CEST [4596]  SELECTLOG:  duration:
0.599 ms  execute : select * from create_mo_sms_message($1, $2,
$3, $4, $5, $6, $7, $8, $9, $10, $11) as result
2007-06-19 16:22:15.554 CEST [4596]  SELECTDETAIL:
parameters: $1 = NULL, $2 = 'a9369fa8-2bd9-41f0-a325-cd0fe62fbe46', $3 =
'+3859811', $4 = 'PULITZER-1', $5 = 'memo Ovo je moja mala
probetina...', $6 = '2007-06-19 14:22:15.547', $7 = NULL, $8 = NULL, $9
= '127.0.0.1', $10 = 'tele2', $11 = NULL
2007-06-19 16:22:15.555 CEST [4596]  BINDLOG:  duration:
0.027 ms  bind S_2: COMMIT
2007-06-19 16:22:15.556 CEST [4596]  COMMITLOG:  duration:
0.029 ms  execute S_2: COMMIT


These are the settings from postgresql.conf, concerning loging:

log_min_messages = info
log_min_duration_stateme
log_error_verbosity = defaultnt = 0
debug_print_parse = off
debug_print_rewritten = off
debug_pretty_print = off
log_line_prefix = '%m [%p] <%d> %i'

Is there a way to turn off these PARSELOG and BINDLOG messages? I realy
need only the SELECTLOG (and SELECTDETAIL because there are the actuall
parametars)?

Tia,

Mario


---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [ADMIN] Postgres8.2 - turning off BINGLOG/PARSELOG

[Alvaro Herrera]

Mario Splivalo wrote:
> I'm finaly switching to 8.2. I notice that ugly 'feature' from pg8.1 has
> been fixed: logging the parametars of prepared statements. It's a bit
> ugly, but it's there :)

> 2007-06-19 16:22:15.555 CEST [4596]  BINDLOG:  duration:
> 0.027 ms  bind S_2: COMMIT
> 2007-06-19 16:22:15.556 CEST [4596]  COMMITLOG:  duration:
> 0.029 ms  execute S_2: COMMIT
>
> log_line_prefix = '%m [%p] <%d> %i'

One thing you should be aware of is that PARSELOG etc are really "PARSE"
and "LOG", but there is no intervening space since you put no space at
the end of log_line_prefix.  So I suggest changing it to

log_line_prefix = '%m [%p] <%d> %i '

Now, regarding your question,

> Is there a way to turn off these PARSELOG and BINDLOG messages? I realy
> need only the SELECTLOG (and SELECTDETAIL because there are the actuall
> parametars)?

I don't think so.  You can increase log_min_duration_statement a bit so
that only statements that take "long" are logged.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [ADMIN] [pgsql-advocacy] [PERFORM] Postgres VS Oracle

[Joshua_Kramer]

The most important point is that third one, I think:
 "any application where reliability requirements do not warrant
 spending $1M to make it more reliable"

Adopting ORAC and/or other HA technologies makes it necessary to spend
a Big Pile Of Money, on hardware and the humans to administer it.


If I were CIO that did not follow the Postgres groups regularly, I would 
take that to mean that Oracle is automatically more reliable than PG 
because you can spend a BPOM to make it so.


Let's ask a different question.  If you take BPOM / 2, and instead of 
buying Oracle, hire consultants to work on a PG solution, could the PG 
solution achieve the same reliability as Oracle?  Would it take the same 
amount of time?  Or heck, spend the full BPOM on hardening PG against 
failure - could PG achieve that reliability?


Or, by spending BPOM for Oracle strictly to get that reliability, are you 
only buying "enterpriseyness" (i.e. someone to blame and the ability to 
one-up a buddy at the golf course)?


Cheers,
-J


---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org

Re: [ADMIN] Postgres8.2 - turning off BINGLOG/PARSELOG

[Mario Splivalo]

On Tue, 2007-06-19 at 10:52 -0400, Alvaro Herrera wrote:
> Mario Splivalo wrote:
> > I'm finaly switching to 8.2. I notice that ugly 'feature' from pg8.1 has
> > been fixed: logging the parametars of prepared statements. It's a bit
> > ugly, but it's there :)
> 
> > 2007-06-19 16:22:15.555 CEST [4596]  BINDLOG:  duration:
> > 0.027 ms  bind S_2: COMMIT
> > 2007-06-19 16:22:15.556 CEST [4596]  COMMITLOG:  duration:
> > 0.029 ms  execute S_2: COMMIT
> >
> > log_line_prefix = '%m [%p] <%d> %i'
> 
> One thing you should be aware of is that PARSELOG etc are really "PARSE"
> and "LOG", but there is no intervening space since you put no space at
> the end of log_line_prefix.  So I suggest changing it to
> 
> log_line_prefix = '%m [%p] <%d> %i '

Huh, thnx! :) Silly me, I tought that %i actually stands for 'SELECT *
FROM ...' :)

> Now, regarding your question,
> 
> > Is there a way to turn off these PARSELOG and BINDLOG messages? I realy
> > need only the SELECTLOG (and SELECTDETAIL because there are the actuall
> > parametars)?
> 
> I don't think so.  You can increase log_min_duration_statement a bit so
> that only statements that take "long" are logged.

Why not? I need to have log_min_duration_statement set to 0 because I do
want every SQL sent to the postgres loged. It's essential in debugging.
But since for every SELECT i have at least 3 lines in my log file,
debugging is much harder (ok, not that harder, but still, it would be
much easier without it). It would be realy nice if one could turn that
off.

When I switch to JDBC driver for pg (pg74.215.jdbc3.jar), I have single
SELECT in a log for a SELECT sent from the client. I guess that's
because there is no prepared statements in pg74.215.jdbc3.jar, but that
is for pg-jdbc mailinglist.

10x again!

Mike


---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

[ADMIN] Export/import issue/question

[Karl Wright]

Hi,

I'm trying to move a database from postgresql 7.4 to postgresql 8.1. 
Unfortunately this is not going well.  This is what I did:


pg_dump --file dbsnapshot --format=t -a -b

and then I installed 8.1, and attempted the following:

pg_restore --file dbsnapshot --format=t --table=ingeststatus -a

But, I get the following error:

pg_restore: [tar archiver] could not find header for file toc.dat in tar 
archive


However, a tar tf shows that toc.dat is indeed in the dbsnapshot file:

[EMAIL PROTECTED]:/common$ tar tf dbsnapshot
toc.dat
2.dat
3.dat
4.dat
5.dat
6.dat
7.dat
8.dat
9.dat
10.dat
11.dat
12.dat
13.dat
14.dat
15.dat
...

The tar is pretty large:

-rw-r--r--   1 root root  6892524032 Jun 19 09:48 dbsnapshot

Any idea what I'm doing wrong?

Karl


---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org

[ADMIN] pg_dump: Exclude multiple tables in version 7.4

[cha]

Hi All,

I want to  dump the database by using pg_dump command but the problem is the
version at the server is 7.4 which doesn't support the provision for
excluding tables as in version 8.2.

There are 500+ tables in the database,from which 15-20 are of huge sizes.I
want to exclude them.Is there any way to do it?

I knw that I have to use include instead of excluding the tables.Do I have
to include each and every tables manually or is there way to do that?

Do i have to write the script for this? if yes, how should I proceed?

Please help me out with this issue.

Thanks in Advance.


Cheers,
Cha
-- 
View this message in context: 
http://www.nabble.com/pg_dump%3A-Exclude-multiple-tables-in-version-7.4-tf3944402.html#a11188794
Sent from the PostgreSQL - admin mailing list archive at Nabble.com.


---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [GENERAL] [PERFORM] [ADMIN] Postgres VS Oracle

[Geoffrey Myers]

Andrew Kelly wrote:

On Mon, 2007-06-18 at 13:02 -0400, Jonah H. Harris wrote:

On 6/18/07, Andreas Kostyrka <[EMAIL PROTECTED]> wrote:

As a cynic, I might ask, what Oracle is fearing?

As a realist, I might ask, how many times do we have to answer this
type of anti-commercial-database flamewar-starting question?



As a nudist, I think I have to answer, "About every 9 weeks, it would
seem".


Jeese!  You could have forwarned us to shut our eyes!


--
Until later, Geoffrey

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
 - Benjamin Franklin

---(end of broadcast)---
TIP 6: explain analyze is your friend

[ADMIN] archive_command does not execute

[George Wilk]

Hi,

 

I am attempting to use the WAL archiving on a Solaris machine, running
PostgreSQL 8.1.4.  The archive_command specified in the postgresql.conf file
does not get executed, nor do I see any log entries showing errors etc.
What am I doing wrong here?  

 

Here is the relevant fragment of my conf file:

 

fsync = on  # turns forced synchronization on or
off

wal_sync_method = fsync # the default is the first option

# supported by the operating system:

#   open_datasync

#   fdatasync

#   fsync

#   fsync_writethrough

#   open_sync

#full_page_writes = on  # recover from partial page writes

#wal_buffers = 8# min 4, 8KB each

#commit_delay = 0   # range 0-10, in microseconds

#commit_siblings = 5# range 1-1000

 

# - Checkpoints -

 

checkpoint_segments = 1 # in logfile segments, min 1, 16MB each

checkpoint_timeout = 30 #  range 30-3600, in second

checkpoint_warning = 5  # in seconds, 0 is off

 

# - Archiving -

 archive_command = 'touch /var/lib/pgsql/bkp/myfile'

 

 

Here is my log entry for the duration of the test:

 

FATAL:  terminating connection due to administrator command

LOG:  shutting down

LOG:  database system is shut down

LOG:  database system was shut down at 2007-06-19 07:48:03 EDT

LOG:  checkpoint record is at 0/899E68

LOG:  redo record is at 0/899E68; undo record is at 0/0; shutdown TRUE

LOG:  next transaction ID: 2445; next OID: 16399

LOG:  next MultiXactId: 1; next MultiXactOffset: 0

LOG:  database system is ready

LOG:  transaction ID wrap limit is 2147484146, limited by database
"postgres"

 

Thanks in advance,

 

~george

Re: [ADMIN] Export/import issue/question

[Tom Lane]

Karl Wright <[EMAIL PROTECTED]> writes:
> But, I get the following error:
> pg_restore: [tar archiver] could not find header for file toc.dat in tar 
> archive

Could we see "pg_restore -l" output for that dump file?

This looks a bit like some bugs we've seen before, eg,
http://archives.postgresql.org/pgsql-bugs/2006-10/msg00263.php
but the particular cause of that one wouldn't apply to a 7.4
dump file.

regards, tom lane

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [ADMIN] pg_dump: Exclude multiple tables in version 7.4

[Tom Lane]

cha <[EMAIL PROTECTED]> writes:
> I want to  dump the database by using pg_dump command but the problem is the
> version at the server is 7.4 which doesn't support the provision for
> excluding tables as in version 8.2.

If you're dumping with the intent to update to 8.2, you could use 8.2's
pg_dump.

regards, tom lane

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [ADMIN] archive_command does not execute

[Tom Arthurs]

George Wilk wrote:


Hi,

 

I am attempting to use the WAL archiving on a Solaris machine, running 
PostgreSQL 8.1.4.  The archive_command specified in the 
postgresql.conf file does not get executed, nor do I see any log 
entries showing errors etc.  What am I doing wrong here? 

 


Here is the relevant fragment of my conf file:

 

fsync = on  # turns forced synchronization 
on or off


wal_sync_method = fsync # the default is the first option

# supported by the operating 
system:


#   open_datasync

#   fdatasync

#   fsync

#   fsync_writethrough

#   open_sync

#full_page_writes = on  # recover from partial page writes

#wal_buffers = 8# min 4, 8KB each

#commit_delay = 0   # range 0-10, in microseconds

#commit_siblings = 5# range 1-1000

 


# - Checkpoints -

 


checkpoint_segments = 1 # in logfile segments, min 1, 16MB each

checkpoint_timeout = 30 #  range 30-3600, in second

checkpoint_warning = 5  # in seconds, 0 is off

 


# - Archiving -

 archive_command = 'touch /var/lib/pgsql/bkp/myfile'

 

 


Here is my log entry for the duration of the test:

 


FATAL:  terminating connection due to administrator command

LOG:  shutting down

LOG:  database system is shut down

LOG:  database system was shut down at 2007-06-19 07:48:03 EDT

LOG:  checkpoint record is at 0/899E68

LOG:  redo record is at 0/899E68; undo record is at 0/0; shutdown TRUE

LOG:  next transaction ID: 2445; next OID: 16399

LOG:  next MultiXactId: 1; next MultiXactOffset: 0

LOG:  database system is ready

LOG:  transaction ID wrap limit is 2147484146, limited by database 
"postgres"


 


Thanks in advance,

 


~george


George

Looks like you are expecting the archive command to run when you shut 
down the data base. It won't.  It only runs when the xlog gets full and 
the system needs to recycle to a new logfile.


FWIW, here's what my solaris 9, posgresql 8.1.8 system has as an archive 
command:


archive_command  = 'test ! -f 
/data/archivelog/%f && cp %p /data/archivelog/%f'


adjust as needed for your directory structure.

you need to run enough commited transactions through to fill up a 16 meg 
xlog.  Then you will see the xlog getting archived (or your "myfile" get 
updated).


---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match

Re: [ADMIN] Export/import issue/question

[Karl Wright]

Tom Lane wrote:

Karl Wright <[EMAIL PROTECTED]> writes:

But, I get the following error:
pg_restore: [tar archiver] could not find header for file toc.dat in tar 
archive


Could we see "pg_restore -l" output for that dump file?

This looks a bit like some bugs we've seen before, eg,
http://archives.postgresql.org/pgsql-bugs/2006-10/msg00263.php
but the particular cause of that one wouldn't apply to a 7.4
dump file.

regards, tom lane



You could, if I could get it.

When I do this:

pg_restore -l

it just hangs.  No CPU usage, no disk usage - just sits there.

When I do this:

pg_restore -l --file dbsnapshot

... same thing.

When I supply database credentials via -U and -W, then it simply displays:


pg_restore: [tar archiver] could not find header for file toc.dat in tar 
archive


Not very helpful, I know.  Any other ideas?

Karl




---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [ADMIN] Export/import issue/question

[Karl Wright]

Karl Wright wrote:

Tom Lane wrote:

Karl Wright <[EMAIL PROTECTED]> writes:

But, I get the following error:
pg_restore: [tar archiver] could not find header for file toc.dat in 
tar archive


Could we see "pg_restore -l" output for that dump file?

This looks a bit like some bugs we've seen before, eg,
http://archives.postgresql.org/pgsql-bugs/2006-10/msg00263.php
but the particular cause of that one wouldn't apply to a 7.4
dump file.

regards, tom lane



You could, if I could get it.

When I do this:

pg_restore -l

it just hangs.  No CPU usage, no disk usage - just sits there.

When I do this:

pg_restore -l --file dbsnapshot

... same thing.

When I supply database credentials via -U and -W, then it simply displays:


pg_restore: [tar archiver] could not find header for file toc.dat in tar 
archive


Not very helpful, I know.  Any other ideas?

Karl



Nevermind.  The man page was not clear for -l.  Here's the output:

[EMAIL PROTECTED]:/common$ sudo pg_restore -l dbsnapshot
;
; Archive created at Tue Jun 19 09:39:30 2007
; dbname: metacarta
; TOC Entries: 20
; Compression: 0
; Dump Version: 1.7-0
; Format: TAR
; Integer: 4 bytes
; Offset: 8 bytes
;
;
; Selected TOC Entries:
;
2; 0 17143 TABLE DATA public agents metacarta
3; 0 17147 TABLE DATA public ingeststatus metacarta
4; 0 17156 TABLE DATA public authconnectors metacarta
5; 0 17161 TABLE DATA public authconnections metacarta
6; 0 17175 TABLE DATA public connectors metacarta
7; 0 17180 TABLE DATA public repoconnections metacarta
8; 0 17198 TABLE DATA public jobs metacarta
9; 0 17210 TABLE DATA public schedules metacarta
10; 0 17220 TABLE DATA public jobcollections metacarta
11; 0 17227 TABLE DATA public jobqueue metacarta
12; 0 30176 TABLE DATA public repohistory metacarta
13; 0 30191 TABLE DATA public throttlespec metacarta
14; 0 30198 TABLE DATA public jobhopfilters metacarta
15; 0 30212 TABLE DATA public hopcount metacarta
16; 0 30226 TABLE DATA public intrinsiclink metacarta
17; 0 30239 TABLE DATA public hopdeletedeps metacarta
18; 0 30257 TABLE DATA public robotsdata metacarta
19; 0 30264 TABLE DATA public dnsdata metacarta
20; 0 0 BLOBS - BLOBS
[EMAIL PROTECTED]:/common$









---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

   http://www.postgresql.org/about/donate

Re: [ADMIN] Export/import issue/question

[Tom Lane]

Karl Wright <[EMAIL PROTECTED]> writes:
> and then I installed 8.1, and attempted the following:
> pg_restore --file dbsnapshot --format=t --table=ingeststatus -a
> But, I get the following error:
> pg_restore: [tar archiver] could not find header for file toc.dat in tar 
> archive

Oh, I'm overthinking the problem.  You left out some details here,
right?  Like it sat and did nothing until you hit control-D?

The above command is wrong because --file is an *output* switch for
pg_restore --- it would have tried to read a tar archive from stdin,
and the "could not find header" complaint is what you get when it hits
immediate EOF and the tar format has been forced on the command line.
(You would have gotten a more recognizable complaint without --format=t,
which is redundant anyway.)  Fortunately, it doesn't seem to try to
write the output file right away, so the dumpfile didn't get trashed.

Correct usage would be something like

pg_restore --table=ingeststatus -a dbsnapshot >restore.sql

or add -d etc switches to issue SQL directly to the target database.

regards, tom lane

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [ADMIN] archive_command does not execute

[Kevin Grittner]

>>> On Tue, Jun 19, 2007 at 11:16 AM, in message <[EMAIL PROTECTED]>,
Tom Arthurs <[EMAIL PROTECTED]> wrote: 
> 
> Looks like you are expecting the archive command to run when you shut 
> down the data base. It won't.  It only runs when the xlog gets full and 
> the system needs to recycle to a new logfile.
 
If you need to force a WAL file to test your backup process, try running
something like:
 
select pg_switch_xlog();
 
http://www.postgresql.org/docs/8.2/interactive/functions-admin.html#FUNCTIONS-ADMIN-BACKUP-TABLE
 
-Kevin
 



---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

[ADMIN] reindex in v8.2

[Bill Willits]

Hello:

We are in the process of upgrading posgres from v7.3.9 to v8.2.4  In our 
current environment (v7.3), we run a reindex operation on all tables to recover 
space and improve performance (we have several tables with high insert/update 
load - no deletes).  Is it likely that the reindex will still be beneficial 
after the upgrade?  Or has the pg code changed such that this operation is 
obsolete?

Thanks in advance.
Bill Willits

Re: [ADMIN] reindex in v8.2

[Alvaro Herrera]

Bill Willits wrote:
> Hello:
> 
> We are in the process of upgrading posgres from v7.3.9 to v8.2.4  In
> our current environment (v7.3), we run a reindex operation on all
> tables to recover space and improve performance (we have several
> tables with high insert/update load - no deletes).  Is it likely that
> the reindex will still be beneficial after the upgrade?  Or has the pg
> code changed such that this operation is obsolete?

The index code was improved in 7.4, but some reindexing is still needed
in (rarer) corner cases.  Try getting rid of the reindex and track your
indexes sizes for a while.  If you don't notice a problem you can forget
it entirely.  Most people gets away without it.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [ADMIN] reindex in v8.2

[Dan Harris]

Bill Willits wrote:

Hello:
 
We are in the process of upgrading posgres from v7.3.9 to v8.2.4  In our 
current environment (v7.3), we run a reindex operation on all tables to 
recover space and improve performance (we have several tables with high 
insert/update load - no deletes).  Is it likely that the reindex will 
still be beneficial after the upgrade?  Or has the pg code changed such 
that this operation is obsolete?
 
Thanks in advance.

Bill Willits


When you reload your dump file into 8.2, the indexes should be created fresh and 
AFAIK, a reindex at that point would not gain anything for you.


---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [ADMIN] archive_command does not execute

[Simon Riggs]

On Tue, 2007-06-19 at 08:17 -0400, George Wilk wrote:

>  archive_command = 'touch /var/lib/pgsql/bkp/myfile'

Presumably you understand that an archive_command like the above is not
ever going to do any archiving?

set

log_min_messages = DEBUG1

if you want to see the archive messages.

But it seems like you should be able to do 

ls -l /var/lib/pgsql/bkp/myfile

to check your archive_command has succeeded, using your example

-- 
  Simon Riggs 
  EnterpriseDB   http://www.enterprisedb.com



---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [ADMIN] Postgres VS Oracle

[Simon Riggs]

On Mon, 2007-06-18 at 17:55 +0200, David Tokmatchi wrote:

> I am DBA for Oracle and beginner on Postgres. For an company in
> France, I must make a comparative study, between Postgres and Oracle.
> Can you send any useful document which can help me.
> Scalability ? Performance? Benchmark ? Availability ? Architecture ?
> Limitation : users, volumes ? Resouces needed ? Support ?

I would suggest you make your comparison based upon your specific needs,
not a purely abstract comparison. If your not sure what your
requirements are, research those first.

-- 
  Simon Riggs 
  EnterpriseDB   http://www.enterprisedb.com



---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

[ADMIN] initdb problem

[Joe Barwell]

Hello people,

Having installed the universal binary for pg 8.2.4 on my mac
running 10.3.9, I'm now trying to use the initdb command,
but keep running into problems. I can't seem to get the
right syntax. Can anyone suggest where I'm going wrong?
Here's what terminal shows:

Acorn acorn 1 acorn$ login root
Password:
Last login: Thu Jun 14 13:43:54 on ttyp1
Welcome to Darwin!
Acorn:~ root# su postgres
shell-init: could not get current directory: getcwd: cannot
access parent directories: Permission denied
su: /dev/null/.bashrc: Not a directory
Acorn:/var/root postgres$ initdb -D
/Library/PostgreSQL8/data
su: initdb: command not found
Acorn:/var/root postgres$ cd
chdir: could not get current directory: getcwd: cannot
access parent directories: Permission denied
su: cd: /dev/null: Not a directory
Acorn:/var/root postgres$ cwd
su: cwd: command not found
Acorn:/var/root postgres$ /Library/PostgreSQL8/initdb -D
/Library/PostgreSQL8/data
su: /Library/PostgreSQL8/initdb: No such file or directory
Acorn:/var/root postgres$ /Library/PostgreSQL8/bin/initdb -D
/Library/PostgreSQL8/data
could not identify current directory: Permission denied
could not identify current directory: Permission denied
could not identify current directory: Permission denied
The program "postgres" is needed by initdb but was not found
in the
same directory as "initdb".
Check your installation.
Acorn:/var/root postgres$

TIA,

Joe

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [ADMIN] initdb problem

[James Herbers]

No MAC expert but try this when changing to the postgres user:
   su - postgres
the hyphen gives you an environment for the postgres user.

J. Herbers

Quoting Joe Barwell <[EMAIL PROTECTED]>:


Hello people,

Having installed the universal binary for pg 8.2.4 on my mac
running 10.3.9, I'm now trying to use the initdb command,
but keep running into problems. I can't seem to get the
right syntax. Can anyone suggest where I'm going wrong?
Here's what terminal shows:

Acorn acorn 1 acorn$ login root
Password:
Last login: Thu Jun 14 13:43:54 on ttyp1
Welcome to Darwin!
Acorn:~ root# su postgres
shell-init: could not get current directory: getcwd: cannot
access parent directories: Permission denied
su: /dev/null/.bashrc: Not a directory
Acorn:/var/root postgres$ initdb -D
/Library/PostgreSQL8/data
su: initdb: command not found
Acorn:/var/root postgres$ cd
chdir: could not get current directory: getcwd: cannot
access parent directories: Permission denied
su: cd: /dev/null: Not a directory
Acorn:/var/root postgres$ cwd
su: cwd: command not found
Acorn:/var/root postgres$ /Library/PostgreSQL8/initdb -D
/Library/PostgreSQL8/data
su: /Library/PostgreSQL8/initdb: No such file or directory
Acorn:/var/root postgres$ /Library/PostgreSQL8/bin/initdb -D
/Library/PostgreSQL8/data
could not identify current directory: Permission denied
could not identify current directory: Permission denied
could not identify current directory: Permission denied
The program "postgres" is needed by initdb but was not found
in the
same directory as "initdb".
Check your installation.
Acorn:/var/root postgres$

TIA,

Joe

---(end of broadcast)---
TIP 6: explain analyze is your friend






---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [ADMIN] initdb problem

[Phillip Smith]

I'm guessing all the problems below are something to do with the 'postgres'
user not having a correct shell login setup. It looks like the home
directory is set to /dev/null which would explain all the "not a directory"
errors.

You'll need to edit the postgers user to have a proper login shell
(/bin/bash maybe?) but I specifically avoid Mac's so that's about all I can
tell you. B)

Cheers,
~p

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of James Herbers
Sent: Wednesday, 20 June 2007 11:11
To: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] initdb problem

No MAC expert but try this when changing to the postgres user:
su - postgres
the hyphen gives you an environment for the postgres user.

J. Herbers

Quoting Joe Barwell <[EMAIL PROTECTED]>:

> Hello people,
>
> Having installed the universal binary for pg 8.2.4 on my mac
> running 10.3.9, I'm now trying to use the initdb command,
> but keep running into problems. I can't seem to get the
> right syntax. Can anyone suggest where I'm going wrong?
> Here's what terminal shows:
>
> Acorn acorn 1 acorn$ login root
> Password:
> Last login: Thu Jun 14 13:43:54 on ttyp1
> Welcome to Darwin!
> Acorn:~ root# su postgres
> shell-init: could not get current directory: getcwd: cannot
> access parent directories: Permission denied
> su: /dev/null/.bashrc: Not a directory
> Acorn:/var/root postgres$ initdb -D
> /Library/PostgreSQL8/data
> su: initdb: command not found
> Acorn:/var/root postgres$ cd
> chdir: could not get current directory: getcwd: cannot
> access parent directories: Permission denied
> su: cd: /dev/null: Not a directory
> Acorn:/var/root postgres$ cwd
> su: cwd: command not found
> Acorn:/var/root postgres$ /Library/PostgreSQL8/initdb -D
> /Library/PostgreSQL8/data
> su: /Library/PostgreSQL8/initdb: No such file or directory
> Acorn:/var/root postgres$ /Library/PostgreSQL8/bin/initdb -D
> /Library/PostgreSQL8/data
> could not identify current directory: Permission denied
> could not identify current directory: Permission denied
> could not identify current directory: Permission denied
> The program "postgres" is needed by initdb but was not found
> in the
> same directory as "initdb".
> Check your installation.
> Acorn:/var/root postgres$
>
> TIA,
>
> Joe
>
> ---(end of broadcast)---
> TIP 6: explain analyze is your friend
>




---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


***Confidentiality and Privilege Notice***

The material contained in this message is privileged and confidential to
the addressee.  If you are not the addressee indicated in this message or
responsible for delivery of the message to such person, you may not copy
or deliver this message to anyone, and you should destroy it and kindly
notify the sender by reply email.

Information in this message that does not relate to the official business
of Weatherbeeta must be treated as neither given nor endorsed by Weatherbeeta.
Weatherbeeta, its employees, contractors or associates shall not be liable
for direct, indirect or consequential loss arising from transmission of this
message or any attachments

---(end of broadcast)---
TIP 6: explain analyze is your friend