Tuesday, July 1, 2008

[HACKERS] Please claim review items for commit fest!

Hackers,

Just in case anyone was unclear, this is how we're trying things for
this commitfest:

1) Starting RIGHT NOW, reviewers should claim review items they are
interested in or specially qualified to review.

2) This weekend, I will check for all items which don't have one or
more reviewers and parcel them out to the Round Robin Reviewers who
don't already have patches to review.

You do not have to be a committer to be a reviewer. Anyone who knows C
code and is familiar with Postgres

Josh Berkus
PostgreSQL @ Sun
San Francisco 415-752-2500

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

Re: [HACKERS] TODO assignment

Jiri,

I don't know of anyone currently working on the "apply permissions to
all objects" TODO. You're welcome to take a stab at it.

--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco 415-752-2500

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

Re: [GENERAL] Memory use in 8.3 plpgsql with heavy use of xpath()

> Ugh. Sounds like "small memory leak inside libxml2" --- probably not
> going to be easy to find. Can you put together a self-contained test
> case?

OK, I'll try to come up with something. Do you have a recommended way of
capturing the amount memory being used by Postgres related to this? I was
thinking I would have a plpgsql function that loops a large number of
times, calling a few xpath() calls, and could take a memory snapshot
before/after the function completes. Is there a call within Postgres I can
make, or should I just rely on OS-level tools for this?

-- m@

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

Re: [SQL] column default dependant on another columns value

> -----Mensaje original-----
> De: Richard Broersma [mailto:richard.broersma@gmail.com]
>
> It is possible to do this with a trigger or a rule. A
> trigger would be more robust.
>
> > Is this correct? Is there another (better/simpler) way to
> achieve this?
>
> Well I might work, but it is a bad practice to get into since
> what you are trying to do violates the rules of database
> normalization.
>
> Wouldn't it be better to calculate the minutes with you query
> your table?
>
> SELECT *, seconds / 60 AS minutes
> FROM yourtable;

Actually I only used this as an example.
The real table is queried lots of times for millions of rows and the server
is showing some high-level user cpu consumption. There are a couple
calculated columns on the table so I am trying to reduce cpu usage by
pre-calculating the more cpu intensive data once on insert. Enhancing the
application is currently not possible.

Anyway, the rule didn't work. Got "an infinite recursion error" when
inserting on the table.
Can't figure out where the recursion is as supposedly the rule kicks in when
the "where minutes is null" condition is satisfied. The DO INSTEAD part runs
an insert were minutes is NOT null so the rule should be ignored.
Where is the recursion then? I am on postgres 8.2.9.

Thanks for your hindsight Richard. I Will look into the trigger solution.
Still, I'd like to understand this recursion error.

Regards,
Fernando.

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

Re: [PATCHES] LOCK_DEBUG documentation

Greg Sabino Mullane wrote:
[ There is text before PGP section. ]
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
>
> Tom Lane replied:
> >> Documentation patch by Kevin L. McBride explaining LOCK_DEBUG options
> >> in detail.
>
> > Should this stuff really go into the SGML documentation, when these
> > options will certainly never be enabled anywhere except in developers'
> > private builds? A few lines of comments in pg_config_manual.h seems
> > a more appropriate solution.
>
> Call me a traditionalist, but I like all the documentation in one place,
> even if some of it it seldom used. For the record, these options have
> been enabled by myself and others in production systems for debugging
> purposes, and the lack of detail in that section while doing so led to
> the patch. The docs also has the advantage of being more available,
> searchable, and found via the web.

Agreed, applied.

--
Bruce Momjian <bruce@momjian.us>

http://momjian.us

EnterpriseDB

http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

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

[COMMITTERS] pgsql: Documentation patch by Kevin L.

Log Message:
-----------
Documentation patch by Kevin L. McBride explaining GUC lock variables,
which are available if LOCK_DEBUG is defined.

Modified Files:
--------------
pgsql/doc/src/sgml:
config.sgml (r1.181 -> r1.182)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/config.sgml?r1=1.181&r2=1.182)

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

Re: [GENERAL] Problem with roles and permissions

That did it! Thanks, all.

(Out of curiosity, what's the reason for not making this the default? It seems to me that if you're making a role a child of another role, it's /because/ you want to inherit permissions. OTOH maybe defaulting to more security is smart enough to be worth the confusion...)

-cb.

> I think it's the other way around --- the login role needs the INHERIT property. Anyway, one or the other should do it.

regards, tom lane


No virus found in this incoming message.
Checked by AVG.
Version: 7.5.526 / Virus Database: 270.4.3/1528 - Release Date: 7/1/2008 7:26 AM

No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.526 / Virus Database: 270.4.3/1528 - Release Date: 7/1/2008 7:26 AM


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

Re: [HACKERS] Commitfest status?

On Tue, 01 Jul 2008 16:19:39 -0400
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Well, it's July 1, and time for another commit fest to begin.
> Do we have all the submitted patches queued up at
> http://wiki.postgresql.org/wiki/CommitFest:2008-07 ?

I think Bruce and I have added everything submitted to June 29. I've
been offline for 36 hours, though, so I'm scanning hackers and patches
now. Help welcomed -- I'm on dial-up and it's slow.

Time for people to start volunteering to review stuff! I'll start
round-robin after a few days. So put your names on the stuff you know
you can review now.

Josh Berkus
PostgreSQL @ Sun
San Francisco 415-752-2500

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

Re: [GENERAL] Memory use in 8.3 plpgsql with heavy use of xpath()

"Matt Magoffin" <postgresql.org@msqr.us> writes:
> Later, I added a large set of plpgsql trigger functions that operate on
> that new xml column data, using the xpath() function to extract bits of
> XML and populate them into normal tables. The server has been running in
> this fashion for many months now, and there is a noticeable difference in
> how Postgres is using memory now, in that over time it's non-shared memory
> use is climbing higher and higher. Right now I'm tracking this from data
> captured by Munin on the system. The memory creep is very slight, but over
> many months is easy to discern.

Ugh. Sounds like "small memory leak inside libxml2" --- probably not
going to be easy to find. Can you put together a self-contained test
case?

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: [ADMIN] Change a character in a text field

>>> Naomi Walker <nwalker@mhs.mphasis.com> wrote:
> Is there some way with a SQL state to interrogate a text field, and
> replace characters.
>
> For example, we would like all "|"'s to be changed to something else,
on
> a regular basis...

It sounds like you might want to look at the regexp_replace function:

http://www.postgresql.org/docs/8.3/interactive/functions-matching.html#FUNCTIONS-POSIX-REGEXP


Be sure to use a WHERE clause on your UPDATE with the ~ operator.

-Kevin

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

Re: [GENERAL] Problem with roles and permissions

Alvaro Herrera <alvherre@commandprompt.com> writes:
> Probably your group role needs to have the INHERIT property set.

I think it's the other way around --- the login role needs the INHERIT
property. Anyway, one or the other should do 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

[HACKERS] Should enum GUCs be listed as such in config.sgml?

Currently, config.sgml still describes the new "enum" GUC variables
as being of type "string" --- but pg_settings says they are "enum".
This is not very consistent, but I wonder whether changing the docs
would be more confusing or less so. I note that section 18.1 doesn't
mention the enum alternative either.

regards, tom lane

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

Re: [GENERAL] Problem with roles and permissions

Chandra Barnett wrote:

> What I've done so far is to set up a "group role" and explicitly
> granted it every possible type of permission on the database in
> question, and also on the individual relations in that database. Then
> I created a "login role" and made it part of the group role I created.
> I expected that to let me connect to the dbms using that login role
> and database, and that I'd then be able to select/insert/update/delete
> in the relations in that database. I can connect just fine to that
> database with that login role, as I expected, but I then can't execute
> any commands.

Probably your group role needs to have the INHERIT property set.
Alternatively, you could "SET ROLE group" after connecting.

> It seems there must be some other step that I didn't know to do. In
> MySQL, for example, after changing permissions, one needs to "flush
> privileges" to get everything to take effect. Is there something
> analogous to this in PostgreSQL?

Fortunately not.

--
Alvaro Herrera

http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

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

[COMMITTERS] pgsql: Remove GUC extra_desc strings that are redundant with the enum

Log Message:
-----------
Remove GUC extra_desc strings that are redundant with the enum value lists.

Modified Files:
--------------
pgsql/src/backend/utils/misc:
guc.c (r1.460 -> r1.461)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/misc/guc.c?r1=1.460&r2=1.461)

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

Re: [planet] Aggregating a new blog to www.planetpostgresql.org

Sorry for the late response.

Could you please add a category (blogger calls it something different
that I cannot recall right now) for PostgreSQL? I'd rather not add the
whole blog to Planet PostgreSQL.

Regards, Devrim

On Mon, 2008-06-02 at 22:03 -0700, Devrim GÜNDÜZ wrote:
> On Mon, 2 Jun 2008, Robert Hodges wrote:
>
> > Hi,
> >
> > Can you aggregate my blog to PlanetPostgreSQL? It's located at:
> >
> > http://scale-out-blog.blogspot.com/feeds/posts/default
> >
> > It has PostgreSQL/MySQL posts for the most part.
> >
> > Thanks!
> >
> > Robert
> > --
> > Robert Hodges, CTO, Continuent, Inc.
> > Email: robert.hodges@continuent.com
> > Mobile: +1-510-501-3728 Skype: hodgesrm
> >
> >
>
> --
> Devrim GÜNDÜZ
> RHCE, PostgreSQL Consultant @ Command Prompt, Inc.
>

http://www.CommandPrompt.com
> devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
>

http://www.gunduz.org
--
Devrim GÜNDÜZ
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr

http://www.gunduz.org

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

Re: [HACKERS] Commitfest status?

Joe Conway wrote:

> I haven't yet committed the dblink patch posted here:
>
> http://archives.postgresql.org/pgsql-patches/2008-06/msg00016.php
>
> Should I post it on the wiki before committing? Either way I'll commit
> in the next day or so.

It doesn't matter. Patches are only listed in the wiki so that we don't
forget about them, or if you want someone else to review them.

--
Alvaro Herrera

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

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

Re: [planet] Me And My Database

Hi,

Sorry for the delay -- You just landed Planet. Welcome aboard.

Regards, Devrim

On Mon, 2008-06-23 at 22:01 -0700, Devrim GÜNDÜZ wrote:
> On Tue, 24 Jun 2008, Leif B. Kristensen wrote:
>
> > Devrim,
> > I've got this blog called "Me And My Database :: Geek Genealogy" that's
> > about my hobby genealogy project, developed and running in a Linux /
> > Apache / PostgreSQL / PHP environment. There's a lot of PostgreSQL
> > stuff there. The address is <http://solumslekt.org/blog/> and the feed
> > is <feed:http://solumslekt.org/blog/?feed=rss2>.
> >
> > I'd be happy to be included in the Planet PostgreSQL.
> > --
> > Leif Biberg Kristensen | Registered Linux User #338009
> > Me And My Database: http://solumslekt.org/blog/
> > My Jazz Jukebox: http://www.last.fm/user/leifbk/
> >
>
> --
> Devrim GÜNDÜZ
> RHCE, PostgreSQL Consultant @ Command Prompt, Inc.
>

http://www.CommandPrompt.com
> devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
>

http://www.gunduz.org
--
Devrim GÜNDÜZ
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr

http://www.gunduz.org

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

Re: [planet] Can I have my feed shown on planetpostgresql.org?

Sorry for the delay -- you just landed Planet. Welcome aboard.

Regards, Devrim

On Tue, 2008-06-24 at 07:47 -0700, Devrim GÜNDÜZ wrote:
> On Tue, 24 Jun 2008, Kenny Gorman wrote:
>
> > Devrim,
> >
> > I just wanted to check back in and see if you are still considering linking
> > me. ;-). Please let me know you received this if you wound not mind.
> >
> > Thanks!
> > Kenny
> >
> > On Jun 5, 2008, at 5:24 PM, Kenny Gorman wrote:
> >
> >>
> >> Devrim,
> >>
> >> Sure, here you go, I think this works..
> >>
> >>
> >>
> >> -kg
> >>
> >> > On May 30, 2008, at 12:41 AM, Devrim GÜNDÜZ wrote:
> >> >
> >> > >
> >> > > Hi,
> >> > >
> >> > > Do you have a specific category for PostgreSQL, which includes all
> >> > > PostgreSQL related stuff? I'd like to pull that one instead of whole
> >> > > feed.
> >> > >
> >> > > Regards, Devrim
> >> > >
> >> > > On Wed, 28 May 2008, Kenny Gorman wrote:
> >> > >
> >> > > > I generally blog about PostgreSQL, Slony, Oracle, python, scalability
> >> > > > and other fun DB related stuff, I work at www.hi5.com where we do
> >> > > > some fun stuff with PostgreSQL.
> >> > > >
> >> > > > site:
> >> > > >
> >> > > > www.kennygorman.com
> >> > > >
> >> > > > feed:
> >> > > >
> >> > > > http://www.kennygorman.com/wordpress/?feed=atom
> >> > > >
> >> > >
> >> > > --
> >> > > Devrim GÜNDÜZ
> >> > > RHCE, PostgreSQL Consultant @ Command Prompt, Inc.
> >> > >

http://www.CommandPrompt.com
> >> > > devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
> >> > >

http://www.gunduz.org
> >> >
> >>
> >
> >
>
> --
> Devrim GÜNDÜZ
> RHCE, PostgreSQL Consultant @ Command Prompt, Inc.
>

http://www.CommandPrompt.com
> devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
>

http://www.gunduz.org
--
Devrim GÜNDÜZ
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr

http://www.gunduz.org

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

[ADMIN] Change a character in a text field

Is there some way with a SQL state to interrogate a text field, and
replace characters.

For example, we would like all "|"'s to be changed to something else, on
a regular basis...
We could unload the rows, change them, and load back, but was hoping
someone had
a slicker way to do it in place..

Thanks,
Naomi

--
------------------------------------------------------------------------
Naomi Walker Chief Information Officer
Eldorado Computing, Inc nwalker@eldocomp.com
---An EDS Company 602-604-3100
------------------------------------------------------------------------
The more I want to get something done, the less I call it work.
- Richard Bach
------------------------------------------------------------------------

-- CONFIDENTIALITY NOTICE --

Information transmitted by this e-mail is proprietary to MphasiS and/or its Customers and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this e-mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please notify us immediately at mailmaster@mphasis.com and delete this mail from your records.

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

Re: [HACKERS] Commitfest status?

Tom Lane wrote:
> Well, it's July 1, and time for another commit fest to begin.
> Do we have all the submitted patches queued up at
> http://wiki.postgresql.org/wiki/CommitFest:2008-07 ?
>

I haven't yet committed the dblink patch posted here:

http://archives.postgresql.org/pgsql-patches/2008-06/msg00016.php

Should I post it on the wiki before committing? Either way I'll commit
in the next day or so.

Joe

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

[GENERAL] Problem with roles and permissions

 
Hi --
 
I've recently started using PostgreSQL after working with MySQL for quite a while. I've been trying to set up roles so I can manage permissions per-user, but it's not working the way I expected and I'm wondering if anyone can steer me straight.
 
What I've done so far is to set up a "group role" and explicitly granted it every possible type of permission on the database in question, and also on the individual relations in that database. Then I created a "login role" and made it part of the group role I created. I expected that to let me connect to the dbms using that login role and database, and that I'd then be able to select/insert/update/delete in the relations in that database. I can connect just fine to that database with that login role, as I expected, but I then can't execute any commands. A sample error message from a failed INSERT is "ERROR:  permission denied for relation sessions". A look in pgAdmin, however, tells me that I've explicitly granted the group role all permissions on both the relation and the database it's in.
 
It seems there must be some other step that I didn't know to do. In MySQL, for example, after changing permissions, one needs to "flush privileges" to get everything to take effect. Is there something analogous to this in PostgreSQL? If so, can someone tell me how to do it via pgAdmin III?
 
For context, I'm using PostgreSQL 8.3 and pgAdmin III on Windows XP.
 
Thanks for your help!
--  Chandra Barnett <chandra.barnett@cognition.com> 310-641-7200 x207 Software Engineer, Cognition, Inc. <http://www.cognition.com> 
 

Re: [SQL] column default dependant on another columns value

On Tue, Jul 1, 2008 at 1:12 PM, Fernando Hevia <fhevia@ip-tel.com.ar> wrote:

> Given a table with columns seconds and minutes, how can I have minutes be
> computed automatically at the insert statement?

It is possible to do this with a trigger or a rule. A trigger would
be more robust.

> Is this correct? Is there another (better/simpler) way to achieve this?

Well I might work, but it is a bad practice to get into since what you
are trying to do violates the rules of database normalization.

Wouldn't it be better to calculate the minutes with you query your table?

SELECT *, seconds / 60 AS minutes
FROM yourtable;


--
Regards,
Richard Broersma Jr.

Visit the Los Angles PostgreSQL Users Group (LAPUG)
http://pugs.postgresql.org/lapug

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

[GENERAL] Memory use in 8.3 plpgsql with heavy use of xpath()

I've been using Postgres 8.3 in a production environment for some time
now, and have noticed a difference in long-term non-shared memory use by
Postgres since upgrading the system from 8.1. After initially making the
switch to 8.3 and making only one schema change (changed a text column to
xml) the server ran and used memory more or less the same as it had in
8.1.

Later, I added a large set of plpgsql trigger functions that operate on
that new xml column data, using the xpath() function to extract bits of
XML and populate them into normal tables. The server has been running in
this fashion for many months now, and there is a noticeable difference in
how Postgres is using memory now, in that over time it's non-shared memory
use is climbing higher and higher. Right now I'm tracking this from data
captured by Munin on the system. The memory creep is very slight, but over
many months is easy to discern.

I was wondering if anyone else out there is making heavy use of xpath()
and related functions in plpgsql functions, and if they've noticed a trend
like this? Is this normal for Postgres to accumulate non-shared memory
over time, up to some configured maximum?

A second question I have about is about plpgsql and memory use in general.
If I run some of these plpgsql functions using a lot of xpath() calls on
large sets of data, huge amounts of memory are consumed (gigabytes) and
the memory seems to accumulate until the transaction the functions are
running in completes. Do invocations of plpgsql functions retain memory
they used until the end of the transaction?

-- m@

--
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 crashing

"Roberts, Jon" <Jon.Roberts@asurion.com> writes:
> Version: "PostgreSQL 8.3.0, compiled by Visual C++ build 1400"

Well, there are plenty of known bugs in 8.3.0 by now. You really
should update before complaining, not after.

> Problem: My database keeps on crashing every few days with this type of
> error message:

> 2008-07-01 10:46:30 CDT LOG: all server processes terminated;
> reinitializing

I think your real problem is with what happened *before* that.
But:

> 2008-07-01 10:46:31 CDT FATAL: pre-existing shared memory block is
> still in use
> 2008-07-01 10:46:31 CDT HINT: Check if there are any old server
> processes still running, and terminate them.

Hmm ... the code in win32_shmem.c that generates this message seems
mighty bogus to me --- it's just hoping that one-second delay is
enough. Another problem is that postmaster children that do
PGSharedMemoryDetach will still have valid inherited handles for
the shmem segment --- does that factor into the behavior? It looks
to me like the CloseHandle ought to be in PGSharedMemoryDetach.

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

[GENERAL] pg crashing

Platform: Windows 2003 Server 32 bit
Windows SharedSection set to 1024,3072 based on recommendations from
http://www.postgresql.org/docs/faqs.FAQ_windows.html#4.4 and
http://support.microsoft.com/kb/184802
Version: "PostgreSQL 8.3.0, compiled by Visual C++ build 1400"
Autovacuum: on
Virus Scanning: disabled on PostgreSQL home directory
Problem: My database keeps on crashing every few days with this type of
error message:

2008-07-01 10:46:30 CDT LOG: all server processes terminated;
reinitializing
2008-07-01 10:46:31 CDT FATAL: pre-existing shared memory block is
still in use
2008-07-01 10:46:31 CDT HINT: Check if there are any old server
processes still running, and terminate them.


Is this problem fixed in 8.3.3 and/or fixed by moving to a Unix
environment like Solaris?


Jon

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

[HACKERS] Commitfest status?

Well, it's July 1, and time for another commit fest to begin.
Do we have all the submitted patches queued up at
http://wiki.postgresql.org/wiki/CommitFest:2008-07 ?

regards, tom lane

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

Re: [BUGS] problema con pg_dum

On Tue, 01 Jul 2008 19:44:28 +0200, Avilio Alarcón
<aalarcon@grupoaventura.com.py> wrote:
> pg_dump: not found
I have no idea what you just said, but I think I understand the problem.
Cron's PATH is reset to quite simple value in each cron script, so,
instead of:
> pg_dump -Ft -b radius > $(date +%Y%m%d)_aloradius_radius.tar
use
> /usr/bin/pg_dump -Ft -b radius > $(date +%Y%m%d)_aloradius_radius.tar
(or wherever your pg_dump is)
I'd also suggest using /bin/gzip instead of just gzip.

Regards,
--
ru

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

[SQL] column default dependant on another columns value

Hi list,

Given a table with columns seconds and minutes, how can I have minutes be
computed automatically at the insert statement?

I tried:

ALTER TABLE table1 ALTER COLUMN minutes SET default (seconds/60);

Postgres' answer was:
ERROR: cannot use column references in default expression

So I gave rules a look but it seems rules apply to the entire row.

CREATE RULE "my_rule" AS ON
INSERT TO table1
WHERE minutes is null
DO INSTEAD
INSERT INTO table1 (column1, column2, seconds, minutes)
VALUES(new.column1, new.column2, new.seconds, new.seconds/60);

Is this correct? Is there another (better/simpler) way to achieve this?

Regards,
Fernando


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

Re: [HACKERS] Location for pgstat.stat

Magnus Hagander <magnus@hagander.net> writes:
> Alvaro Herrera wrote:
>> Well, it doesn't :-) No database or table will be processed until stat
>> entries are created, and then I think it will first wait until enough
>> activity gathers to take any actions at all.

> That's not actualliy not affected, but it does seem like it wouldn't be
> a very big issue. If one table was just about to be vacuumed or
> analyzed, this would just push it up to twice the threshold, right?

Except you could lather, rinse, repeat indefinitely.

The stats system started out with the idea that the stats were
disposable, but I don't really think that's an acceptable behavior
today. We don't even have stats_reset_on_server_start anymore.

It doesn't seem to me that it'd be hard to support two locations for the
stats file --- it'd just take another parameter to the read and write
routines. pgstat.c already knows the difference between a normal write
and a shutdown write ...

regards, tom lane

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

Re: [GENERAL] Version 8.2.6 - ecpg: current_timestamp - how to control timezone

paul tilles <Paul.Tilles@noaa.gov> writes:
> How do we set the time zone for current_timestamp to be UTC?

http://www.postgresql.org/docs/8.2/static/datatype-datetime.html#DATATYPE-TIMEZONES

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: [ADMIN] After upgrade cleanup

On Fri, Jun 20, 2008 at 3:19 PM, Decibel! <decibel@decibel.org> wrote:
> On Jun 19, 2008, at 8:13 AM, Carol Walter wrote:
>>
>> I just did an upgrade from 8.1 to 8.2.3. We'll go up to 8.3.3 very soon,
>> but for reasons I won't go into, this intermediate step was necessary. My
>> problem is, now that the upgrade is done, how can I clean up the database
>> from the old version. I leave the original database up as long as I can
>> when I do an upgrade just in case I need to revert to it. Now I have the
>> databases from two versions on my server and I need to get rid of the old
>> one. Can I just remove the old files from the data directories? With other
>> systems, I've had trouble removing database files because upgrades use
>> certain files from old versions. I don't want to break my new database.
>> I'm on Solaris 10.
>
>
> Not only does the new version not use files from the old, it doesn't even
> know it exists. You can just nuke all the 8.1 stuff.

If you're paranoid, then you can also do:

sudo chmod 000 /old/data/dir

and see if anything breaks.

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

Re: [HACKERS] Location for pgstat.stat

On Tue, 1 Jul 2008, Tom Lane wrote:

> Magnus Hagander <magnus@hagander.net> writes:
>> Tom Lane wrote:
>>> Hmm ... that would almost certainly result in the stats being lost over
>>> a system shutdown. How much do we care?
>
>> Only for those who put it on a ramdrive. The default, unless you
>> move/sync it off, would still be the same as it is today. While not
>> perfect, the performance difference of going to a ramdrive might easily
>> be enough to offset that in some cases, I think.
>
> Well, what I was wondering about is whether it'd be worth adding logic
> to copy the file to/from a "safer" location at startup/shutdown.

Anyone who needs fast stats storage enough that they're going to symlink
it to RAM should be perfectly capable of scripting server startup/shutdown
to shuffle that to/from a more permanent location. Compared to the admin
chores you're likely to encounter before reaching that scale it's a pretty
easy job, and it's not like losing that data file is a giant loss in any
case. The only thing I could see putting into the server code to help
support this situation is rejecting an old stats file and starting from
scratch instead if they restored a previous version after a crash that
didn't save an updated copy.

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

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

Re: [PERFORM] Select running slow on Postgres

On Tue, Jul 1, 2008 at 1:29 PM, samantha mahindrakar
<sam.mahindrakar@gmail.com> wrote:
> Hi
> I have a select statement that runs on a partition having say couple
> million rows.
> The tabel has indexes on two colums. However the query uses the
> non-indexed colums too in its where clause.
> For example:
> SELECT lane_id,measurement_start,
> measurement_end,speed,volume,occupancy,quality,effective_date
> FROM tss.lane_data_06_08
> WHERE lane_id in(select lane_id from lane_info where inactive is null )
> AND date_part('hour', measurement_start) between 5 and 23
> AND date_part('day',measurement_start)=30
> GROUP BY lane_id,measurement_start,measurement_end,speed,volume,occupancy,quality,effective_date
> ORDER BY lane_id, measurement_start
>
> out of this only lane_id and mesaurement_start are indexed. This query
> will return around 10,000 rows. But it seems to be taking a long time
> to execute which doesnt make sense for a select statement. It doesnt
> make any sense to create index for every field we are gonna use in tne
> where clause.
> Isnt there any way we can improve the performance?

I'm guessing that adding an index for either
date_part('hour',measurement_start) or
date_part('day',measurement_start) or both would help.

What does explain analyze select ... (rest of query here) say?

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

[ODBC] Function sequence error when executing DELETE with 08.03.0200

Hello,

I'm trying to get the latest pgsql-odbc driver working with my database
creation app.

The following error occurs when a DELETE statement is executed:

12830016:S1010:[iODBC][Driver Manager]Function sequence error

I'm running pgsql-odbc 08.03.0200 against a PostgreSQL 8.2.3 database,
on Mac OS X Leopard using iODBC.

Any assistance would be appreciated.

Regards,

Nick

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

Re: [HACKERS] Location for pgstat.stat

Alvaro Herrera wrote:
> Magnus Hagander wrote:
>
>> Not sure. I guess my own personal concern would be how badly is
>> autovacuum affected by having to start off a blank set of stats? Any
>> other uses I have I think are capable of dealing with reset-to-zero states.
>
> Well, it doesn't :-) No database or table will be processed until stat
> entries are created, and then I think it will first wait until enough
> activity gathers to take any actions at all.

That's not actualliy not affected, but it does seem like it wouldn't be
a very big issue. If one table was just about to be vacuumed or
analyzed, this would just push it up to twice the threshold, right?

//Magnus


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

Re: [HACKERS] A new take on the foot-gun meme

"Shane Ambler" <pgsql@Sheeky.Biz> writes:

> Robert Treat wrote:
>
>>> So is that a "golf club gun"?
>>
>> Careful what you wish for....
>> http://www.totallyabsurd.com/12gaugegolfclub.htm
>
> I reckon they watched Caddyshack (I think that was the one) and thought they
> could get the patent before someone actually tried selling them.

Surely a movie counts as "published"!?

--
Gregory Stark
EnterpriseDB

http://www.enterprisedb.com

Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!

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

Re: [NOVICE] Automatic SQL command execution

--- On Fri, 6/27/08, Sean Davis <sdavis2@mail.nih.gov> wrote:

>> Postgresql doesn't have tools to do that directly. If
>> you are on
>> Linux or Unix, you can use cron; Windows probably has
>> something
>> similar to automate tasks.
>>

> I use nncron lite. Free and cron file compatible.

> http://www.nncron.ru/nncronlt/help/help.htm


> Lewis R Cunningham

> An Expert's Guide to Oracle Technology
> http://blogs.ittoolbox.com/oracle/guide/


> Postgres Forums
> http://postgres.enterprisedb.com/forum.do



Actually you can use PgAgent which comes packaged with PgAdmin III.
I've used it successfully on both windows and RedHat linux. I think it
works anywhere PostgreSQL works. The nice thing about PgAgent is that
you can see the status of jobs from the PgAdmin administrative tool and
trigger a manual run of a scheduled job from PgAdmin tool from anywhere.

http://www.pgadmin.org/docs/1.8/pgagent.html


Hope that helps,
Regina
-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.


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

[PERFORM] Select running slow on Postgres

Hi
I have a select statement that runs on a partition having say couple
million rows.
The tabel has indexes on two colums. However the query uses the
non-indexed colums too in its where clause.
For example:
SELECT lane_id,measurement_start,
measurement_end,speed,volume,occupancy,quality,effective_date
FROM tss.lane_data_06_08
WHERE lane_id in(select lane_id from lane_info where inactive is null )
AND date_part('hour', measurement_start) between 5 and 23
AND date_part('day',measurement_start)=30
GROUP BY lane_id,measurement_start,measurement_end,speed,volume,occupancy,quality,effective_date
ORDER BY lane_id, measurement_start

out of this only lane_id and mesaurement_start are indexed. This query
will return around 10,000 rows. But it seems to be taking a long time
to execute which doesnt make sense for a select statement. It doesnt
make any sense to create index for every field we are gonna use in tne
where clause.
Isnt there any way we can improve the performance?


Samantha

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

Re: [HACKERS] Location for pgstat.stat

Magnus Hagander wrote:

> Not sure. I guess my own personal concern would be how badly is
> autovacuum affected by having to start off a blank set of stats? Any
> other uses I have I think are capable of dealing with reset-to-zero states.

Well, it doesn't :-) No database or table will be processed until stat
entries are created, and then I think it will first wait until enough
activity gathers to take any actions at all.

--
Alvaro Herrera

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

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

Re: [HACKERS] Location for pgstat.stat

Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> Tom Lane wrote:
>>> Hmm ... that would almost certainly result in the stats being lost over
>>> a system shutdown. How much do we care?
>
>> Only for those who put it on a ramdrive. The default, unless you
>> move/sync it off, would still be the same as it is today. While not
>> perfect, the performance difference of going to a ramdrive might easily
>> be enough to offset that in some cases, I think.
>
> Well, what I was wondering about is whether it'd be worth adding logic
> to copy the file to/from a "safer" location at startup/shutdown.

Oh, I see. I should think more before I answer sometimes :-)

Not sure. I guess my own personal concern would be how badly is
autovacuum affected by having to start off a blank set of stats? Any
other uses I have I think are capable of dealing with reset-to-zero states.

//Magnus


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

Re: [HACKERS] Fairly serious bug induced by latest guc enum changes

Magnus Hagander <magnus@hagander.net> writes:
> Not having looked at md.c (I confess...) but don't we have a problem in
> case we have closed the file without fsyncing it, and then change the
> fsync parameter?

Well, we don't promise to retroactively fsync stuff we didn't before;
and I wouldn't expect that to happen if I were changing the setting.
What I *would* expect is that the system immediately starts to act
according to the new setting, and that's not true as the code stands.

As you say, the whole thing is pretty dubious from a data safety
standpoint anyway. What I am concerned about here is people trying to
compare performance measurements under different settings, and not being
aware that the system's behavior doesn't change when they tell it to.

regards, tom lane

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

[planet] Testing...ignore..

--
Devrim GÜNDÜZ <devrim@gunduz.org>


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

Re: [HACKERS] Location for pgstat.stat

Magnus Hagander <magnus@hagander.net> writes:
> Tom Lane wrote:
>> Hmm ... that would almost certainly result in the stats being lost over
>> a system shutdown. How much do we care?

> Only for those who put it on a ramdrive. The default, unless you
> move/sync it off, would still be the same as it is today. While not
> perfect, the performance difference of going to a ramdrive might easily
> be enough to offset that in some cases, I think.

Well, what I was wondering about is whether it'd be worth adding logic
to copy the file to/from a "safer" location at startup/shutdown.

regards, tom lane

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

Re: [HACKERS] Fairly serious bug induced by latest guc enum changes

Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> Or are you talking about changing the variable "fsync"? If so, doesn't
>> "fsync=off" also change the behavior of other parts of the code, so it's
>> not just WAL, which means it'd be pretty unsafe *anyway* unless you
>> actually "sync" the disks, and not just fsync?
>
> No, because the other uses of it are controlling whether to issue
> fsync() calls dynamically. The use in get_sync_bit is the only one
> that sets persistent state. In fact md.c goes out of its way to ensure
> that changing fsync on the fly behaves as expected.

Not having looked at md.c (I confess...) but don't we have a problem in
case we have closed the file without fsyncing it, and then change the
fsync parameter?

Either way, I see your point, but I doubt it's worth getting upset over.
Funning with fsync=off in the first place is bad, and if it takes you
one WAL segment to "recover", I think that's acceptable...

//Magnus


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

Re: [HACKERS] Fairly serious bug induced by latest guc enum changes

Magnus Hagander <magnus@hagander.net> writes:
> Or are you talking about changing the variable "fsync"? If so, doesn't
> "fsync=off" also change the behavior of other parts of the code, so it's
> not just WAL, which means it'd be pretty unsafe *anyway* unless you
> actually "sync" the disks, and not just fsync?

No, because the other uses of it are controlling whether to issue
fsync() calls dynamically. The use in get_sync_bit is the only one
that sets persistent state. In fact md.c goes out of its way to ensure
that changing fsync on the fly behaves as expected.

regards, tom lane

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

Re: [HACKERS] Access to localized_str_tolower()

On Jul 1, 2008, at 11:59, Tom Lane wrote:

> These are static --- that's why you can't get at them from outside
> the module.
>
> I think your best bet for an 8.3 version of citext is just to
> copy-and-paste a lot of code from HEAD.

Well, that's what I'd done already; I was just trying to make it
simpler. So, well, now I don't have to do anything. :-)

Thanks,

David

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

Re: [INTERFACES] Where to find libpq++ ?

"rick richards" <rr047928@gmail.com> writes:
> Please advice on where to find libpq++.

If it's not on pgfoundry, you'll have to go digging in PG 7.2.x source
tarballs. In any case I think there's about 0 chance of finding it
prebuilt for any modern distro --- you'll have to compile from source.

regards, tom lane

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

Re: [HACKERS] Access to localized_str_tolower()

"David E. Wheeler" <david@kineticode.com> writes:
> From formatting.c in 8.3.1:
> static char *localized_str_toupper(char *buff);
> static char *localized_str_tolower(char *buff);

These are static --- that's why you can't get at them from outside
the module.

I think your best bet for an 8.3 version of citext is just to
copy-and-paste a lot of code from HEAD.

regards, tom lane

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

Re: [HACKERS] Location for pgstat.stat

Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> But pending that we have that, how about we just move it into it's own
>> subdirectory?
>> This would make it possible to symlink or mount that directory off to a
>> ramdrive (for example).
>
> Hmm ... that would almost certainly result in the stats being lost over
> a system shutdown. How much do we care?

Only for those who put it on a ramdrive. The default, unless you
move/sync it off, would still be the same as it is today. While not
perfect, the performance difference of going to a ramdrive might easily
be enough to offset that in some cases, I think.

//Magnus


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

Re: [HACKERS] Fairly serious bug induced by latest guc enum changes

Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> Tom Lane wrote:
>>> Hmm ... or at least more or less fixed. Seems like there's no provision
>>> to close and reopen the file if enableFsync changes. Not sure if that's
>>> worth worrying about.
>
>> We didn't have that before either, did we?
>
> No, so I think it's a pre-existing bug.

Ok, at least I'm reading the code right.


>> We close it when the sync bit
>> changes, but not just if we change say between fsync() and fdatasync().
>> Is there any actual reason we'd want to close it?
>
> The point is that if you turn the fsync GUC on or off while using a wal
> sync mode that requires supplying an option flag to open(), then really
> you ought to close the WAL file and re-open it with the new correct
> option flags. The fact that we're not doing that implies that the
> effects of a change in fsync might not fully take effect until the next
> WAL segment is started. Whether this is worth fixing isn't real clear.

What scenario does it actually happen in, though? Doesn't the check:
if (get_sync_bit(sync_method) != get_sync_bit(new_sync_method))

take care of that? If the sync bit changed, we close the file?


Or are you talking about changing the variable "fsync"? If so, doesn't
"fsync=off" also change the behavior of other parts of the code, so it's
not just WAL, which means it'd be pretty unsafe *anyway* unless you
actually "sync" the disks, and not just fsync?

//Magnus


//Magnus

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