Re: [GENERAL] pg_config --sharedir points to the wrong folder.. is this a problem?

[Jennifer Trey]

On Fri, Jul 31, 2009 at 3:02 AM, Daniel Verite wrote:

>Jennifer Trey wrote:
>
> > >> locate pg_config
> > /opt/PostgreSQL/8.4/bin/pg_config
> > /opt/PostgreSQL/8.4/include/ecpg_config.h
> > /opt/PostgreSQL/8.4/include/pg_config.h
> > /opt/PostgreSQL/8.4/include/pg_config_manual.h
> > /opt/PostgreSQL/8.4/include/pg_config_os.h
> > /opt/PostgreSQL/8.4/include/postgresql/server/pg_config.h
> > /opt/PostgreSQL/8.4/include/postgresql/server/pg_config_manual.h
> > /opt/PostgreSQL/8.4/include/postgresql/server/pg_config_os.h
> > /opt/PostgreSQL/8.4/share/man/man1/pg_config.1
> > /usr/bin/pg_config
> > /usr/share/man/man1/pg_config.1.gz
>
> > >> echo $PATH
> > /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
> >
> > I am guessing I should delete the pg_config (or else there would be a
> > conflict, right?) in the /usr/bin
>
> Actually you should restrain from doing that, because it would break the
> package that installed that file, and then your system would become harder
> to
> manage in the long run. It's better to act at the package level with the
> dpkg
> command.
>
> /usr/bin/pg_config is part of the libpq-dev package (this can be found with
> dpkg -S /usr/bin/pg_config)
>
> Probably you haven't uninstalled this package, which you can check by
> running:
> dpkg -s libpq-dev (look at the Status field). In this case, remove it
> (apt-get remove libpq-dev)
>



Thanks.Yes, it was still there. I un-installed it.
Should I still add the pg_config to the $PATH ?
>> export PATH=/opt/PostgreSQL/8.4/bin/:$PATH




> You can also remove the postgresql-common and postgresql-client-8.3
> packages
> if they're still there and you want to avoid any possible conflict with
> your
> other postgresql installation.
> dpkg -l 'postgresql*' also displays the list of most PG-related packages
> and
> whether they're installed or not.
>


r...@ubuntu-904-jaunty-64-minimal:~# dpkg -l 'postgresql*'
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err:
uppercase=bad)
||/ Name   VersionDescription
+++-==-==-
pn  postgresql  (no description
available)
un  postgresql-7.4  (no description
available)
un  postgresql-8.0  (no description
available)
rc  postgresql-8.3 8.3.7-1object-relational
SQL database, version 8.3 server
pn  postgresql-client   (no description
available)
pn  postgresql-client-8.3   (no description
available)
pn  postgresql-client-common(no description
available)
rc  postgresql-common  97 PostgreSQL
database-cluster manager
un  postgresql-dev  (no description
available)
un  postgresql-doc-8.3  (no description
available)

Looks fine?



> > Is there other things that could have been destroyed by the bad
> > un-installment other than pg_config or was that it ?
>
> It doesn't look like the uninstallation of the server itself has gone bad
> in
> any way. You mentioned removing the package without stopping the server
> beforehand, but personally I doubt that the package uninstall process
> doesn't
> do it automatically.
>


Ok, that's good to hear. I must have missed un-installing the package
mentioned above.
What I did was to uninstall the postgresql-common which then removed some
other depending packages.I am not sure how this package got installed.



> Best regards,
> --
> Daniel
> PostgreSQL-powered mail user agent and storage:
> http://www.manitou-mail.org
>


Sincerely / Jennifer

Re: [GENERAL] SVN and Postgres 8.3

[Phoenix Kiula]

On Fri, Jul 31, 2009 at 12:29 PM, Greg Smith wrote:
> On Thu, 30 Jul 2009, Phoenix Kiula wrote:
>
>> svn: error while loading shared libraries: libpq.so.4: cannot open
>> shared object file: No such file or directory
>
> There's a long guide to working around the issues you run into converting
> from the stock PostgreSQL version to using the newer ones at
> http://www.westnet.com/~gsmith/content/postgresql/pgrpm.htm you should take
> a look at to see how to avoid getting stuck in this position again, and all
> you probably need to do to get out of your current jam is grab the
> compat-postgresql-libs packages from the same place you grabbed the rest of
> 8.3 from in order to put back libpq.so.4.



Perfect Greg. This did it!

Cheers

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Can I have a look at your TuningWizard generated config file?

[Jennifer Trey]

Hi,
I wanted to start with the TuningWizard and then configure the one they
suggested, thinking that I am starting from good default values.

But I am not able to run TuningWizard for some strange reason, but I am
actually mostly interested in some few settings that it usually provides.
Especially
max_fsm_pages
max_fsm_relations

and also the Vacuum settings, track_activities and such.. I don't know how
to set those things myself but I have figured out some of the other things.

The computer is a Quad Core with 8GB memory and running on Mixed mode on
Ubuntu Server 9.04

I use pg_admin to configure the config file because it provides a good
overview of the things that are set and values.
So this is a special request, if you could provide a screen shot with
perhaps three images, then I could go through it myself one by one and do
similar things on mine.

Thank you and I hope I am not asking to much :)

- Jennifer

Re: [GENERAL] Can I have a look at your TuningWizard generated config file?

[Thomas Kellerer]

Jennifer Trey, 31.07.2009 12:17:

Hi,

I wanted to start with the TuningWizard and then configure the one they 
suggested, thinking that I am starting from good default values.


But I am not able to run TuningWizard for some strange reason, but I am 
actually mostly interested in some few settings that it usually provides. 
Especially 
max_fsm_pages

max_fsm_relations

Which Postgres version are you using? 


IIRC those settings are not longer valid for 8.4

THomas


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Can I have a look at your TuningWizard generated config file?

[Jennifer Trey]

On Fri, Jul 31, 2009 at 12:29 PM, Thomas Kellerer wrote:

> Jennifer Trey, 31.07.2009 12:17:
>
>> Hi,
>>
>> I wanted to start with the TuningWizard and then configure the one they
>> suggested, thinking that I am starting from good default values.
>>
>> But I am not able to run TuningWizard for some strange reason, but I am
>> actually mostly interested in some few settings that it usually provides.
>> Especially max_fsm_pages
>> max_fsm_relations
>>
>>  Which Postgres version are you using?
> IIRC those settings are not longer valid for 8.4
>
> THomas



Aha, ok. I am using 8.4. They are still to be set, confusing.



>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

Thanks / Jen

Re: [GENERAL] Can I have a look at your TuningWizard generated config file?

[Magnus Hagander]

On Fri, Jul 31, 2009 at 12:35, Jennifer Trey wrote:
> On Fri, Jul 31, 2009 at 12:29 PM, Thomas Kellerer 
> wrote:
>>
>> Jennifer Trey, 31.07.2009 12:17:
>>>
>>> Hi,
>>>
>>> I wanted to start with the TuningWizard and then configure the one they
>>> suggested, thinking that I am starting from good default values.
>>>
>>> But I am not able to run TuningWizard for some strange reason, but I am
>>> actually mostly interested in some few settings that it usually provides.
>>> Especially max_fsm_pages
>>> max_fsm_relations
>>>
>> Which Postgres version are you using?
>> IIRC those settings are not longer valid for 8.4
>>
>> THomas
>
> Aha, ok. I am using 8.4. They are still to be set, confusing.

AFAICS, the edb tuning wizard has not (yet) been updated to support
PostgreSQL 8.4. The hints it gives are for 8.3 and earlier. It would
probably be a good idea if they gave a warning for that, but I take it
they don't :-)

There may be other issues as well, so read up on the documentation for
anything else it recommends to change.

As for these two values, you can just ignore them - they are tuned
dynamically on 8.4.


-- 
 Magnus Hagander
 Self: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] pg_config --sharedir points to the wrong folder.. is this a problem?

[Daniel Verite]

Jennifer Trey wrote:

> Should I still add the pg_config to the $PATH ?
> >> export PATH=/opt/PostgreSQL/8.4/bin/:$PATH

Yes.

> pn  postgresql  (no description
> available)
> un  postgresql-7.4  (no description
> available)
> un  postgresql-8.0  (no description
> available)
> rc  postgresql-8.3 8.3.7-1object-relational
> SQL database, version 8.3 server
> pn  postgresql-client   (no description
> available)
> pn  postgresql-client-8.3   (no description
> available)
> pn  postgresql-client-common(no description
> available)
> rc  postgresql-common  97 PostgreSQL
> database-cluster manager
> un  postgresql-dev  (no description
> available)
> un  postgresql-doc-8.3  (no description
> available)
> 
> Looks fine?

Definitely.

Best regards,
-- 
 Daniel
 PostgreSQL-powered mail user agent and storage: http://www.manitou-mail.org

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Can I have a look at your TuningWizard generated config file?

[Jennifer Trey]

Ok. I will.. when it comes to the other settings, like autovacuum and such.
Could I have a look at yours ? :)
I will list the ones that I find important and that i already have figured
out good values for, please fill in if there is more I should look at:

max_connections
effective_cache
random_page_cost
maintenance_work_mem
shared_buffers
work_mem
max_fsm_pages(scratched)
max_fsm_relations(scratched)
wal_buffers

But then there is the log and autovacuum stuff that I have no idea about and
that believe that I could just take from someone else and not really machine
dependant..

Thanks in advance / Jennifer



On Fri, Jul 31, 2009 at 12:48 PM, Magnus Hagander wrote:

> On Fri, Jul 31, 2009 at 12:35, Jennifer Trey
> wrote:
> > On Fri, Jul 31, 2009 at 12:29 PM, Thomas Kellerer 
> > wrote:
> >>
> >> Jennifer Trey, 31.07.2009 12:17:
> >>>
> >>> Hi,
> >>>
> >>> I wanted to start with the TuningWizard and then configure the one they
> >>> suggested, thinking that I am starting from good default values.
> >>>
> >>> But I am not able to run TuningWizard for some strange reason, but I am
> >>> actually mostly interested in some few settings that it usually
> provides.
> >>> Especially max_fsm_pages
> >>> max_fsm_relations
> >>>
> >> Which Postgres version are you using?
> >> IIRC those settings are not longer valid for 8.4
> >>
> >> THomas
> >
> > Aha, ok. I am using 8.4. They are still to be set, confusing.
>
> AFAICS, the edb tuning wizard has not (yet) been updated to support
> PostgreSQL 8.4. The hints it gives are for 8.3 and earlier. It would
> probably be a good idea if they gave a warning for that, but I take it
> they don't :-)
>
> There may be other issues as well, so read up on the documentation for
> anything else it recommends to change.
>
> As for these two values, you can just ignore them - they are tuned
> dynamically on 8.4.
>
>
> --
>  Magnus Hagander
>  Self: http://www.hagander.net/
>  Work: http://www.redpill-linpro.com/
>

[GENERAL] Design Database, 3 degrees of Users.

[Andre Lopes]

I need to design a Database that will handle 3 degrees of users:


Administrators - They can see all the information in the database.

Managers - They only can see the information of his dependants.

Dependants - Theirs action must be aprovet by the managers.


Wich the best way to implement this in PostGreSQL? There is some database
examples doing this? Some OpenSource Project?

I'am designing a Database for doing this, but I don't have sure I'am doing
well.


Please give me some advice.
Best Regards,
André Lopes.

[GENERAL] MSSQL to PostgreSQL

[Thom Brown]

Hi all,

We're migrating the contents of an old MSSQL server to PostgreSQL 8.3.7, so
a full conversion is required.  Does anyone know of any guides which
highlight common gotchas and other userful information?

Thanks

Thom

Re: [GENERAL] Design Database, 3 degrees of Users.

[Sam Mason]

On Fri, Jul 31, 2009 at 12:38:30PM +0100, Andre Lopes wrote:
> I need to design a Database that will handle 3 degrees of users:
> 
> Administrators - They can see all the information in the database.
> Managers - They only can see the information of his dependants.
> Dependants - Theirs action must be aprovet by the managers.
> 
> Wich the best way to implement this in PostGreSQL? There is some database
> examples doing this? Some OpenSource Project?

Depends on how much this separation should be done inside the database,
and how much outside the database.  Within PG, the things that will help
you are roles[1], views[2], and functions[3] with "security definer"
set.

-- 
  Sam  http://samason.me.uk/

 [1] http://www.postgresql.org/docs/current/static/user-manag.html
 [2] http://www.postgresql.org/docs/current/static/sql-createview.html
 [3] http://www.postgresql.org/docs/current/static/sql-createfunction.html

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] MSSQL to PostgreSQL

[Merlin Moncure]

On Fri, Jul 31, 2009 at 8:47 AM, Thom Brown wrote:
> Hi all,
>
> We're migrating the contents of an old MSSQL server to PostgreSQL 8.3.7, so
> a full conversion is required.  Does anyone know of any guides which
> highlight common gotchas and other userful information?

That's going to depend a lot on how many features of the database you
were using...especially higher level features like stored procedures.
Converting the schema and the data shouldn't be too bad -- there are a
number of relatively easy ways to do it including microsoft DTS
levering the pg odbc driver.

The biggest change is going to be getting used to the new tools...if
you haven't already, i'd highly recommend mastering psql (don't lean
too much on pgadmin) and learning basic administration tasks like
restarting the database while active, killing particular backends,
backup strategies, etc.  If the sql server installation is 2000 or
older, you should be able to port most things pretty easily except for
any t-sql procedures.  PostgreSQL supports functions which are a
little different so some of the things you used to do in t-sql you may
have to do in sql scripts and an external scheduler such as cron.

Many things in PostgeSQL are easier than you might be used to...it's
got superior concurrency handing and a much better type system.  Good
luck!

merlin

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] MSSQL to PostgreSQL

[Thom Brown]

> That's going to depend a lot on how many features of the database you
> were using...especially higher level features like stored procedures.
> Converting the schema and the data shouldn't be too bad -- there are a
> number of relatively easy ways to do it including microsoft DTS
> levering the pg odbc driver.
>
> The biggest change is going to be getting used to the new tools...if
> you haven't already, i'd highly recommend mastering psql (don't lean
> too much on pgadmin) and learning basic administration tasks like
> restarting the database while active, killing particular backends,
> backup strategies, etc.  If the sql server installation is 2000 or
> older, you should be able to port most things pretty easily except for
> any t-sql procedures.  PostgreSQL supports functions which are a
> little different so some of the things you used to do in t-sql you may
> have to do in sql scripts and an external scheduler such as cron.
>
> Many things in PostgeSQL are easier than you might be used to...it's
> got superior concurrency handing and a much better type system.  Good
> luck!
>
> merlin
>

Learning PostgreSQL isn't a problem since most of our database servers are
Postgres.  It's just an old database we want to convert.

Thankfully we don't rely on DTS but I think there may be some refactoring of
stored procedures into functions as some return multiple datasets.

And I personally much prefer Postgres to MSSQL Server any day.

Thom

Re: [GENERAL] Design Database, 3 degrees of Users.

[bricklen]

Would Veil be useful to you?

http://veil.projects.postgresql.org/curdocs/index.html

On Fri, Jul 31, 2009 at 4:38 AM, Andre Lopes wrote:
> I need to design a Database that will handle 3 degrees of users:
>
>
> Administrators - They can see all the information in the database.
>
> Managers - They only can see the information of his dependants.
>
> Dependants - Theirs action must be aprovet by the managers.
>
> Wich the best way to implement this in PostGreSQL? There is some database
> examples doing this? Some OpenSource Project?
>
> I'am designing a Database for doing this, but I don't have sure I'am doing
> well.
>
> Please give me some advice.
>
> Best Regards,
> André Lopes.

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Can I have a look at your TuningWizard generated config file?

[Jennifer Trey]

Is autovacuum on by default?
or do I uncomment

#autovacuum = on

and

#track_counts = on

to enable it? Anything else I should do?

Thanks / Jennifer

On Fri, Jul 31, 2009 at 1:10 PM, Jennifer Trey wrote:

> Ok. I will.. when it comes to the other settings, like autovacuum and such.
> Could I have a look at yours ? :)
> I will list the ones that I find important and that i already have figured
> out good values for, please fill in if there is more I should look at:
>
> max_connections
> effective_cache
> random_page_cost
> maintenance_work_mem
> shared_buffers
> work_mem
> max_fsm_pages(scratched)
> max_fsm_relations(scratched)
> wal_buffers
>
> But then there is the log and autovacuum stuff that I have no idea about
> and that believe that I could just take from someone else and not really
> machine dependant..
>
> Thanks in advance / Jennifer
>
>
>
> On Fri, Jul 31, 2009 at 12:48 PM, Magnus Hagander wrote:
>
>> On Fri, Jul 31, 2009 at 12:35, Jennifer Trey
>> wrote:
>> > On Fri, Jul 31, 2009 at 12:29 PM, Thomas Kellerer 
>> > wrote:
>> >>
>> >> Jennifer Trey, 31.07.2009 12:17:
>> >>>
>> >>> Hi,
>> >>>
>> >>> I wanted to start with the TuningWizard and then configure the one
>> they
>> >>> suggested, thinking that I am starting from good default values.
>> >>>
>> >>> But I am not able to run TuningWizard for some strange reason, but I
>> am
>> >>> actually mostly interested in some few settings that it usually
>> provides.
>> >>> Especially max_fsm_pages
>> >>> max_fsm_relations
>> >>>
>> >> Which Postgres version are you using?
>> >> IIRC those settings are not longer valid for 8.4
>> >>
>> >> THomas
>> >
>> > Aha, ok. I am using 8.4. They are still to be set, confusing.
>>
>> AFAICS, the edb tuning wizard has not (yet) been updated to support
>> PostgreSQL 8.4. The hints it gives are for 8.3 and earlier. It would
>> probably be a good idea if they gave a warning for that, but I take it
>> they don't :-)
>>
>> There may be other issues as well, so read up on the documentation for
>> anything else it recommends to change.
>>
>> As for these two values, you can just ignore them - they are tuned
>> dynamically on 8.4.
>>
>>
>> --
>>  Magnus Hagander
>>  Self: http://www.hagander.net/
>>  Work: http://www.redpill-linpro.com/
>>
>
>

Re: [GENERAL] Can I have a look at your TuningWizard generated config file?

[Adrian Klaver]

On Friday 31 July 2009 6:18:30 am Jennifer Trey wrote:
> Is autovacuum on by default?
> or do I uncomment
>
> #autovacuum = on
>
> and
>
> #track_counts = on
>
> to enable it? Anything else I should do?
>
> Thanks / Jennifer

You might check out this part of the manual :)
http://www.postgresql.org/docs/8.4/interactive/runtime-config-autovacuum.html

-- 
Adrian Klaver
akla...@comcast.net

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] MSSQL to PostgreSQL

[Ivan Sergio Borgonovo]

On Fri, 31 Jul 2009 13:47:39 +0100
Thom Brown  wrote:

> Hi all,

> We're migrating the contents of an old MSSQL server to PostgreSQL
> 8.3.7, so a full conversion is required.  Does anyone know of any
> guides which highlight common gotchas and other userful
> information?


http://wiki.postgresql.org/wiki/Microsoft_SQL_Server_to_PostgreSQL_Migration_by_Ian_Harding

http://edoceo.com/creo/ms2pg

These were the places I read when I had to migrate some MS SQL DB to
Postgresql.

I admit I mostly did it by exporting csv from MS SQL[1],
refactoring the schema and rewriting from scratch functions... but
those were the places where I read the info I needed.

[1] suddenly MS SQL became unable to export proper csv so I remember
I wrote an rudimentary odbc2csv tool as well. Since it was inspired
by an even more rudimentary work of a colleague I'll ask if he can
release it under GPL if you'll find yourself in the need of such a
beast.

You may also find useful FreeTDS
http://www.freetds.org/
http://www.webthatworks.it/d1/page/odbc,_freetds_and_microsoft_sql_(and_php)
and dblink
http://www.postgresonline.com/journal/index.php?/archives/44-Using-DbLink-to-access-other-PostgreSQL-Databases-and-Servers.html
http://www.postgresql.org/docs/8.3/static/dblink.html


-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] How do I run PG Tuning Wizard on Linux?

[Ashesh Vashi]

Hi Jennifer,

Some times, gtk does not work as expected.
Please try to run TuningWizard using the following command:
DISPLAY=:0.0 
LD_LIBRARY_PATH=/opt/PostgreSQL/EnterpriseDB-TuningWizard/lib 
/opt/PostgreSQL/EnterpriseDB-TuningWizard/TuningWizard.


Hope - this will help you.
BTW: TuningWizard is updated to work with PostgreSQL 8.4 version.

Jennifer Trey wrote:

Thank you for your answer.

I did export the LD_LIBRARY_PATH and now the complain is something 
else.. progress :)


Error: Unable to initialize gtk, is DISPLAY set properly?

I have also launched the TuningWizard from an icon and I got to the 
step (development, mixed, dedicated) as before and then the same 
message (connecting to webserver) and then it disappears.


Thanks / Jen


--
Thanks & Regards,
Ashesh Vashi

EnterpriseDB INDIA: http://www.enterprisedb.com

[GENERAL] tsearch2 on Synology

[Dennis Janezic]

Hi,

 

I am using a Synology NAS and want to use the installed postgresql 8.2.5
database as backend for mediawiki 1.25.1. 

 

The problem is that mediawiki needs tsearch2 installed, but I can't find a
solution to get tsearch2 on my NAS. There are several packages for nearly
all linux distributions on the net, but I can't find a hint for Synology.
Synology uses ipkg for installing software, but the automatic search does
not find any relevant packages like contrib.

 

Anyone an idea or even some experiances?

 

 

Thanks for response,

 

Dennis

Re: [GENERAL] Can I have a look at your TuningWizard generated config file?

[Magnus Hagander]

On Fri, Jul 31, 2009 at 15:47, Ashesh
Vashi wrote:
> Magnus Hagander wrote:
> AFAICS, the edb tuning wizard has not (yet) been updated to support
> PostgreSQL 8.4. The hints it gives are for 8.3 and earlier. It would
> probably be a good idea if they gave a warning for that, but I take it
> they don't :-)
>
> TuningWizard (latest version 1.3) has been updated to support PostgreSQL
> 8.4.

Your download page only lists 1.1 as download :-) Glad to hear an
updated version exists, I assume it'll make it there eventually?


-- 
 Magnus Hagander
 Self: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] why is autovacuum still ongoing even if set to off ?

[Costin Grigoras]

Ok, if autovacuum doesn't actually lock the tables for this long time 
then it's fine. But I started investigating this because the inserts 
were hanging and I'm still puzzled why it's active when it shouldn't be :)


In principle you are right, but in this particular case autovacuum gets 
in the way since internal cleanup procedures already do 
cluster/vacuum/analyze when needed.


Anyway, now the autovacuum thread is gone so ... I'll investigate more 
next time when it pops up.


Thanks a lot for your help!

Cheers,

.costin

Scott Marlowe wrote:

On Fri, Jul 31, 2009 at 12:24 AM, Costin Grigoras wrote:

  

=> show autovacuum;
autovacuum

off

I really overdid it, I know, but this issue is very annoying. Even with
these settings it's still ongoing.

The IO doesn't seem to be an issue, the DB sits on a RAID6 of 8 10K rpm
disks while the logs are on another identical controller, 512M cache on
each. 32G of RAM with 30 being only cache also help. fsync is off and below
is the output of iostat. But something is indeed weird, if autovacuum
doesn't consume CPU and doesn't do much IO then where does it spend the time



sleeping so as not to get in the way.

  

Btw, I've tried "vacuum full analyze" on the same table that autovacuum
reports vacuumed in 542 seconds and it only took 36 seconds on the command
line (when the files were not in cache, 7 seconds when they were)! And I see
the vacuum process using a lot of cpu in "top" while the autovacuum process
is always at 2-3% only. This raises another question, why is autovacuum
taking so long to do much less?!



What's the difference between autovacuum_vacuum_cost_delay and
vacuum_cost_delay ?

Since autovacuum seems to not be causing any actual problems, why are
you so invested in turning it off instead of making sure it's tuned to
not get in the way?
  


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Can I have a look at your TuningWizard generated config file?

[Ashesh Vashi]

Hi Magnus,

Magnus Hagander wrote:

On Fri, Jul 31, 2009 at 15:47, Ashesh
Vashi wrote:

Magnus Hagander wrote:
AFAICS, the edb tuning wizard has not (yet) been updated to support
PostgreSQL 8.4. The hints it gives are for 8.3 and earlier. It would
probably be a good idea if they gave a warning for that, but I take it
they don't :-)

TuningWizard (latest version 1.3) has been updated to support PostgreSQL
8.4.

Your download page only lists 1.1 as download :-) Glad to hear an
updated version exists, I assume it'll make it there eventually?

Right now, the latest version is available only through the stack-builder.
It will be available soon on download pages too. :)

--
Thanks & Regards,
Ashesh Vashi

EnterpriseDB INDIA: http://www.enterprisedb.com

Re: [GENERAL] Can I have a look at your TuningWizard generated config file?

[Ashesh Vashi]

Hi Jennifer,

Magnus Hagander wrote:

On Fri, Jul 31, 2009 at 12:35, Jennifer Trey wrote:

On Fri, Jul 31, 2009 at 12:29 PM, Thomas Kellerer 
wrote:

Jennifer Trey, 31.07.2009 12:17:

Hi,

I wanted to start with the TuningWizard and then configure the one they
suggested, thinking that I am starting from good default values.

But I am not able to run TuningWizard for some strange reason, but I am
actually mostly interested in some few settings that it usually provides.
Especially max_fsm_pages
max_fsm_relations

Which Postgres version are you using?
IIRC those settings are not longer valid for 8.4

THomas

Aha, ok. I am using 8.4. They are still to be set, confusing.

AFAICS, the edb tuning wizard has not (yet) been updated to support
PostgreSQL 8.4. The hints it gives are for 8.3 and earlier. It would
probably be a good idea if they gave a warning for that, but I take it
they don't :-)
TuningWizard (latest version 1.3) has been updated to support PostgreSQL 
8.4.

As for these two values, you can just ignore them - they are tuned
dynamically on 8.4.

Agree.
It will be taken care automatically on 8.4.

--
Thanks & Regards,
Ashesh Vashi

EnterpriseDB INDIA: http://www.enterprisedb.com

Re: [GENERAL] Design Database, 3 degrees of Users.

[Rich Shepard]

On Fri, Jul 31, 2009 at 4:38 AM, Andre Lopes wrote:


I need to design a Database that will handle 3 degrees of users:

Administrators - They can see all the information in the database.
Managers - They only can see the information of his dependants.
Dependants - Theirs action must be aprovet by the managers.

Wich the best way to implement this in PostGreSQL? There is some database
examples doing this? Some OpenSource Project?

I'am designing a Database for doing this, but I don't have sure I'am doing
well.

Please give me some advice.


  You don't want to implement this in SQL, regardless of what DBMS you use
as the back end. Implementing different user classes (or roles as we call
them) is done in your middleware and UI.

  SQL is a set-oriented language for manipulating data stored in tables.
Your application code can specify the creation and use of VIEWS that depend
on the priviledges associated with each user when logged into the system. It
appears to me that you ought to take a step back and learn a bit more about
application development which uses a DBMS as a data storage back end.

Rich

--
Richard B. Shepard, Ph.D.   |  IntegrityCredibility
Applied Ecosystem Services, Inc.|Innovation
 Voice: 503-667-4517  Fax: 503-667-8863

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Can I have a look at your TuningWizard generated config file?

[Jennifer Trey]

I think I got everything now. Most things where on by default it seems.


#--
# RUNTIME STATISTICS
#--

# - Query/Index Statistics Collector -

track_activities = off  *#I turned this off
*#track_counts = on
#track_functions = none# none, pl, all
track_activity_query_size = 16kB
#update_process_title = on
#stats_temp_directory = 'pg_stat_tmp'


# - Statistics Monitoring -

#log_parser_stats = off
#log_planner_stats = off
#log_executor_stats = off
#log_statement_stats = off


#--
# AUTOVACUUM PARAMETERS
#--

#autovacuum = on# Enable autovacuum subprocess?  'on'
# requires track_counts to also be on.
#log_autovacuum_min_duration = -1# -1 disables, 0 logs all actions and
# their durations, > 0 logs only
# actions running at least this number
# of milliseconds.
#autovacuum_max_workers = 3# max number of autovacuum subprocesses
*autovacuum_naptime* = 20min# time between autovacuum runs
*autovacuum_vacuum_threshold* = 250# min number of row updates before
# vacuum
*autovacuum_analyze_threshold* = 125# min number of row updates before
# analyze
#autovacuum_vacuum_scale_factor = 0.2# fraction of table size before
vacuum
#autovacuum_analyze_scale_factor = 0.1# fraction of table size before
analyze
#autovacuum_freeze_max_age = 2# maximum XID age before forced
vacuum
# (change requires restart)
#autovacuum_vacuum_cost_delay = 20ms# default vacuum cost delay for
# autovacuum, in milliseconds;
# -1 means use vacuum_cost_delay
#autovacuum_vacuum_cost_limit = -1# default vacuum cost limit for
# autovacuum, -1 means use
# vacuum_cost_limit


I am not going for the TuningWizard anymore since I set everything up
manually that I believe it normally touches.

Thanks all (on the other threads as well :) ), you have been extremely
helpful. I must say that I love this mailing list. And PostgreSQL :)

Sincerely / Jennifer

Re: [GENERAL] Clients disconnect but query still runs

[Tatsuo Ishii]

> > Right. For this purpose, pgpool sends param packet to client
> > periodically while waiting for a reply from backend to detect if the
> > connection to the client is broken. If it's broken, pgool sends cancel
> > packet to backend not to waste backend machine's CPU cycle.
> 
> The downside to this is that it will cause spurious failures for
> transient network failures even if the network comes back before it's
> actually needed.

Can't we expect such a transient error to be fixed by underlying
TCP/IP stack?
--
Tatsuo Ishii
SRA OSS, Inc. Japan

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Can I have a look at your TuningWizard generated config file?

[Alvaro Herrera]

Jennifer Trey escribió:
> I think I got everything now. Most things where on by default it seems.
> 
> 
> #--
> # RUNTIME STATISTICS
> #--
> 
> # - Query/Index Statistics Collector -
> 
> track_activities = off  *#I turned this off

What for?

> #autovacuum_vacuum_scale_factor = 0.2# fraction of table size before
> vacuum
> #autovacuum_analyze_scale_factor = 0.1# fraction of table size before
> analyze

Hmm, does the tuning wizard not touch these?

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

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] MSSQL to PostgreSQL

[Merlin Moncure]

On Fri, Jul 31, 2009 at 9:17 AM, Thom Brown wrote:
>
>> That's going to depend a lot on how many features of the database you
>> were using...especially higher level features like stored procedures.
>> Converting the schema and the data shouldn't be too bad -- there are a
>> number of relatively easy ways to do it including microsoft DTS
>> levering the pg odbc driver.
>>
>> The biggest change is going to be getting used to the new tools...if
>> you haven't already, i'd highly recommend mastering psql (don't lean
>> too much on pgadmin) and learning basic administration tasks like
>> restarting the database while active, killing particular backends,
>> backup strategies, etc.  If the sql server installation is 2000 or
>> older, you should be able to port most things pretty easily except for
>> any t-sql procedures.  PostgreSQL supports functions which are a
>> little different so some of the things you used to do in t-sql you may
>> have to do in sql scripts and an external scheduler such as cron.
>>
>> Many things in PostgeSQL are easier than you might be used to...it's
>> got superior concurrency handing and a much better type system.  Good
>> luck!
>>
>> merlin
>
> Learning PostgreSQL isn't a problem since most of our database servers are
> Postgres.  It's just an old database we want to convert.
>
> Thankfully we don't rely on DTS but I think there may be some refactoring of
> stored procedures into functions as some return multiple datasets.

you meant to say t-sql?  DTS is data transformation services, you can
use it to do the one time schema and data converesions (it's not
perfect, but can be a time saver).

merlin

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] export csv file on XP

[Wang Kuo-Ying]

I want to know how to export csv file.

Command:
copy test to 'c:/test.csv'
delimiters ',' ;

but the error ERROR:  could not open file "c:/test.csv" for writing:
Permission denied

[GENERAL] export csv file on XP

[Wang Kuo-Ying]

I want to know how to export csv file.

Command:
copy test to 'c:/test.csv'
delimiters ',' ;

but the error ERROR:  could not open file "c:/test.csv" for writing:
Permission denied

[GENERAL] Grouping Question

[Ketema Harris]

I have a table defined as

CREATE TABLE mytable
(
  carrier varchar,
  start_time timestamp with time zone,
  call_date date,
  cost numeric,
  call_length numeric
)

I want to create a query that will generate a the following columns:

carrier, week, sum(call_length) as totallength, sum(cost) as total_cost
from mytable
group by carrier, (WHAT HERE?)
order by week, carrier


week is defined as a date range so something like 7/6/2009 - 7/13/2009

I would need the timestamps to be grouped into 7 day intervals  
starting from the first one and moving through the table. is this  
possible in a single query or would I have to write a function ?



--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] export csv file on XP

[Raymond O'Donnell]

On 31/07/2009 16:57, Wang Kuo-Ying wrote:

> Command:
> copy test to 'c:/test.csv'
> delimiters ',' ;
> 
> but the error ERROR:  could not open file "c:/test.csv" for writing:
> Permission denied

Looks like a permissions problem - check that the user as which the
server is running has read permissions on that file.

Ray.

--
Raymond O'Donnell, Director of Music, Galway Cathedral, Ireland
r...@iol.ie
Galway Cathedral Recitals: http://www.galwaycathedral.org/recitals
--

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Grouping Question

[Sam Mason]

On Fri, Jul 31, 2009 at 12:09:51PM -0400, Ketema Harris wrote:
> I want to create a query that will generate a the following columns:
> 
> carrier, week, sum(call_length) as totallength, sum(cost) as total_cost
> from mytable
> group by carrier, (WHAT HERE?)
> order by week, carrier
> 
> week is defined as a date range so something like 7/6/2009 - 7/13/2009
> 
> I would need the timestamps to be grouped into 7 day intervals  
> starting from the first one and moving through the table. is this  
> possible in a single query or would I have to write a function ?

Either use something like date_trunc[1], convert it to a string with
to_char[2], or create a table that contains what you consider to be your
week ranges in (i.e. year, week, startdate, enddate).

-- 
  Sam  http://samason.me.uk/

 [1] 
http://www.postgresql.org/docs/current/static/functions-datetime.html#FUNCTIONS-DATETIME-TRUNC
 [2] http://www.postgresql.org/docs/current/static/functions-formatting.html

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] export csv file on XP

[Thomas Kellerer]

Raymond O'Donnell wrote on 31.07.2009 18:12:

On 31/07/2009 16:57, Wang Kuo-Ying wrote:


Command:
copy test to 'c:/test.csv'
delimiters ',' ;

but the error ERROR:  could not open file "c:/test.csv" for writing:
Permission denied


Looks like a permissions problem - check that the user as which the
server is running has read permissions on that file.


I think *write* permission is the approriate ;)

Thomas


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] export csv file on XP

[Raymond O'Donnell]

On 31/07/2009 17:23, Thomas Kellerer wrote:
>> Looks like a permissions problem - check that the user as which the
>> server is running has read permissions on that file.
> 
> I think *write* permission is the approriate ;)

Whoops - my mistake - you're absolutely write! :-P

Ray.


--
Raymond O'Donnell, Director of Music, Galway Cathedral, Ireland
r...@iol.ie
Galway Cathedral Recitals: http://www.galwaycathedral.org/recitals
--

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] size of data stored in gist index

[Gerhard Heift]

Hello,

I try to index histograms in my table. For this I uses the cube contrib
module in which I removed the dimension check. If the cube has more than
255 dimensions, for example 256 ^= 4 + 4 + 256 * 2 * 8 = 4104 bytes, this
data can not be stored in the gist index any more. If I try it, I get the
following error:

PANIC:  failed to add item to index page in "histogram_idx"

Do I have to compress the data in any way or is it possible, to store index
data with this huge size?

Thanks,
  Gerhard


signature.asc
Description: Digital signature

Re: [GENERAL] Grouping Question

[Gerhard Heift]

On Fri, Jul 31, 2009 at 12:09:51PM -0400, Ketema Harris wrote:
> I have a table defined as
> 
> CREATE TABLE mytable
> (
>   carrier varchar,
>   start_time timestamp with time zone,
>   call_date date,
>   cost numeric,
>   call_length numeric
> )
> 
> I want to create a query that will generate a the following columns:
 
select carrier,
extract(YEAR FROM start_time) || '-' || EXTRACT(WEEK FROM start_time),
sum(call_length) as totallength, sum(cost) as total_cost
from mytable
group by carrier,
extract(YEAR FROM start_time) || '-' || EXTRACT(WEEK FROM start_time),
order by carrier,
extract(YEAR FROM start_time) || '-' || EXTRACT(WEEK FROM start_time),
> 
> week is defined as a date range so something like 7/6/2009 - 7/13/2009
> 
> I would need the timestamps to be grouped into 7 day intervals
> starting from the first one and moving through the table. is this
> possible in a single query or would I have to write a function ?

Regards,
  Gerhard


signature.asc
Description: Digital signature

Re: [GENERAL] Grouping Question

[Rob Wickert]

You would use some of postgresql built in date functions to extract the week from the date and group 
by that


i.e.

select carrier, extract(week from start_time) as week, sum(call_length) as totallength, sum(cost) as 
total_cost

from mytable
group by carrier, extract(week from start_time)
order by week, carrier

you'll probably want to extract the year as well so dates weeks from alternate years don't get 
merged together


Ketema Harris wrote:

I have a table defined as

CREATE TABLE mytable
(
  carrier varchar,
  start_time timestamp with time zone,
  call_date date,
  cost numeric,
  call_length numeric
)

I want to create a query that will generate a the following columns:

carrier, week, sum(call_length) as totallength, sum(cost) as total_cost
from mytable
group by carrier, (WHAT HERE?)
order by week, carrier


week is defined as a date range so something like 7/6/2009 - 7/13/2009

I would need the timestamps to be grouped into 7 day intervals starting 
from the first one and moving through the table. is this possible in a 
single query or would I have to write a function ?





--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Grouping Question

[Ketema Harris]

OK that worked, but now how do I get the integer returned by extract  
into a human friendly string like

7/1 - 7/8 or something similar ?

On Jul 31, 2009, at 12:37 PM, Rob Wickert wrote:

You would use some of postgresql built in date functions to extract  
the week from the date and group by that


i.e.

select carrier, extract(week from start_time) as week,  
sum(call_length) as totallength, sum(cost) as total_cost

from mytable
group by carrier, extract(week from start_time)
order by week, carrier

you'll probably want to extract the year as well so dates weeks from  
alternate years don't get merged together


Ketema Harris wrote:

I have a table defined as
CREATE TABLE mytable
(
 carrier varchar,
 start_time timestamp with time zone,
 call_date date,
 cost numeric,
 call_length numeric
)
I want to create a query that will generate a the following columns:
carrier, week, sum(call_length) as totallength, sum(cost) as  
total_cost

from mytable
group by carrier, (WHAT HERE?)
order by week, carrier
week is defined as a date range so something like 7/6/2009 -  
7/13/2009
I would need the timestamps to be grouped into 7 day intervals  
starting from the first one and moving through the table. is this  
possible in a single query or would I have to write a function ?



--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] size of data stored in gist index

[Tom Lane]

Gerhard Heift  writes:
> I try to index histograms in my table. For this I uses the cube contrib
> module in which I removed the dimension check. If the cube has more than
> 255 dimensions, for example 256 ^= 4 + 4 + 256 * 2 * 8 = 4104 bytes, this
> data can not be stored in the gist index any more. If I try it, I get the
> following error:

> PANIC:  failed to add item to index page in "histogram_idx"

> Do I have to compress the data in any way or is it possible, to store index
> data with this huge size?

Well, if you're going to turn cube into an unlimited-size datatype,
it would behoove you to make its compress and decompress routines
do something.

Still, it seems like gist ought to defend itself a bit better against
ill-considered datatypes.  Maybe put a check in gistFormTuple to verify
that the tuple isn't larger than can fit on one page?  Or is there a
better place to check it?

regards, tom lane

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] PG equivalent of "mysqlhotcopy"?

[Dimitri Fontaine]

Hi,

Le 30 juil. 09 à 15:34, Phoenix Kiula a écrit :

I know about pg_dumpall, which creates a humongous SQL file, but is
there something equivalent in the postgresql world, like a
"pgsqlhotcopy" which copies data folders in a similar way as
mysqlhotcopy?



Copying the raw data files of a live database only works under certain  
conditions with PostgreSQL, in short you have to tell it about what  
you're going to do for it to cooperate. That's pg_start_backup()  
function and friends.


Now, the generic technique provided by PostgreSQL is called PITR,  
Point In Time Recovery. You'll find ready to go software to drive  
this, in order of personal preference :


 - walmgr from Skytools
http://wiki.postgresql.org/wiki/Skytools#walmgr
http://skytools.projects.postgresql.org/doc/walmgr.html
https://developer.skype.com/SkypeGarage/DbProjects/SkyTools/WalMgr

 - pitrtools
http://projects.commandprompt.com/public/pitrtools/

 - pg_standby (read carefully the 8.3 era behavior of this one)
it's in the contribs

Those 3 solutions are packaged in debian and maybe some other  
distributions or OS.


Regards,
--
dim
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Limiting records in pg_dump

[Arnold, Sandra]

Is there a way to just dump records equal to a specific value using pg_dump?  
In Oracle, you can export data and use a WHERE clause and only pull a range of 
data.  We currently use this in Oracle to load data sets in our Development 
database.  As we move to PostgreSQL we will be wanting to do the same thing.  
If we cannot do it using the pg_dump command, I will need to find a work around.

Thanks,

Sandra

Re: [GENERAL] Limiting records in pg_dump

[Raymond O'Donnell]

On 31/07/2009 18:27, Arnold, Sandra wrote:
> Is there a way to just dump records equal to a specific value using
> pg_dump?  In Oracle, you can export data and use a WHERE clause and only
> pull a range of data.  We currently use this in Oracle to load data sets
> in our Development database.  As we move to PostgreSQL we will be
> wanting to do the same thing.  If we cannot do it using the pg_dump
> command, I will need to find a work around.

Not with pg_dump - it's all-or nothing. However, you could use the COPY
command:

  http://www.postgresql.org/docs/8.3/static/sql-copy.html

Ray.

--
Raymond O'Donnell, Director of Music, Galway Cathedral, Ireland
r...@iol.ie
Galway Cathedral Recitals: http://www.galwaycathedral.org/recitals
--

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Division by zero

[Oliver Kohll - Mailing Lists]

Hello,

Divide by zero errors have come up a couple of times on this list  
(once raised by me). I wonder if I could propose a feature for  
discussion. Could the result of a division by zero be treated as  
infinity or null, rather than raising an error? Floating point types  
already have the concept of infinity.


I'd have thought that there's no reason why a /0 in one row  
necessarily has to be fatal for the whole view. In many cases, you can  
imagine that returning infinity makes more sense. Strictly, I suppose,  
1/0 should return infinity, 0/0 null and -1/0 negative infinity.  
Alternatively, all could return NaN. At least there could be a  
configuration option to turn on this behaviour.


The concern stems from the fact that when a divide by zero occurs in a  
view, no rows at all are returned, just the error message. This makes  
it very difficult to work out where the problem value is, compared to  
other tools like spreadsheets, which return a cell error. A view can  
be very fragile. Further, the Postgres error doesn't give any details  
of the field and of course can't point to the row, it just says

ERROR:  division by zero

There may well be good reasons for not treating this. I've come across  
comments such as 'I think everybody would agree that this would be a  
bad thing to do!' but remain to be convinced.


I know you can use CASE and NULLIF but if you have complex  
calculations, that makes them a lot less readable.


Regards
Oliver Kohll

oli...@gtwm.co.uk / 0845 456 1810 / 07814 828608
www.gtwm.co.uk - company
www.gtportalbase.com - product

Re: [GENERAL] Limiting records in pg_dump

[John R Pierce]

Arnold, Sandra wrote:
Is there a way to just dump records equal to a specific value using 
pg_dump?  In Oracle, you can export data and use a WHERE clause and 
only pull a range of data.  We currently use this in Oracle to load 
data sets in our Development database.  As we move to PostgreSQL we 
will be wanting to do the same thing.  If we cannot do it using the 
pg_dump command, I will need to find a work around.


you could create an alternate schema in your DB with VIEW's to your 
database table(s) that filter it according to your requirements, then 
pg_dump -n schemaname 




--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Limiting records in pg_dump

[Arnold, Sandra]

Thanks for that suggestion.   Since I have a schema on the database, I could 
create the view on my schema or even a table with the same name with just the 
records that I want to copy to the other database.   I had thought about the 
table but not necessary the view.  

We are just in the process of looking at PostgreSQL as a solution to replace 
Oracle.  Those high Maintenance and Support cost have made it necessary to find 
a replacement for Oracle.
 

-Original Message-
From: John R Pierce [mailto:pie...@hogranch.com] 
Sent: Friday, July 31, 2009 1:59 PM
To: Arnold, Sandra; pgsql-general@postgresql.org
Subject: Re: [GENERAL] Limiting records in pg_dump

Arnold, Sandra wrote:
> Is there a way to just dump records equal to a specific value using 
> pg_dump?  In Oracle, you can export data and use a WHERE clause and 
> only pull a range of data.  We currently use this in Oracle to load 
> data sets in our Development database.  As we move to PostgreSQL we 
> will be wanting to do the same thing.  If we cannot do it using the 
> pg_dump command, I will need to find a work around.

you could create an alternate schema in your DB with VIEW's to your 
database table(s) that filter it according to your requirements, then 
pg_dump -n schemaname 



-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] change ownership on all tables

[Alan McKay]

OK, my DB Admin is on vacation, and 15 minutes of googling didn't get
me the answer :-)

Although in that 15 minutes I could have done all 109 tables manually :-)

I know this command for a single table, and checked the manual but
don't see anything about wildcards

ALTER TABLE tablename OWNER to user;

PG 8.4

-- 
“Don't eat anything you've ever seen advertised on TV”
 - Michael Pollan, author of "In Defense of Food"

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Can I have a look at your TuningWizard generated config file?

[Greg Smith]

On Fri, 31 Jul 2009, Jennifer Trey wrote:

So this is a special request, if you could provide a screen shot with 
perhaps three images, then I could go through it myself one by one and 
do similar things on mine.


As a general note here, the Enterprise DB TuningWizard program is 
technically open-source, but the actual tuning it does runs as a private 
web service.  They apparently want to keep its implementation details to 
themselves and are just providing this as a helpful service to people.


As such, I know I really don't want to see any such output show up on one 
of these mailing lists.  The PostgreSQL community at large should avoid 
learning what they're doing just so it's clear that any open development 
work here isn't taking their ideas.  I hope no one actually shows the 
output from the program downthread, once I read this message I deleted 
everything else in it so at least I stay clean.


The TuningWizard software redirects you over to 
http://forums.enterprisedb.com for support with it and that's really the 
right place to ask questions about that specific program.


--
* Greg Smith gsm...@gregsmith.com http://www.gregsmith.com Baltimore, MD

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Design Database, 3 degrees of Users.

[Steve Crawford]

Andre Lopes wrote:

I need to design a Database that will handle 3 degrees of users:
 


Administrators - They can see all the information in the database.

Managers - They only can see the information of his dependants.

Dependants - Theirs action must be aprovet by the managers.


A little more description of your application would be helpful.

Are these users of the database directly or are they users who login to 
something like a web-app to retrieve information?


In research, we sometimes deal with organizational trees. For example we 
might have employee-satisfaction that must be made available to 
thousands of managers, each of which is allowed to see the aggregate 
data of her department and of any department below her but nothing above 
her. If your situation is similar, you might look into using an 
adjacency-tree (every record except the top has a "manager-id" pointing 
to that person's boss) along with the new "with recursive" queries in 8.4.


Cheers,
Steve


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Division by zero

[Jeff Davis]

On Fri, 2009-07-31 at 18:27 +0100, Oliver Kohll - Mailing Lists wrote:
> Divide by zero errors have come up a couple of times on this list
> (once raised by me). I wonder if I could propose a feature for
> discussion. Could the result of a division by zero be treated as
> infinity or null, rather than raising an error? Floating point types
> already have the concept of infinity.

The SQL spec seems to require that an exception be raised in 6.26
General Rules 4.

(Disclaimer: I'm not an expert on the SQL standard. This was based on a
quick text search of the document).

> I'd have thought that there's no reason why a /0 in one row
> necessarily has to be fatal for the whole view. In many cases, you can
> imagine that returning infinity makes more sense. Strictly, I suppose,
> 1/0 should return infinity, 0/0 null and -1/0 negative infinity.
> Alternatively, all could return NaN. At least there could be a
> configuration option to turn on this behaviour.

For every situation in which coming up with some kind of result "makes
sense", there is another situation in which the result would be wrong or
hides some subtle logical flaw in the query. For instance:

"Find all store locations which have not achieved an average sale price
of $100."

  SELECT store_name FROM sales WHERE totalsales/nsales < 100;

The person running that query might be missing stores with no sales at
all, and they might prefer an ERROR to the silent omission of results.

> The concern stems from the fact that when a divide by zero occurs in a
> view, no rows at all are returned, just the error message. This makes
> it very difficult to work out where the problem value is, compared to
> other tools like spreadsheets, which return a cell error. A view can
> be very fragile. Further, the Postgres error doesn't give any details
> of the field and of course can't point to the row, it just says 
> ERROR:  division by zero

I agree that it may be useful to show you the values that are causing
the expression to be throwing an error. However, we shouldn't say that
it's a problem with the field itself -- it may be a problem with the
query.

> I know you can use CASE and NULLIF but if you have complex
> calculations, that makes them a lot less readable.

Yes -- you can do what you want anyway. If you want it to be more
readable, you can redefine the division operator yourself -- it's just a
function and operator that happens to be named "/" (although that might
not be wise). Maybe you can call it "//" to avoid confusion with people
used to the SQL standard behavior.

Regards,
Jeff Davis


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] change ownership on all tables

[John R Pierce]

Alan McKay wrote:

OK, my DB Admin is on vacation, and 15 minutes of googling didn't get
me the answer :-)

Although in that 15 minutes I could have done all 109 tables manually :-)

I know this command for a single table, and checked the manual but
don't see anything about wildcards

ALTER TABLE tablename OWNER to user;
  


see http://pgedit.com/public/sql/acl_admin/index.html
or http://www.archonet.com/pgdocs/grant-all.html

these are scripts for doing a GRANT to all objects, but they should 
easily be modifiable to do a ALTER TABLE... OWNER




--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Design Database, 3 degrees of Users.

[Merlin Moncure]

On Fri, Jul 31, 2009 at 9:47 AM, Rich Shepard wrote:
> On Fri, Jul 31, 2009 at 4:38 AM, Andre Lopes wrote:
>
>> I need to design a Database that will handle 3 degrees of users:
>>
>> Administrators - They can see all the information in the database.
>> Managers - They only can see the information of his dependants.
>> Dependants - Theirs action must be aprovet by the managers.
>>
>> Wich the best way to implement this in PostGreSQL? There is some database
>> examples doing this? Some OpenSource Project?
>>
>> I'am designing a Database for doing this, but I don't have sure I'am doing
>> well.
>>
>> Please give me some advice.
>
>  You don't want to implement this in SQL, regardless of what DBMS you use
> as the back end. Implementing different user classes (or roles as we call
> them) is done in your middleware and UI.
>

That's a fairly broad statement which I don't necessarily agree with
depending on how you define 'in SQL'.  It's quite easy and common to
describe user roles and allowed activities within the database to
support an application, and to check user actions against those tables
at various places.  This is 'in SQL' to me, because the logic
controlling what the users can and cannot do is handled inside the
database (either in tables + actual sql or a supporting language
hooked in to the database).

Strictly using SQL roles for security. however, can be clumsy if you
need fine grained control beyond reading or writing to a particular
set of tables.  This is more of a data security thing, which is quite
different from controlling how a particular application is supposed to
behave.

merlin

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Limiting records in pg_dump

[Adrian Klaver]

- "Sandra Arnold"  wrote:

> Thanks for that suggestion.   Since I have a schema on the database, I
> could create the view on my schema or even a table with the same name
> with just the records that I want to copy to the other database.   I
> had thought about the table but not necessary the view.  
> 
> We are just in the process of looking at PostgreSQL as a solution to
> replace Oracle.  Those high Maintenance and Support cost have made it
> necessary to find a replacement for Oracle.
>  
>

How about the COPY command:
http://www.postgresql.org/docs/8.4/interactive/sql-copy.html

Be sure and read to the bottom where it explains that this is a server command 
and needs to be run on the server and as the Postgres user. 

An alternative is \copy run from psql, documentation here:
http://www.postgresql.org/docs/8.4/interactive/app-psql.html

It runs locally and as the local user.

Adrian Klaver
akla...@comcast.net


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Can I have a look at your TuningWizard generated config file?

[Selena Deckelmann]

Hi Greg!

On Fri, Jul 31, 2009 at 11:43 AM, Greg Smith wrote:

> As such, I know I really don't want to see any such output show up on one of
> these mailing lists.  The PostgreSQL community at large should avoid
> learning what they're doing just so it's clear that any open development
> work here isn't taking their ideas.  I hope no one actually shows the output
> from the program downthread, once I read this message I deleted everything
> else in it so at least I stay clean.

What exactly is the concern? I'm for healthy paranoia, but I'd like to
know what exactly you're paranoid about.

I'd rather resolve whatever is bothering you by being direct and
talking to EDB (if whatever this is can be changed), than to have you
desperately deleting threads.

-selena

-- 
http://chesnok.com/daily - me
http://endpoint.com - work

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Make check fails on 8.3.7

[Christine Desmuke]

Tom Lane wrote:

Christine Desmuke  writes:

I'm trying to install 8.3.7, but can't get past make check.
CentOS release 4.7 (Final), with an existing install of 8.3.1 running as 
a warm standby

...
It looks in every case like the ERROR (and also HINT lines) lines are 
causing the failures, but I'm not sure what setting I messed up to cause 
that. What should I be looking for?


Years ago I saw roughly similar symptoms when SELinux decided postgres
shouldn't be allowed to write to /dev/tty.  I'm not sure how that would
relate to your situation, but it'd be worth checking for avc messages in
the kernel log ...

regards, tom lane


Thanks for the suggestion. It is not SELinux (SELinux status: disabled), 
but _something_ is preventing postgres (both the existing install and 
the one I'm trying to check) from writing to /dev/tty. There are no 
related messages in the kernel log or postgres log, however.


The permissions on /dev/tty appear to be ok:

[r...@zu log]# ls -l /dev/tty
crw-rw-rw-  1 root root 5, 0 Jul 31 12:23 /dev/tty

Trying to invoke psql ought to write an error (because the warm standby 
is perpetually in startup mode), but I'm just returned to the prompt:


[cdesm...@zu ~]# psql -h localhost
psql: [cdesm...@zu ~]#

Other programs can write to /dev/tty without problems:

[cdesm...@zu ~]# mysql
ERROR 1045 (28000): Access denied for user 'cdesmuke'@'localhost' (using 
password: NO)

[cdesm...@zu ~]$ pg_config
BINDIR = /usr/local/pgsql/bin
DOCDIR = /usr/local/pgsql/doc
INCLUDEDIR = /usr/local/pgsql/include
PKGINCLUDEDIR = /usr/local/pgsql/include
INCLUDEDIR-SERVER = /usr/local/pgsql/include/server
LIBDIR = /usr/local/pgsql/lib
PKGLIBDIR = /usr/local/pgsql/lib
LOCALEDIR =
MANDIR = /usr/local/pgsql/man
SHAREDIR = /usr/local/pgsql/share
SYSCONFDIR = /usr/local/pgsql/etc
PGXS = /usr/local/pgsql/lib/pgxs/src/makefiles/pgxs.mk
CONFIGURE =
CC = gcc
CPPFLAGS = -D_GNU_SOURCE
CFLAGS = -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline 
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv

CFLAGS_SL = -fpic
LDFLAGS = -Wl,-rpath,'/usr/local/pgsql/lib'
LDFLAGS_SL =
LIBS = -lpgport -lz -lreadline -ltermcap -lcrypt -ldl -lm
VERSION = PostgreSQL 8.3.1

The same thing happens whether trying as root, as postgres, or under my 
own unprivileged username.


Trying to connect to this instance from another machine does generate 
the expected error:

[cdesm...@alberta ~]$ psql -h zu
psql: FATAL:  the database system is starting up

Some other PG programs seems to work partway, but not fully:
[cdesm...@zu ~]$ pg_dump -U gar
pg_dump: [archiver (db)] connection to database "gar" failed: 
[cdesm...@zu ~]$


[i.e., the message "fe_sendauth: no password supplied" that I expected 
to see did not appear, and the command prompt appeared immediately after 
the "failed:" rather than on a new line.]


I'm out of ideas on what to check next. Thank you for any and all 
suggestions.


--

Christine Desmuke
Kansas State Historical Society
cdesm...@kshs.org

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] building a binary-portable database

[Alexy Khrabrov]

I've filled a database on Linux and tried to bring it across to Mac OSX, and
got an error: FATAL:  incorrect checksum in control file.
Exploring with pg_controldata shows differences such as:

Linux:
pg_control version number:833
Catalog version number:   200711281
Database system identifier:   5338438316294798685
Database cluster state:   in production
pg_control last modified: Fri 24 Jul 2009 06:37:28 PM EDT
Latest checkpoint location:   4B/5E4B2EC8
Prior checkpoint location:4B/5E011FD8
Latest checkpoint's REDO location:4B/5E4B2EC8
Latest checkpoint's TimeLineID:   1
Latest checkpoint's NextXID:  0/47680877
Latest checkpoint's NextOID:  24576
Latest checkpoint's NextMultiXactId:  1
Latest checkpoint's NextMultiOffset:  0
Time of latest checkpoint:Fri 24 Jul 2009 06:34:58 PM EDT
Minimum recovery ending location: 0/0
Maximum data alignment:   8
Database block size:  8192
Blocks per segment of large relation: 131072
WAL block size:   8192
Bytes per WAL segment:16777216
Maximum length of identifiers:64
Maximum columns in an index:  32
Maximum size of a TOAST chunk:1996
Date/time type storage:   floating-point numbers
Maximum length of locale name:128
LC_COLLATE:   en_US.UTF-8
LC_CTYPE: en_US.UTF-8

Mac:
WARNING: Calculated CRC checksum does not match value stored in file.
Either the file is corrupt, or it has a different layout than this program
is expecting.  The results below are untrustworthy.

pg_control version number:833
Catalog version number:   200711281
Database system identifier:   5338438316294798685
Database cluster state:   in production
pg_control last modified: Wed Dec 31 19:00:00 1969
Latest checkpoint location:   4A6A35E8/0
Prior checkpoint location:4B/5E011FD8
Latest checkpoint's REDO location:4B/5B2B3F28
Latest checkpoint's TimeLineID:   75
Latest checkpoint's NextXID:  1560372384/1
Latest checkpoint's NextOID:  0
Latest checkpoint's NextMultiXactId:  47680877
Latest checkpoint's NextMultiOffset:  24576
Time of latest checkpoint:Wed Dec 31 19:00:01 1969
Minimum recovery ending location: 0/4A6A35E6
Maximum data alignment:   0
Database block size:  8
Blocks per segment of large relation: 0
WAL block size:   0
Bytes per WAL segment:1093850759
Maximum length of identifiers:8192
Maximum columns in an index:  131072
Maximum size of a TOAST chunk:8192
Date/time type storage:   64-bit integers
Maximum length of locale name:64
LC_COLLATE:
LC_CTYPE:

-- apparently, Linux uses floating-point timestamps, while Mac uses 64-bit
integers.

Is there a set of options for the build which will ensure I'll be able to
rsync the databases between 64-bit Linux and 64-bit Mac, both Intel ones?

Cheers,
Alexy

Re: [GENERAL] Division by zero

[Josh Kupershmidt]

On Fri, 31 Jul 2009 11:49:47 -0700 Jeff Davis wrote:
> "Find all store locations which have not achieved an average sale price
> of $100."
>
>  SELECT store_name FROM sales WHERE totalsales/nsales < 100;
>
> The person running that query might be missing stores with no sales at
> all, and they might prefer an ERROR to the silent omission of results.


Not that I'm suggesting that Postgres mimic MySQL's behavior in this
case, but just for fun I tried the following SQL in both PG 8.3 and MySQL 5.0:

-
CREATE TEMPORARY TABLE sales(
store_name varchar( 128 ) ,
totalsales float NOT NULL DEFAULT 0.0,
nsales int NOT NULL DEFAULT 0) ;

INSERT INTO sales(store_name, totalsales, nsales)
VALUES ('store A', 1000.0, 100), ('store B', 0, 0), ('store C', 51.1, 2);

SELECT store_name FROM sales WHERE totalsales / nsales < 100 ;
-

MySQL gave results:
++
| store_name |
++
| store A|
| store C|
++

since divide-by-zero errors in MySQL produce NULL values, while Postgres gave:
"ERROR:  division by zero".

I am also no expert on the SQL Standard; there was a Stack Overflow discussion
relating to this topic which didn't produce any useful answers:
http://stackoverflow.com/questions/1140860/treatment-of-error-values-in-the-sql-standard

To the original poster, I'd suggest just using NULLIF(column, 0) on
your denominators to
achieve an effect similar to MySQL's behavior.
Cheers,
Josh

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] building a binary-portable database

[John R Pierce]

Alexy Khrabrov wrote:
I've filled a database on Linux and tried to bring it across to Mac 
OSX, and got an error: FATAL:  incorrect checksum in control file.


use pg_dumpall | psql  to export/import databases between machines.



--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] building a binary-portable database

[Alexy Khrabrov]

On Jul 31, 2009, at 6:30 PM, John R Pierce wrote:


Alexy Khrabrov wrote:
I've filled a database on Linux and tried to bring it across to Mac  
OSX, and got an error: FATAL:  incorrect checksum in control file.


use pg_dumpall | psql  to export/import databases between machines.


That's doable of course, but I wonder what would it take to get it to  
work as-is, when building pg from source on each box, giving their  
fairly similar characteristics.  Or, if time_t is different, would it  
be a show-stopper?


Cheers,
Alexy


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Make check fails on 8.3.7

[Tom Lane]

Christine Desmuke  writes:
> Tom Lane wrote:
>> Years ago I saw roughly similar symptoms when SELinux decided postgres
>> shouldn't be allowed to write to /dev/tty.

> Thanks for the suggestion. It is not SELinux (SELinux status: disabled), 
> but _something_ is preventing postgres (both the existing install and 
> the one I'm trying to check) from writing to /dev/tty.

You *sure* selinux is disabled?  Because that sounds exactly like a
long-ago selinux policy bug.  I'd have thought everybody's machine
had the fix by now, but if this machine isn't too up2date, maybe not...

regards, tom lane

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] building a binary-portable database

[Tom Lane]

Alexy Khrabrov  writes:
> That's doable of course, but I wonder what would it take to get it to  
> work as-is, when building pg from source on each box, giving their  
> fairly similar characteristics.

It's not promised to work, and if it breaks you get to keep both pieces.

> Or, if time_t is different, would it be a show-stopper?

The pg_controldata output suggests that indeed time_t size difference is
the immediate issue.  But there might be other ones lurking behind that.

(FWIW, 8.4 has removed this particular potential platform difference:
http://archives.postgresql.org/pgsql-committers/2008-02/msg00184.php
But I still wouldn't trust copying DB files between significantly
different OSes.)

regards, tom lane

-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Design Database, 3 degrees of Users.

[Marc Munro]

On Fri, 2009-07-31 at 08:38 -0300, pgsql-general-ow...@postgresql.org
wrote:
> Date: Fri, 31 Jul 2009 12:38:30 +0100
> From: Andre Lopes 
> To: pgsql-general@postgresql.org
> Subject: Design Database, 3 degrees of Users.
> Message-ID:
> <18f98e680907310438o764e9bc7hbb6e245d8464...@mail.gmail.com>
> 
> I need to design a Database that will handle 3 degrees of users:
> 
> 
> Administrators - They can see all the information in the database.
> 
> Managers - They only can see the information of his dependants.
> 
> Dependants - Theirs action must be aprovet by the managers.
> 
> 
> Wich the best way to implement this in PostGreSQL? There is some
> database
> examples doing this? Some OpenSource Project?

If I understand your requirement, I think you are hoping to implement
Virtual Private Databases for each of your users.  With a VPD each user
connects to the same database but can see different subsets of data.

You can do this with veil:
http://veil.projects.postgresql.org/curdocs/index.html

Note that this is a hard problem and good solutions, even using veil,
require a lot of work.  My advice to anyone thinking that they want to
do this is, consider very carefully whether the benefits of a VPD are
worth the cost.  It is generally much easier to place the sort of
controls you need in your application than in the database.

__
Marc Munro (developer of veil)



-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Can I have a look at your TuningWizard generated config file?

[Greg Smith]

On Fri, 31 Jul 2009, Selena Deckelmann wrote:


What exactly is the concern? I'm for healthy paranoia, but I'd like to
know what exactly you're paranoid about.


EDB has this program that runs as a web service.  It runs a proprietary 
tuning routine (what they call "DynaTune") and gives the results out to 
people, which is a nice service they're providing.  No problem with that 
and I'm glad they help out by providing it.


But I don't want to see those results showing up here, for fear that 
community efforts to provide a similar service would be comprimised by 
seeing it.  You'll see people here warning against discussing the design 
of proprietary bits of Oe's implementation lest it similarly taint the 
PostgreSQL design.  I'm just pointing out that the output of EDB's Tuning 
Wizard could be a similarly protected bit of intellectual property.


I already asked EDB last year whether they were intending to release the 
DynaTune program and didn't get the impression that was forthcoming, and 
it's unreasonable to ask them to, so I don't know what further questions 
you might ask them.


--
* Greg Smith gsm...@gregsmith.com http://www.gregsmith.com Baltimore, MD

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Drop Cluster

[sweta]

Hi,

Is there any command to drop a postgres cluster???

I tried the following link
http://www.digipedia.pl/man/pg_dropcluster.8.html

but it says command not found.
Is there any other way??

Any help will be highly appreciated.

Thanks in advance.

Regards,
Sweta.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Drop Cluster

[sweta]

Hi,

Is there any command to drop a postgres cluster???

I tried the following link
http://www.digipedia.pl/man/pg_dropcluster.8.html

but it says command not found.
Is there any other way??

Any help will be highly appreciated.

Thanks in advance.

Regards,
Sweta.



-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general