Tuesday, June 24, 2008

Re: [GENERAL] backslashes in 8.3.3

"Brandon Metcalf" <bmetcalf@nortel.com> writes:
> t == tgl@sss.pgh.pa.us writes:
> t> Uh, no, that is certainly *not* the behavior you were getting in 8.1;
> t> 8.1's behavior corresponds to both switches off.

> OK. I'm confused. With 8.1.5 we never had to do anything special
> with backslashes. When we upgraded to 8.3.3, backslashes in our
> INSERTs caused problems until we turn _on_
> standard_conforming_strings.

Maybe something changed on the client side? 8.1 definitely does not have
standard_conforming_strings, but perhaps you had some client-side
code that compensated by inserting backslashes.

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] Probably been asked a hundred times before.

On Tue, Jun 24, 2008 at 8:30 AM, David Siebert <david@eclipsecat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Which disto is best for running a Postgres server?

That is the subject of many a holy flame war. FreeBSD 7.0 seems to
currently be regarded as being one of the top performers.

I use ubuntu because it's easier to maintain and it provides very good
performance

> I just installed OpenSuse and downloaded and compiled the latest version
> of Postgres. It isn't that big of a hassle but I noticed that almost
> none of the big distros keep all that up to date with Postgres as far as
> what they have in their repositories.

Ubuntu does, and there are the PGDG rpms on the postgresql website
that work on RHEL / Centos / Whitebox linux quite nicely.

> I was wondering if anybody has made an Postgres centric distro? Just a
> nice stripped down server Distro that is ideal for running a database
> server on?

There's been a few pg_live CDs floating around. They're more of a
demo / super easy setup type of thing, not intended for production
use. But they are very handy for trying out pgsql.

--
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] Need "Round Robin Reviewer" volunteers

Josh Berkus wrote:
> Hackers,
>
> Hey! So far, a sum total of *2* people have signed up to be assigned
> reviewers, and one of them I put down myself. If only Greg and Alvaro
> are available to review patches, no wonder our commit fests take so long!

Oh, also -- you don't have to be a committer to be a reviewer. If you
can read C code, and know the PostgreSQL coding conventions, you can be
a reviewer!

--Josh

--
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] Git Repository for WITH RECURSIVE and others

> Well I will grant that I don't know that there is a better forum because
> we don't have a yourrepos@postgresql.org :) but I am pretty certain that
> discussion of the Git repo administration doesn't have much to do with
> -hackers.

How about some generic list? alt-repos@postgresql.org or something like
that?

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

[COMMITTERS] pgsql: Reduce the alignment requirement of type "name" from int to char,

Log Message:
-----------
Reduce the alignment requirement of type "name" from int to char, and arrange
to suppress zero-padding of "name" entries in indexes.

The alignment change is unlikely to save any space, but it is really needed
anyway to make the world safe for our widespread practice of passing plain
old C strings to functions that are declared as taking Name. In the previous
coding, the C compiler was entitled to assume that a Name pointer was
word-aligned; but we were failing to guarantee that. I think the reason
we'd not seen failures is that usually the only thing that gets done with
such a pointer is strcmp(), which is hard to optimize in a way that exploits
word-alignment. Still, some enterprising compiler guy will probably think
of a way eventually, or we might change our code in a way that exposes
more-obvious optimization opportunities.

The padding change is accomplished in one-liner fashion by declaring the
"name" index opclasses to use storage type "cstring" in pg_opclass.h.
Normally btree and hash don't allow a nondefault storage type, because they
don't have any provisions for converting the input datum to another type.
However, because name and cstring are effectively the same thing except for
padding, no conversion is needed --- we only need index_form_tuple() to treat
the datum as being cstring not name, and this is sufficient. This seems to
make for about a one-third reduction in the typical sizes of system catalog
indexes that involve "name" columns, of which we have many.

These two changes are only weakly related, but the alignment change makes
me feel safer that the padding change won't introduce problems, so I'm
committing them together.

Modified Files:
--------------
pgsql/src/backend/bootstrap:
bootstrap.c (r1.243 -> r1.244)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/bootstrap/bootstrap.c?r1=1.243&r2=1.244)
pgsql/src/backend/utils/adt:
name.c (r1.62 -> r1.63)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/name.c?r1=1.62&r2=1.63)
pgsql/src/include:
c.h (r1.227 -> r1.228)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/c.h?r1=1.227&r2=1.228)
pg_config_manual.h (r1.33 -> r1.34)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/pg_config_manual.h?r1=1.33&r2=1.34)
pgsql/src/include/catalog:
catversion.h (r1.463 -> r1.464)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/catversion.h?r1=1.463&r2=1.464)
pg_attribute.h (r1.137 -> r1.138)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/pg_attribute.h?r1=1.137&r2=1.138)
pg_opclass.h (r1.81 -> r1.82)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/pg_opclass.h?r1=1.81&r2=1.82)
pg_type.h (r1.195 -> r1.196)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/pg_type.h?r1=1.195&r2=1.196)

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

Re: [pgsql-advocacy] [HACKERS] My upcoming events

Bruce Momjian wrote:
> I recently mentioned I am speaking in New York City tonight. I am also
> speaking about open source in Massachusetts in July; see my events web
> page for details on both events:
>
>

http://momjian.us/main/events.html
>
> Also, I assume people like these details posted to hackers and advocacy,
> but _not_ to the events web page or the announce email list.

Your blog (& on planetpostgresql) would be better than any of these.

Also, you should post on local UG mailing lists.

As for the events page, it depends on the size/depth of PostgreSQL
content of the event. The WWW team can make the decision, though.

--Josh


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

Re: [HACKERS] Git Repository for WITH RECURSIVE and others

On Tue, Jun 24, 2008 at 05:27:38PM +0200, Magnus Hagander wrote:
> David Fetter wrote:
> > On Tue, Jun 24, 2008 at 09:52:22AM +0200, Magnus Hagander wrote:
> >> David Fetter wrote:
> >>> Folks,
> >>>
> >>> With lots of help from Greg Sabino Mullane, I've set up a git
> >>> repository for the WITH RECURSIVE patches on
> >>> <http://git.postgresql.org/>.
> >>>
> >>> What other patches would people like to try maintaining this way
> >>> until commitfest?
> >>>
> >>> It looks like gitosis is a good way to grant write access to git
> >>> repositories, but it's not yet packaged for FreeBSD. Any ideas
> >>> about how to handle this?
> >> As you were answered the last time you asked about it, people are
> >> already working on this.
> >
> > Which people, and what are they doing? The silence here has been
> > deafening.
>
> Peter is in charge of the GIT repository, and I've offered to make
> the changes once we've agreed exactly on what should be done.

I think it's time for a few more people--yes, I'm volunteering for the
work--to get the needed access for this :)

> >> Unfortunately, the requirements have also been raised a bit (such
> >> as allowing a user to delegate access to another user)
> >
> > Who raised those requirements, and where did that discussion take
> > place?
>
> Peter did.

So, no public discussion anywhere, even though this is something that
the future development of Postgres is supposed to depend on. That's
just great.

> > I don't recall any decision to do any of this by star chamber and
> > secret cabal, and frankly, moving the goalposts on this is a great
> > way to have it never actually happen. Is that your intention?
>
> Not mine :-) My suggestion is to fix what we have now, and then add
> more stuff later.

Excellent!

> >> which means it will take longer.
> >>
> >> Now, if you can give us a step-by-step on how to set it up, that
> >> would certainly help ;-)
> >
> > Gitosis does not, as far as I can tell, have that delegation
> > capability, but I've come up with a way to do this:
> >
> > 1. Use git-shell. Yes, this does involve creating one shell account
> > for each project, but git-shell is, by design, very short on
> > exploitable capability.
> >
> > 2. Make the .ssh directory a git repository.
> >
> > 3. Edit .ssh/authorized_keys and push via git.
>
> I was looking into being able to do it using gitosis, with an
> interface on top of it's existing GIT repository for being able to
> delegate this.

I discussed this with gitosis's author, and he wants to keep gitosis
from becoming "a sourceforge reimplementation." He did, however,
commit to stamping it 1.0 and putting up a TODO list. I'd like to
package it up for FreeBSD and Fedora, those being two common
platforms.

> I think it can be done without modifying gitosis itself, by just
> writing some simple frontend script on top of it.

Would the front-end script just modify gitosis.conf? If so, it's got
to be pretty bullet-proof because it can step on access to all the git
repositories.

> What do you think of this idea?

It's complicated :(

Wouldn't it be easier to have a gitosis admin team with the needed
access?

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

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

Re: [pgsql-es-ayuda] INCREMENTAR EL VALOR DE UNA PARTE DE UNA COLUMNA DE UNA TABALA ESPECIFICA

solo por curiosidad que pasa si pones este comando

SELECT sum(sellprice) from parts WHERE partsgroup_id = (SELECT id
FROM partsgroup WHERE partsgroup = 'Brushes'); UPDATE parts SET
sellprice = (sellprice * 1.10) WHERE partsgroup_id =(SELECT id FROM
partsgroup WHERE partsgroup = 'Brushes');SELECT sum(sellprice) from
parts WHERE partsgroup_id = (SELECT id FROM partsgroup WHERE
partsgroup = 'Brushes');

Todo pones como un solo comando, no tres

2008/6/23 Ricardo Granados Tiznado <ricardo@solargi.net>:
> Saludos.
>
> tal como lo comente en el anterior mail, me encontre una sentencia en
> donde supuestamente se hacen cambios en un grupo de datos
> pertenecientes a un columna especifica.
>
> y es el siguiente:
>
> UPDATE parts
> SET sellprice = (sellprice * 1.10)
> WHERE partsgroup_id =
> (SELECT id FROM partsgroup
> WHERE partsgroup = 'Brushes');
>
> lo aplico y como resultado tal parece que hace los cambios, pero al
> confirmar en el porgrama no hay ningun precio cambiado.
>
> adjunto informacion del procedimiento mediante putty:
>
> -bash-3.1$ psql testimport
> Welcome to psql 8.1.11, the PostgreSQL interactive terminal.
>
> Type: \copyright for distribution terms
> \h for help with SQL commands
> \? for help with psql commands
> \g or terminate with semicolon to execute query
> \q to quit
>
> testimport=# UPDATE parts SET sellprice = (sellprice * 1.10) WHERE
> partsgroup_id =10173;
> UPDATE 132
>
>
> La pregunta es si la sintaxis es correcta o se me esta pasando algo -
> agradeceré sus comentarios.
>
>
> Ricardo Granados.
> --
> TIP 10: no uses HTML en tu pregunta, seguro que quien responda no podrá leerlo
>

--
________________________________________
Lo bueno de vivir un dia mas
es saber que nos queda un dia menos de vida
--
TIP 9: visita nuestro canal de IRC #postgresql-es en irc.freenode.net

[HACKERS] My upcoming events

I recently mentioned I am speaking in New York City tonight. I am also
speaking about open source in Massachusetts in July; see my events web
page for details on both events:

http://momjian.us/main/events.html

Also, I assume people like these details posted to hackers and advocacy,
but _not_ to the events web page or the announce email list.

--
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-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [GENERAL] backslashes in 8.3.3

t == tgl@sss.pgh.pa.us writes:

t> "Brandon Metcalf" <bmetcalf@nortel.com> writes:
t> > t == tgl@sss.pgh.pa.us writes:
t> > t> Well, if your intent is to replicate 8.1's behavior, you should instead
t> > t> frob the other switch.

t> > I now have
t> > escape_string_warning = off
t> > and
t> > standard_conforming_strings = on
t> > in postgresql.conf and things are back to how they were. That is no
t> > warnings and backslashes treated literally.

t> Uh, no, that is certainly *not* the behavior you were getting in 8.1;
t> 8.1's behavior corresponds to both switches off.

OK. I'm confused. With 8.1.5 we never had to do anything special
with backslashes. When we upgraded to 8.3.3, backslashes in our
INSERTs caused problems until we turn _on_
standard_conforming_strings.

t> > A related question, is it in any way possible that a control sequence
t> > could have been sent from a client that caused a fast shutdown? Our
t> > server log shows a fast shutdown request last night, but nobody
t> > manually issued such a request.

t> Fast shutdown means something sent SIGINT to the postmaster.
t> The only way I've heard for that to happen "accidentally" is
t> if you normally launch the postmaster by hand in a way that
t> leaves it attached to your terminal session --- then control-C
t> in that session would SIGINT the postmaster.

That could have been it.


--
Brandon

--
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] backslashes in 8.3.3

"Brandon Metcalf" <bmetcalf@nortel.com> writes:
> t == tgl@sss.pgh.pa.us writes:
> t> Well, if your intent is to replicate 8.1's behavior, you should instead
> t> frob the other switch.

> I now have
> escape_string_warning = off
> and
> standard_conforming_strings = on
> in postgresql.conf and things are back to how they were. That is no
> warnings and backslashes treated literally.

Uh, no, that is certainly *not* the behavior you were getting in 8.1;
8.1's behavior corresponds to both switches off.

> A related question, is it in any way possible that a control sequence
> could have been sent from a client that caused a fast shutdown? Our
> server log shows a fast shutdown request last night, but nobody
> manually issued such a request.

Fast shutdown means something sent SIGINT to the postmaster.
The only way I've heard for that to happen "accidentally" is
if you normally launch the postmaster by hand in a way that
leaves it attached to your terminal session --- then control-C
in that session would SIGINT the postmaster.

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: [HACKERS] Git Repository for WITH RECURSIVE and others

On Tue, 2008-06-24 at 09:27 -0700, David Fetter wrote:
> On Tue, Jun 24, 2008 at 09:21:27AM -0700, Joshua D. Drake wrote:
> > On Tue, 2008-06-24 at 07:55 -0700, David Fetter wrote:

> > Lastly, you could also perhaps take the 10 seconds it takes to find
> > this page:
> >
> > http://git.postgresql.org/static/serviceinfo.html
> >
> > Where it tells you exactly how to participate.
>
> Yes, and since you brought that up, it appears that mail to
> gitadmin@git.postgresql.org goes to /dev/null. I specifically asked
> for a couple of different things at that email, and have gotten 'tude
> but no action.

Well I can appreciate that problem but its their project, if they are
unwilling to answer you...

>
> As far as discussion goes, if there's a forum more appropriate than
> -hackers, please feel free to specify exactly what that forum is and
> explain why you believe that. :)

Well I will grant that I don't know that there is a better forum because
we don't have a yourrepos@postgresql.org :) but I am pretty certain that
discussion of the Git repo administration doesn't have much to do with
-hackers.

Either way it would seem to me the place for this to happen would be
between yourself, Magnus and Peter. Once everything is done, put it on
wiki... and be done with it :)

Sincerely,

Joshua D. Drake

--
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] Need "Round Robin Reviewer" volunteers

Hackers,

Hey! So far, a sum total of *2* people have signed up to be assigned
reviewers, and one of them I put down myself. If only Greg and Alvaro
are available to review patches, no wonder our commit fests take so long!

> At the developer meeting, we determined that one thing needed to speed
> up the commitfests is a list of people who were available to review
> assigned patches, and someone to do the assigning. Well, for July I'm
> the assignor, and I'm looking for some assignees. Here's how it will work:
>
> July 1: commitfest starts.
> July 7: reviewer assignment, 1st round
> July 10: reviewer assignment, 2nd round
> July 15 (hopefully): commitfest complete.
>
> Reviewer assgnment: I look over the list of submitted patches and see
> which ones aren't getting attention. shared_buffer fashion, I start
> assigning them round-robin from the people our "pool" of reviewers who
> haven't already taken on patches. I'll e-mail you with a patch I want
> you to review, and you will accept or reject the assignment promptly.
> I'll continue this until everything is assigned.
>
> So, can everyone who is qualified to be part of the pool please put your
> name on the RRR list?
>
> http://wiki.postgresql.org/wiki/RRReviewers
>
> Thanks!
>
> --Josh Berkus
>


--
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] Git Repository for WITH RECURSIVE and others

On Tue, 2008-06-24 at 07:55 -0700, David Fetter wrote:
> On Tue, Jun 24, 2008 at 09:52:22AM +0200, Magnus Hagander wrote:
> > David Fetter wrote:
> > > Folks,

>
> > Unfortunately, the requirements have also been raised a bit (such as
> > allowing a user to delegate access to another user)
>
> Who raised those requirements, and where did that discussion take
> place? I don't recall any decision to do any of this by star chamber
> and secret cabal, and frankly, moving the goalposts on this is a great
> way to have it never actually happen. Is that your intention?

You could take your complaints to an appropriate forum, which is not
hackers. Then you could take it up with the people that are actually in
charge of the repository.

Lastly, you could also perhaps take the 10 seconds it takes to find this
page:

http://git.postgresql.org/static/serviceinfo.html

Where it tells you exactly how to participate.


Joshua D. Drake

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

Re: [ADMIN] Functions

Hello,

There a some differences from MySQL to PostgreSQL. In PostgreSQL we use Functions, what you called "Store Procedures", that do the same thing.
In Postgres you can combine the Functions with "Triggers".
Triggers are procedures that will be done when you do some U, I or D, you have to specific the operation.
In the Functions you can work with some languages: plpgsql (the best, in my oppinion), SQL, C, Ruby, Perl, Python, and so on.
So, you have to create a function that does the operation you want, and then you call that function using "select * from [function]".


About the $n, you can create an alias for the variable, using clause "DECLARE":
DECLARE
  vardocid alias for $1;

An example:
CREATE OR REPLACE FUNCTION test (integer) RETURNS integer AS
$BODY$
DECLARE
  vardocid alias for $1;
BEGIN
  update docs
  set
    posted = -1
  where
    docid = vardocid;

  RETURN 1;
END
$BODY$
LANGUAGE 'plpgsql';

select test (2);

2008/6/24 C K <shreeseva.it@gmail.com>:
Dear Members,
I am switching our ERP and other under development applications from MySQL to PostgreSQL. While working on this, I got some problems while creating store procedures. As PG does not support procedures, rather it uses Functions. While creating a function from MySQL as

CREATE DEFINER=`root`@`localhost` PROCEDURE `postdoc`(vardocid int)
    MODIFIES SQL DATA
UPDATE docs        SET posted = -1        WHERE docid = vardocid;

on PG, it gave me error for using variable in where condition. Other things are properly defined thru' PGAdmin. Does PG do no support to use variables or variable names in the functions? As per manual for 8.3, I understood to use $1, $2...$n for the input parameter reference, but it is difficult to mark them correclty in a big function having many parameters.
How could I use varibles in the functions?
Plesae help and give the details on above issue.

Thanks

CPK
--
Keep your Environment clean and green.

Re: [GENERAL] what are rules for?

Martijn van Oosterhout <kleptog@svana.org> writes:
> On Tue, Jun 24, 2008 at 10:28:00AM -0500, Michael Shulman wrote:
>> My question was, what else *can* you do with a rule that you *can't*
>> do with a trigger? Are rules only a way to speed up things that could
>> also be done with triggers?

> Well, views for one.

To expand on that: it's pretty hard to see how update or delete triggers
on a view would work. Insert is easy, because if left to its own
devices the system would in fact try to insert a tuple into the view
relation, and that action could fire a trigger which could redirect the
insertion someplace else. But updates and deletes require a
pre-existing target tuple, and there just aren't any of those in a view
relation. (Another way to say it is that update/delete require a CTID
column, which a view hasn't got.)

So view update/delete appear to require a transformational-rule kind
of approach instead of an actions-on-physical-tuples kind of approach.

If you've got a better idea we're all ears ...

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

[COMMITTERS] pgsql: TODO item done: < o Prevent pg_dump/pg_restore from being

Log Message:
-----------
TODO item done:

< o Prevent pg_dump/pg_restore from being affected by
> o -Prevent pg_dump/pg_restore from being affected by

Modified Files:
--------------
pgsql/doc:
TODO (r1.2472 -> r1.2473)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/TODO?r1=1.2472&r2=1.2473)
pgsql/doc/src/FAQ:
TODO.html (r1.978 -> r1.979)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/FAQ/TODO.html?r1=1.978&r2=1.979)

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

Re: [PATCHES] [HACKERS] Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout

Joshua D. Drake wrote:
> Alex Hunsaker wrote:
> > On Mon, Jun 23, 2008 at 4:51 PM, Bruce Momjian <bruce@momjian.us> wrote:
> >> I would like to get do this without adding a new --use-statement-timeout
> >> flag. Is anyone going to want to honor statement_timeout during
> >> pg_dump/pg_restore? I thought we were just going to disable it.
> >
> > I believe so. This was when not everyone was convinced. Im fairly
> > certain Josh original patch is in the commit fest. So feel free to
> > drop this one.
> >
>
> My patch has been committed.

Ah, I see, but with no switch. Thanks.

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

Re: [ADMIN] plpgsql function seems to be leaking memory

Guillaume Lelarge <guillaume@lelarge.info> writes:
> Tom Lane a écrit :
>> What do you have shared_buffers set to? I think you might be getting
>> fooled by top's treatment of shared memory (ie, it starts to count
>> shared pages after the process touches them for the first time).

> That's what I thought at first when I saw Marc's email. I tried his
> example many times, with different values for shared_buffers. RSS column
> climbs until it reaches more or less the shared_buffers configuration.
> But, if I launch another psql, this process will have a much lower value
> on the RSS column. Shouldn't it get the RSS at the same value, even when
> the process starts ?

No, that's exactly the point. Linux top includes in a process's
reported size its actual private space, plus however many pages of
shared memory that process has physically accessed so far. So any PG
backend that's doing a material amount of table access is going to show
an RSS that starts low and creeps up to roughly the size of your shared
memory block, quite independently of what its actual private space usage
is. It's just a matter of how many buffers it has had occasion to use.

This is all pretty OS-dependent. Some systems don't count shared memory
at all (HPUX seems not to), and some other ones report a separate total
for shared memory so that you can mentally subtract it.

regards, tom lane

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

Re: [ADMIN] plpgsql function seems to be leaking memory

Tom Lane a écrit :
> Marc Cousin <mcousin@sigma.fr> writes:
>> I'm having a problem with plpgsql functions leaking memory.
>
> Your example shows absolutely no memory leak here, in either 8.3.3
> or CVS HEAD.
>
>> I see the postgresql process growing from 8MB to about 400 MB during this
>> run...
>
> What do you have shared_buffers set to? I think you might be getting
> fooled by top's treatment of shared memory (ie, it starts to count
> shared pages after the process touches them for the first time).
>

That's what I thought at first when I saw Marc's email. I tried his
example many times, with different values for shared_buffers. RSS column
climbs until it reaches more or less the shared_buffers configuration.
But, if I launch another psql, this process will have a much lower value
on the RSS column. Shouldn't it get the RSS at the same value, even when
the process starts ?

I'm a bit puzzled by this column, anyone has a URL where I can find more
info?

Regards.


--
Guillaume.

http://www.postgresqlfr.org

http://dalibo.com

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

Re: [ADMIN] plpgsql function seems to be leaking memory

On Tuesday 24 June 2008 16:56:10 Tom Lane wrote:
> Marc Cousin <mcousin@sigma.fr> writes:
> > I'm having a problem with plpgsql functions leaking memory.
>
> Your example shows absolutely no memory leak here, in either 8.3.3
> or CVS HEAD.
>
> > I see the postgresql process growing from 8MB to about 400 MB during this
> > run...
>
> What do you have shared_buffers set to? I think you might be getting
> fooled by top's treatment of shared memory (ie, it starts to count
> shared pages after the process touches them for the first time).
>
> regards, tom lane


I'm seeing this with ps aux, you're (almost) right... And I've been wasting your time.

At the begining :
postgres 23305 39.2 0.8 1275484 31208 ? Rs 17:07 0:18 postgres: postgres test [local] idle in transaction


Then after a few seconds :
postgres 23305 39.2 0.8 1275484 31208 ? Rs 17:07 0:18 postgres: postgres test [local] idle in transaction

The RSS column is growing ... Here it is only a test, but I've been having
it get to more that 500MB on the real use case, and it got me worried...

shared_buffers is at 1GB...

So in fact, the problem is linked to RSS containing some shared memory...
And that this growing memory is because the process has put all those
modified blocks in the shared buffers... I've confirmed that with doing the
inserts out of plpgsql, and it's also the same if I select the process...
And I never noticed it before ...

It all started with a plperl procedure and I was afraid I had a leak in it ... :)


Sorry to have wasted your time and thanks a lot ...

Regards.

--
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] Git Repository for WITH RECURSIVE and others

David Fetter wrote:
> On Tue, Jun 24, 2008 at 09:52:22AM +0200, Magnus Hagander wrote:
>> David Fetter wrote:
>>> Folks,
>>>
>>> With lots of help from Greg Sabino Mullane, I've set up a git
>>> repository for the WITH RECURSIVE patches on
>>> <http://git.postgresql.org/>.
>>>
>>> What other patches would people like to try maintaining this way
>>> until commitfest?
>>>
>>> It looks like gitosis is a good way to grant write access to git
>>> repositories, but it's not yet packaged for FreeBSD. Any ideas
>>> about how to handle this?
>> As you were answered the last time you asked about it, people are
>> already working on this.
>
> Which people, and what are they doing? The silence here has been
> deafening.

Peter is in charge of the GIT repository, and I've offered to make the
changes once we've agreed exactly on what should be done.


>> Unfortunately, the requirements have also been raised a bit (such as
>> allowing a user to delegate access to another user)
>
> Who raised those requirements, and where did that discussion take
> place?

Peter did.


> I don't recall any decision to do any of this by star chamber
> and secret cabal, and frankly, moving the goalposts on this is a great
> way to have it never actually happen. Is that your intention?

Not mine :-) My suggestion is to fix what we have now, and then add more
stuff later.


>> which means it will take longer.
>>
>> Now, if you can give us a step-by-step on how to set it up, that
>> would certainly help ;-)
>
> Gitosis does not, as far as I can tell, have that delegation
> capability, but I've come up with a way to do this:
>
> 1. Use git-shell. Yes, this does involve creating one shell account
> for each project, but git-shell is, by design, very short on
> exploitable capability.
>
> 2. Make the .ssh directory a git repository.
>
> 3. Edit .ssh/authorized_keys and push via git.

I was looking into being able to do it using gitosis, with an interface
on top of it's existing GIT repository for being able to delegate this.
I think it can be done without modifying gitosis itself, by just writing
some simple frontend script on top of it. What do you think of this idea?

//Magnus

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

[SQL] Verify Execute

Hello
 
Is there a way to find out if the EXECUTE of a UPDATE, INSERT has been completed successfully?
 
Here is an example of what I do:
 
Set conn = Server.CreateObject("ADODB.Connection")
conn.Open "Form_Store_PSQL"
 
Set oRs = Server.CreateObject("ADODB.Recordset" )
strSQL = "INSERT INTO TABLE_TEMP (ID) VALUES ('1')"
conn.Execute strSQL
 
Thank you
 
Shavonne Wijesinghe

[GENERAL] could not select a suitable default timezone on Initdb, 8.3.3, Windows 2008 x64

Initdb throws "could not select a suitable default timezone" on PostgreSQL
8.3.3
and Windows x64.

We'd like to use those settings --lc-collate=C --lc-ctype=French_Canada
pginstaller does initdb properly but not with the parameters we want.

We want upper, lower, regex, ... to process acccented characters properly
but don't care
about the collating sequence of those accented characters.

We have many indexes of varchar columns and want to avoid having both
regular indexes
and index with *_pattern_ops.

we first install PostgreSQL with pgInstaller and no initdb

we then issue:
initdb -d --pgdata="C:/Program Files (x86)/PostgreSQL/8.3/data"
--encoding=WIN1252 --lc-collate=C --lc-ctype=French_Canada --pwprompt -L
"C:/Program Files (x86)/PostgreSQL/8.3/share"

creating template1 database in C:/Program Files
(x86)/PostgreSQL/8.3/data/base/1 ...
DEBUG: TZ "US/Eastern" matches Windows timezone "Eastern Daylight Time"
LOG: could not open directory "/share/timezone": No such file or directory
LOG: could not open directory "/share/timezone": No such file or directory
FATAL: could not select a suitable default timezone
DETAIL: It appears that your GMT time zone uses leap seconds. PostgreSQL
does not support leap seconds.
DEBUG: proc_exit(1)
DEBUG: shmem_exit(1)
DEBUG: exit(1)
child process exited with exit code 1

We tried putting a copy of C:/Program Files (x86)/PostgreSQL/8.3/share in
c:/share
to get a little bit further and got this fatal error:

creating conversions ...
FATAL: could not access file "$libdir/ascii_and_mic": No such file or
directory
STATEMENT: CREATE OR REPLACE FUNCTION ascii_to_mic (INTEGER, INTEGER,
CSTRING, INTERNAL, INTEGER)
RETURNS VOID AS '$libdir/ascii_and_mic', 'ascii_to_mic' LANGUAGE C STRICT;
child process exited with exit code 1

The file ascii_and_mic.dll does exist in C:/Program Files
(x86)/PostgreSQL/8.3/lib

Thanks,
Jean-Pierre Pelletier
e-djuster

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

Re: [PATCHES] variadic function support

*** ./doc/src/sgml/ref/create_function.sgml.orig 2008-06-24 16:46:47.000000000 +0200
--- ./doc/src/sgml/ref/create_function.sgml 2008-06-24 16:47:46.000000000 +0200
***************
*** 102,108 ****
<listitem>
<para>
The mode of an argument: either <literal>IN</>, <literal>OUT</>,
! or <literal>INOUT</>. If omitted, the default is <literal>IN</>.
</para>
</listitem>
</varlistentry>
--- 102,109 ----
<listitem>
<para>
The mode of an argument: either <literal>IN</>, <literal>OUT</>,
! <literal>INOUT</> or <literal>VARIADIC</literal>. If omitted,
! the default is <literal>IN</>.
</para>
</listitem>
</varlistentry>
*** ./doc/src/sgml/xfunc.sgml.orig 2008-06-24 16:53:58.000000000 +0200
--- ./doc/src/sgml/xfunc.sgml 2008-06-24 16:59:42.000000000 +0200
***************
*** 578,584 ****

<para>
Parameters can be marked as <literal>IN</> (the default),
! <literal>OUT</>, or <literal>INOUT</>. An <literal>INOUT</>
parameter serves as both an input parameter (part of the calling
argument list) and an output parameter (part of the result record type).
</para>
--- 578,585 ----

<para>
Parameters can be marked as <literal>IN</> (the default),
! <literal>OUT</>, <literal>INOUT</>, or <literal>VARIADIC</literal>.
! An <literal>INOUT</>
parameter serves as both an input parameter (part of the calling
argument list) and an output parameter (part of the result record type).
</para>
***************
*** 805,810 ****
--- 806,833 ----
</screen>
</para>
</sect2>
+
+ <sect2>
+ <title>Variadic <acronym>SQL</acronym> Functions</title>
+
+ <para>
+ <acronym>SQL</acronym> functions can be declared to accept
+ variable number of arguments.
+ <screen>
+ CREATE FUNCTION mleast(variadic numeric[]) RETURNS numeric AS $$
+ SELECT min($1[i])
+ FROM generate_subscripts($1,1) g(i);
+ $$ LANGUAGE SQL;
+
+ SELECT mleast(10, -1, 5, 4);
+ mleast
+ --------
+ -1
+ (1 row)
+ </screen>
+ </para>
+ </sect2>
+
</sect1>

<sect1 id="xfunc-overload">
*** ./src/backend/catalog/namespace.c.orig 2008-06-24 11:24:34.000000000 +0200
--- ./src/backend/catalog/namespace.c 2008-06-24 13:58:31.000000000 +0200
***************
*** 570,576 ****
* identical entries in later namespaces.
*/
FuncCandidateList
! FuncnameGetCandidates(List *names, int nargs)
{
FuncCandidateList resultList = NULL;
char *schemaname;
--- 570,576 ----
* identical entries in later namespaces.
*/
FuncCandidateList
! FuncnameGetCandidates(List *names, int nargs, bool transform_variadic)
{
FuncCandidateList resultList = NULL;
char *schemaname;
***************
*** 606,614 ****
int pronargs = procform->pronargs;
int pathpos = 0;
FuncCandidateList newResult;

/* Ignore if it doesn't match requested argument count */
! if (nargs >= 0 && pronargs != nargs)
continue;

if (OidIsValid(namespaceId))
--- 606,655 ----
int pronargs = procform->pronargs;
int pathpos = 0;
FuncCandidateList newResult;
+ Oid va_oid = InvalidOid;
+ bool variadic = false;
+ bool isnull;
+ Datum proargmodes;
+
+ /*
+ * Search type of variadic argument,
+ */
+ proargmodes = SysCacheGetAttr(PROCOID, proctup,
+ Anum_pg_proc_proargmodes, &isnull);
+ if (!isnull)
+ {
+ ArrayType *ar = DatumGetArrayTypeP(proargmodes);
+ char *argmodes;
+ int j;
+
+ argmodes = ARR_DATA_PTR(ar);
+ for (j = 0; j < ARR_DIMS(ar)[0]; j++)
+ if (argmodes[j] == PROARGMODE_VARIADIC)
+ {
+ variadic = true;
+ switch (procform->proargtypes.values[j])
+ {
+ case ANYOID:
+ va_oid = ANYOID;
+ break;
+ case ANYARRAYOID:
+ va_oid = ANYELEMENTOID;
+ break;
+ default:
+ va_oid = get_element_type(procform->proargtypes.values[j]);
+ Assert(OidIsValid(va_oid));
+ }
+
+ break;
+ }
+ }

/* Ignore if it doesn't match requested argument count */
! if (nargs >= 0 && pronargs != nargs && !variadic)
! continue;
!
! /* Ignore variadic function with less arguments */
! if (nargs >= 0 && pronargs > nargs && variadic)
continue;

if (OidIsValid(namespaceId))
***************
*** 691,706 ****
/*
* Okay to add it to result list
*/
! newResult = (FuncCandidateList)
! palloc(sizeof(struct _FuncCandidateList) - sizeof(Oid)
! + pronargs * sizeof(Oid));
newResult->pathpos = pathpos;
newResult->oid = HeapTupleGetOid(proctup);
- newResult->nargs = pronargs;
- memcpy(newResult->args, procform->proargtypes.values,
- pronargs * sizeof(Oid));
-
newResult->next = resultList;
resultList = newResult;
}

--- 732,772 ----
/*
* Okay to add it to result list
*/
! if (variadic && transform_variadic)
! {
! int i;
!
! Assert(nargs >= pronargs);
!
! newResult = (FuncCandidateList)
! palloc(sizeof(struct _FuncCandidateList) - sizeof(Oid)
! + nargs * sizeof(Oid));
! newResult->nargs = nargs;
! newResult->nvargs = nargs - pronargs + 1;
! newResult->variadic_oid = va_oid;
! memcpy(newResult->args, procform->proargtypes.values,
! (pronargs - 1) * sizeof(Oid));
!
! /* Multiply variadic argument */
! for (i = pronargs - 1; i < nargs; i++)
! newResult->args[i] = va_oid;
! }
! else
! {
! newResult = (FuncCandidateList)
! palloc(sizeof(struct _FuncCandidateList) - sizeof(Oid)
! + pronargs * sizeof(Oid));
! newResult->nargs = pronargs;
! newResult->nvargs = 0;
! newResult->variadic_oid = 0;
! memcpy(newResult->args, procform->proargtypes.values,
! pronargs * sizeof(Oid));
! }
!
newResult->pathpos = pathpos;
newResult->oid = HeapTupleGetOid(proctup);
newResult->next = resultList;
+
resultList = newResult;
}

***************
*** 755,761 ****

visible = false;

! clist = FuncnameGetCandidates(list_make1(makeString(proname)), nargs);

for (; clist; clist = clist->next)
{
--- 821,827 ----

visible = false;

! clist = FuncnameGetCandidates(list_make1(makeString(proname)), nargs, false);

for (; clist; clist = clist->next)
{
*** ./src/backend/catalog/pg_aggregate.c.orig 2008-06-24 14:17:42.000000000 +0200
--- ./src/backend/catalog/pg_aggregate.c 2008-06-24 15:58:27.000000000 +0200
***************
*** 297,302 ****
--- 297,304 ----
FuncDetailCode fdresult;
AclResult aclresult;
int i;
+ int nvargs;
+ Oid va_oid;

/*
* func_get_detail looks up the function in the catalogs, does
***************
*** 307,313 ****
*/
fdresult = func_get_detail(fnName, NIL, nargs, input_types,
&fnOid, rettype, &retset,
! &true_oid_array);

/* only valid case is a normal function not returning a set */
if (fdresult != FUNCDETAIL_NORMAL || !OidIsValid(fnOid))
--- 309,316 ----
*/
fdresult = func_get_detail(fnName, NIL, nargs, input_types,
&fnOid, rettype, &retset,
! &true_oid_array,
! &nvargs, &va_oid);

/* only valid case is a normal function not returning a set */
if (fdresult != FUNCDETAIL_NORMAL || !OidIsValid(fnOid))
***************
*** 321,326 ****
--- 324,334 ----
errmsg("function %s returns a set",
func_signature_string(fnName, nargs, input_types))));

+ if (nvargs > 0)
+ ereport(ERROR,
+ (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+ errmsg("aggregate function has variadic argument %d %d", nvargs, va_oid)));
+
/*
* If there are any polymorphic types involved, enforce consistency, and
* possibly refine the result type. It's OK if the result is still
*** ./src/backend/commands/functioncmds.c.orig 2008-06-24 10:36:44.000000000 +0200
--- ./src/backend/commands/functioncmds.c 2008-06-24 12:37:26.000000000 +0200
***************
*** 173,178 ****
--- 173,179 ----
Datum *paramNames;
int outCount = 0;
bool have_names = false;
+ int varCount = 0;
ListCell *x;
int i;

***************
*** 227,241 ****
errmsg("functions cannot accept set arguments")));

if (fp->mode != FUNC_PARAM_OUT)
inTypes[inCount++] = toid;

! if (fp->mode != FUNC_PARAM_IN)
{
if (outCount == 0) /* save first OUT param's type */
*requiredResultType = toid;
outCount++;
}

allTypes[i] = ObjectIdGetDatum(toid);

paramModes[i] = CharGetDatum(fp->mode);
--- 228,270 ----
errmsg("functions cannot accept set arguments")));

if (fp->mode != FUNC_PARAM_OUT)
+ {
inTypes[inCount++] = toid;
+ /* check if variadic argument is last IN argument */
+ if (varCount > 0 && fp->mode != FUNC_PARAM_OUT)
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_FUNCTION_DEFINITION),
+ errmsg("variadic argument isn't last function's argument")));
+ }

! if (fp->mode != FUNC_PARAM_IN && fp->mode != FUNC_PARAM_VARIADIC)
{
if (outCount == 0) /* save first OUT param's type */
*requiredResultType = toid;
outCount++;
}

+ if (fp->mode == FUNC_PARAM_VARIADIC)
+ {
+ if (varCount++ > 0)
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_FUNCTION_DEFINITION),
+ errmsg("function cannot accept two or more variadic arguments")));
+
+ /* check variadic parameter type */
+ switch (toid)
+ {
+ case ANYARRAYOID:
+ case ANYOID:
+ break;
+ default:
+ if (!OidIsValid(get_element_type(toid)))
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_FUNCTION_DEFINITION),
+ errmsg("variadic argument isn't array")));
+ }
+ }
+
allTypes[i] = ObjectIdGetDatum(toid);

paramModes[i] = CharGetDatum(fp->mode);
***************
*** 252,258 ****
/* Now construct the proper outputs as needed */
*parameterTypes = buildoidvector(inTypes, inCount);

! if (outCount > 0)
{
*allParameterTypes = construct_array(allTypes, parameterCount, OIDOID,
sizeof(Oid), true, 'i');
--- 281,287 ----
/* Now construct the proper outputs as needed */
*parameterTypes = buildoidvector(inTypes, inCount);

! if (outCount > 0 || varCount > 0)
{
*allParameterTypes = construct_array(allTypes, parameterCount, OIDOID,
sizeof(Oid), true, 'i');
*** ./src/backend/parser/gram.y.orig 2008-06-24 10:30:01.000000000 +0200
--- ./src/backend/parser/gram.y 2008-06-24 10:32:36.000000000 +0200
***************
*** 444,450 ****
UNCOMMITTED UNENCRYPTED UNION UNIQUE UNKNOWN UNLISTEN UNTIL
UPDATE USER USING

! VACUUM VALID VALIDATOR VALUE_P VALUES VARCHAR VARYING
VERBOSE VERSION_P VIEW VOLATILE

WHEN WHERE WHITESPACE_P WITH WITHOUT WORK WRITE
--- 444,450 ----
UNCOMMITTED UNENCRYPTED UNION UNIQUE UNKNOWN UNLISTEN UNTIL
UPDATE USER USING

! VACUUM VALID VALIDATOR VALUE_P VALUES VARCHAR VARIADIC VARYING
VERBOSE VERSION_P VIEW VOLATILE

WHEN WHERE WHITESPACE_P WITH WITHOUT WORK WRITE
***************
*** 4204,4209 ****
--- 4204,4210 ----
| OUT_P { $$ = FUNC_PARAM_OUT; }
| INOUT { $$ = FUNC_PARAM_INOUT; }
| IN_P OUT_P { $$ = FUNC_PARAM_INOUT; }
+ | VARIADIC { $$ = FUNC_PARAM_VARIADIC; }
;

/*
*** ./src/backend/parser/keywords.c.orig 2008-06-24 10:29:58.000000000 +0200
--- ./src/backend/parser/keywords.c 2008-06-24 10:30:50.000000000 +0200
***************
*** 393,398 ****
--- 393,399 ----
{"value", VALUE_P, UNRESERVED_KEYWORD},
{"values", VALUES, COL_NAME_KEYWORD},
{"varchar", VARCHAR, COL_NAME_KEYWORD},
+ {"variadic", VARIADIC, UNRESERVED_KEYWORD},
{"varying", VARYING, UNRESERVED_KEYWORD},
{"verbose", VERBOSE, TYPE_FUNC_NAME_KEYWORD},
{"version", VERSION_P, UNRESERVED_KEYWORD},
*** ./src/backend/parser/parse_func.c.orig 2008-06-24 13:09:17.000000000 +0200
--- ./src/backend/parser/parse_func.c 2008-06-24 15:58:44.000000000 +0200
***************
*** 76,81 ****
--- 76,83 ----
Node *retval;
bool retset;
FuncDetailCode fdresult;
+ int nvargs;
+ Oid va_oid;

/*
* Most of the rest of the parser just assumes that functions do not have
***************
*** 158,164 ****
*/
fdresult = func_get_detail(funcname, fargs, nargs, actual_arg_types,
&funcid, &rettype, &retset,
! &declared_arg_types);
if (fdresult == FUNCDETAIL_COERCION)
{
/*
--- 160,167 ----
*/
fdresult = func_get_detail(funcname, fargs, nargs, actual_arg_types,
&funcid, &rettype, &retset,
! &declared_arg_types,
! &nvargs, &va_oid);
if (fdresult == FUNCDETAIL_COERCION)
{
/*
***************
*** 229,234 ****
--- 232,279 ----
}

/*
+ * Last nvargs arguments are transformed to array when function is
+ * non "any" variadic.
+ */
+ if (nvargs> 0 && va_oid != ANYOID)
+ {
+ A_ArrayExpr *n = makeNode(A_ArrayExpr);
+ Node *tn;
+
+ if (nvargs < nargs)
+ {
+ int non_var_args = nargs - nvargs;
+ List *vargs;
+
+ vargs = list_copy_tail(fargs, non_var_args);
+ fargs = list_truncate(fargs, non_var_args);
+ n->elements = vargs;
+ tn = transformExpr(pstate, (Node *) n);
+ fargs = lappend(fargs, tn);
+ }
+ else
+ {
+ /* array from all argumenst */
+ n->elements = fargs;
+ tn= transformExpr(pstate, (Node *) n);
+ fargs = list_make1(tn);
+ }
+
+ /*
+ * Now we have to correct argument's metadata used in
+ * enforce_generic_type_consistency and make_fn_arguments. These
+ * functions needs actual values of nargs, actual_arg_types and
+ * real_arg_types.
+ */
+ nargs = nargs - nvargs + 1;
+ actual_arg_types[nargs - 1] = ((ArrayExpr *) tn)->array_typeid;
+ if (va_oid != ANYELEMENTOID)
+ declared_arg_types[nargs - 1] = get_array_type(va_oid);
+ else
+ declared_arg_types[nargs - 1] = ANYARRAYOID;
+ }
+
+ /*
* enforce consistency with polymorphic argument and return types,
* possibly adjusting return type or declared_arg_types (which will be
* used as the cast destination by make_fn_arguments)
***************
*** 697,709 ****
Oid *funcid, /* return value */
Oid *rettype, /* return value */
bool *retset, /* return value */
! Oid **true_typeids) /* return value */
{
FuncCandidateList raw_candidates;
FuncCandidateList best_candidate;

/* Get list of possible candidates from namespace search */
! raw_candidates = FuncnameGetCandidates(funcname, nargs);

/*
* Quickly check if there is an exact match to the input datatypes (there
--- 742,756 ----
Oid *funcid, /* return value */
Oid *rettype, /* return value */
bool *retset, /* return value */
! Oid **true_typeids, /* return value */
! int *nvargs, /* return value */
! Oid *va_oid) /* return value */
{
FuncCandidateList raw_candidates;
FuncCandidateList best_candidate;

/* Get list of possible candidates from namespace search */
! raw_candidates = FuncnameGetCandidates(funcname, nargs, true);

/*
* Quickly check if there is an exact match to the input datatypes (there
***************
*** 787,792 ****
--- 834,841 ----
*rettype = targetType;
*retset = false;
*true_typeids = argtypes;
+ *nvargs = 0;
+ *va_oid = InvalidOid;
return FUNCDETAIL_COERCION;
}
}
***************
*** 836,841 ****
--- 885,892 ----

*funcid = best_candidate->oid;
*true_typeids = best_candidate->args;
+ *nvargs = best_candidate->nvargs;
+ *va_oid = best_candidate->variadic_oid;

ftup = SearchSysCache(PROCOID,
ObjectIdGetDatum(best_candidate->oid),
***************
*** 1189,1195 ****
{
FuncCandidateList clist;

! clist = FuncnameGetCandidates(funcname, nargs);

while (clist)
{
--- 1240,1246 ----
{
FuncCandidateList clist;

! clist = FuncnameGetCandidates(funcname, nargs, false);

while (clist)
{
*** ./src/backend/utils/adt/regproc.c.orig 2008-06-24 13:12:03.000000000 +0200
--- ./src/backend/utils/adt/regproc.c 2008-06-24 13:12:53.000000000 +0200
***************
*** 131,137 ****
* pg_proc entries in the current search path.
*/
names = stringToQualifiedNameList(pro_name_or_oid);
! clist = FuncnameGetCandidates(names, -1);

if (clist == NULL)
ereport(ERROR,
--- 131,137 ----
* pg_proc entries in the current search path.
*/
names = stringToQualifiedNameList(pro_name_or_oid);
! clist = FuncnameGetCandidates(names, -1, false);

if (clist == NULL)
ereport(ERROR,
***************
*** 189,195 ****
* Would this proc be found (uniquely!) by regprocin? If not,
* qualify it.
*/
! clist = FuncnameGetCandidates(list_make1(makeString(proname)), -1);
if (clist != NULL && clist->next == NULL &&
clist->oid == proid)
nspname = NULL;
--- 189,195 ----
* Would this proc be found (uniquely!) by regprocin? If not,
* qualify it.
*/
! clist = FuncnameGetCandidates(list_make1(makeString(proname)), -1, false);
if (clist != NULL && clist->next == NULL &&
clist->oid == proid)
nspname = NULL;
***************
*** 276,282 ****
*/
parseNameAndArgTypes(pro_name_or_oid, false, &names, &nargs, argtypes);

! clist = FuncnameGetCandidates(names, nargs);

for (; clist; clist = clist->next)
{
--- 276,282 ----
*/
parseNameAndArgTypes(pro_name_or_oid, false, &names, &nargs, argtypes);

! clist = FuncnameGetCandidates(names, nargs, false);

for (; clist; clist = clist->next)
{
*** ./src/backend/utils/adt/ruleutils.c.orig 2008-06-24 14:37:19.000000000 +0200
--- ./src/backend/utils/adt/ruleutils.c 2008-06-24 14:38:28.000000000 +0200
***************
*** 5344,5349 ****
--- 5344,5351 ----
Oid p_rettype;
bool p_retset;
Oid *p_true_typeids;
+ int nvargs;
+ Oid va_oid;

proctup = SearchSysCache(PROCOID,
ObjectIdGetDatum(funcid),
***************
*** 5362,5368 ****
p_result = func_get_detail(list_make1(makeString(proname)),
NIL, nargs, argtypes,
&p_funcid, &p_rettype,
! &p_retset, &p_true_typeids);
if ((p_result == FUNCDETAIL_NORMAL || p_result == FUNCDETAIL_AGGREGATE) &&
p_funcid == funcid)
nspname = NULL;
--- 5364,5371 ----
p_result = func_get_detail(list_make1(makeString(proname)),
NIL, nargs, argtypes,
&p_funcid, &p_rettype,
! &p_retset, &p_true_typeids,
! &nvargs, &va_oid);
if ((p_result == FUNCDETAIL_NORMAL || p_result == FUNCDETAIL_AGGREGATE) &&
p_funcid == funcid)
nspname = NULL;
*** ./src/backend/utils/fmgr/funcapi.c.orig 2008-06-24 16:18:51.000000000 +0200
--- ./src/backend/utils/fmgr/funcapi.c 2008-06-24 16:21:54.000000000 +0200
***************
*** 844,850 ****
numoutargs = 0;
for (i = 0; i < numargs; i++)
{
! if (argmodes[i] == PROARGMODE_IN)
continue;
Assert(argmodes[i] == PROARGMODE_OUT ||
argmodes[i] == PROARGMODE_INOUT);
--- 844,850 ----
numoutargs = 0;
for (i = 0; i < numargs; i++)
{
! if (argmodes[i] == PROARGMODE_IN || argmodes[i] == PROARGMODE_VARIADIC)
continue;
Assert(argmodes[i] == PROARGMODE_OUT ||
argmodes[i] == PROARGMODE_INOUT);
***************
*** 994,1000 ****
{
char *pname;

! if (argmodes[i] == PROARGMODE_IN)
continue;
Assert(argmodes[i] == PROARGMODE_OUT ||
argmodes[i] == PROARGMODE_INOUT);
--- 994,1000 ----
{
char *pname;

! if (argmodes[i] == PROARGMODE_IN || argmodes[i] == PROARGMODE_VARIADIC)
continue;
Assert(argmodes[i] == PROARGMODE_OUT ||
argmodes[i] == PROARGMODE_INOUT);
*** ./src/bin/pg_dump/pg_dump.c.orig 2008-06-24 15:05:21.000000000 +0200
--- ./src/bin/pg_dump/pg_dump.c 2008-06-24 15:09:08.000000000 +0200
***************
*** 6435,6449 ****
{
switch (argmodes[j][0])
{
! case 'i':
argmode = "";
break;
! case 'o':
argmode = "OUT ";
break;
! case 'b':
argmode = "INOUT ";
break;
default:
write_msg(NULL, "WARNING: bogus value in proargmodes array\n");
argmode = "";
--- 6435,6452 ----
{
switch (argmodes[j][0])
{
! case PROARGMODE_IN:
argmode = "";
break;
! case PROARGMODE_OUT:
argmode = "OUT ";
break;
! case PROARGMODE_INOUT:
argmode = "INOUT ";
break;
+ case PROARGMODE_VARIADIC:
+ argmode = "VARIADIC ";
+ break;
default:
write_msg(NULL, "WARNING: bogus value in proargmodes array\n");
argmode = "";
*** ./src/bin/psql/describe.c.orig 2008-06-24 15:17:23.000000000 +0200
--- ./src/bin/psql/describe.c 2008-06-24 15:18:26.000000000 +0200
***************
*** 187,192 ****
--- 187,193 ----
" WHEN p.proargmodes[s.i] = 'i' THEN ''\n"
" WHEN p.proargmodes[s.i] = 'o' THEN 'OUT '\n"
" WHEN p.proargmodes[s.i] = 'b' THEN 'INOUT '\n"
+ " WHEN p.proargmodes[s.i] = 'v' THEN 'VARIADIC '\n"
" END ||\n"
" CASE\n"
" WHEN COALESCE(p.proargnames[s.i], '') = '' THEN ''\n"
*** ./src/include/catalog/namespace.h.orig 2008-06-24 12:48:23.000000000 +0200
--- ./src/include/catalog/namespace.h 2008-06-24 12:59:36.000000000 +0200
***************
*** 29,34 ****
--- 29,36 ----
int pathpos; /* for internal use of namespace lookup */
Oid oid; /* the function or operator's OID */
int nargs; /* number of arg types returned */
+ int nvargs; /* number of variadic arguments */
+ Oid variadic_oid; /* Oid of variadic argument */
Oid args[1]; /* arg types --- VARIABLE LENGTH ARRAY */
} *FuncCandidateList; /* VARIABLE LENGTH STRUCT */

***************
*** 51,57 ****
extern Oid TypenameGetTypid(const char *typname);
extern bool TypeIsVisible(Oid typid);

! extern FuncCandidateList FuncnameGetCandidates(List *names, int nargs);
extern bool FunctionIsVisible(Oid funcid);

extern Oid OpernameGetOprid(List *names, Oid oprleft, Oid oprright);
--- 53,60 ----
extern Oid TypenameGetTypid(const char *typname);
extern bool TypeIsVisible(Oid typid);

! extern FuncCandidateList FuncnameGetCandidates(List *names, int nargs,
! bool transform_variadic);
extern bool FunctionIsVisible(Oid funcid);

extern Oid OpernameGetOprid(List *names, Oid oprleft, Oid oprright);
*** ./src/include/catalog/pg_proc.h.orig 2008-06-24 13:33:45.000000000 +0200
--- ./src/include/catalog/pg_proc.h 2008-06-24 13:33:24.000000000 +0200
***************
*** 4466,4470 ****
--- 4466,4471 ----
#define PROARGMODE_IN 'i'
#define PROARGMODE_OUT 'o'
#define PROARGMODE_INOUT 'b'
+ #define PROARGMODE_VARIADIC 'v'

#endif /* PG_PROC_H */
*** ./src/include/nodes/parsenodes.h.orig 2008-06-24 10:35:02.000000000 +0200
--- ./src/include/nodes/parsenodes.h 2008-06-24 10:35:09.000000000 +0200
***************
*** 1568,1574 ****
/* the assigned enum values appear in pg_proc, don't change 'em! */
FUNC_PARAM_IN = 'i', /* input only */
FUNC_PARAM_OUT = 'o', /* output only */
! FUNC_PARAM_INOUT = 'b' /* both */
} FunctionParameterMode;

typedef struct FunctionParameter
--- 1568,1575 ----
/* the assigned enum values appear in pg_proc, don't change 'em! */
FUNC_PARAM_IN = 'i', /* input only */
FUNC_PARAM_OUT = 'o', /* output only */
! FUNC_PARAM_INOUT = 'b', /* both */
! FUNC_PARAM_VARIADIC = 'v' /* variadic */
} FunctionParameterMode;

typedef struct FunctionParameter
*** ./src/include/parser/parse_func.h.orig 2008-06-24 14:16:40.000000000 +0200
--- ./src/include/parser/parse_func.h 2008-06-24 14:17:13.000000000 +0200
***************
*** 49,55 ****
extern FuncDetailCode func_get_detail(List *funcname, List *fargs,
int nargs, Oid *argtypes,
Oid *funcid, Oid *rettype,
! bool *retset, Oid **true_typeids);

extern int func_match_argtypes(int nargs,
Oid *input_typeids,
--- 49,56 ----
extern FuncDetailCode func_get_detail(List *funcname, List *fargs,
int nargs, Oid *argtypes,
Oid *funcid, Oid *rettype,
! bool *retset, Oid **true_typeids,
! int *nvargs, Oid *va_oid);

extern int func_match_argtypes(int nargs,
Oid *input_typeids,
*** ./src/interfaces/ecpg/preproc/preproc.y.orig 2008-06-24 11:12:00.000000000 +0200
--- ./src/interfaces/ecpg/preproc/preproc.y 2008-06-24 11:13:52.000000000 +0200
***************
*** 489,495 ****
UNCOMMITTED UNENCRYPTED UNION UNIQUE UNKNOWN UNLISTEN UNTIL
UPDATE USER USING

! VACUUM VALID VALIDATOR VALUE_P VALUES VARCHAR VARYING
VERBOSE VERSION_P VIEW VOLATILE
WHEN WHERE WHITESPACE_P WITH WITHOUT WORK WRITE

--- 489,495 ----
UNCOMMITTED UNENCRYPTED UNION UNIQUE UNKNOWN UNLISTEN UNTIL
UPDATE USER USING

! VACUUM VALID VALIDATOR VALUE_P VALUES VARCHAR VARIADIC VARYING
VERBOSE VERSION_P VIEW VOLATILE
WHEN WHERE WHITESPACE_P WITH WITHOUT WORK WRITE

***************
*** 6668,6673 ****
--- 6668,6674 ----
| VALIDATOR { $$ = make_str("validator"); }
| VALUE_P { $$ = make_str("value"); }
| VARYING { $$ = make_str("varying"); }
+ | VARIADIC { $$ = make_str("variadic"); }
| VERSION_P { $$ = make_str("version"); }
| VIEW { $$ = make_str("view"); }
| VOLATILE { $$ = make_str("volatile"); }
*** ./src/pl/plpgsql/src/pl_comp.c.orig 2008-06-24 16:23:47.000000000 +0200
--- ./src/pl/plpgsql/src/pl_comp.c 2008-06-24 16:25:53.000000000 +0200
***************
*** 426,432 ****
{
argitemtype = PLPGSQL_NSTYPE_VAR;
/* input argument vars are forced to be CONSTANT */
! if (argmode == PROARGMODE_IN)
((PLpgSQL_var *) argvariable)->isconst = true;
}
else
--- 426,432 ----
{
argitemtype = PLPGSQL_NSTYPE_VAR;
/* input argument vars are forced to be CONSTANT */
! if (argmode == PROARGMODE_IN || argmode == PROARGMODE_VARIADIC)
((PLpgSQL_var *) argvariable)->isconst = true;
}
else
***************
*** 436,442 ****
}

/* Remember arguments in appropriate arrays */
! if (argmode == PROARGMODE_IN || argmode == PROARGMODE_INOUT)
in_arg_varnos[num_in_args++] = argvariable->dno;
if (argmode == PROARGMODE_OUT || argmode == PROARGMODE_INOUT)
out_arg_variables[num_out_args++] = argvariable;
--- 436,443 ----
}

/* Remember arguments in appropriate arrays */
! if (argmode == PROARGMODE_IN || argmode == PROARGMODE_INOUT
! || argmode == PROARGMODE_VARIADIC)
in_arg_varnos[num_in_args++] = argvariable->dno;
if (argmode == PROARGMODE_OUT || argmode == PROARGMODE_INOUT)
out_arg_variables[num_out_args++] = argvariable;
*** ./src/test/regress/expected/plpgsql.out.orig 2008-06-24 16:33:20.000000000 +0200
--- ./src/test/regress/expected/plpgsql.out 2008-06-24 16:32:32.000000000 +0200
***************
*** 3544,3546 ****
--- 3544,3611 ----

drop function catch();
drop function case_test(bigint);
+ -- variadic fuction test
+ create or replace function vari(variadic int[])
+ returns void as $$
+ begin
+ for i in array_lower($1,1)..array_upper($1,1) loop
+ raise notice '%', $1[i];
+ end loop; end;
+ $$ language plpgsql;
+ select vari(1,2,3,4,5);
+ NOTICE: 1
+ NOTICE: 2
+ NOTICE: 3
+ NOTICE: 4
+ NOTICE: 5
+ vari
+ ------
+
+ (1 row)
+
+ select vari(3,4,5);
+ NOTICE: 3
+ NOTICE: 4
+ NOTICE: 5
+ vari
+ ------
+
+ (1 row)
+
+ drop function vari(int[]);
+ -- coerce test
+ create or replace function pleast(variadic numeric[])
+ returns numeric as $$
+ declare aux numeric = $1[array_lower($1,1)];
+ begin
+ for i in array_lower($1,1)+1..array_upper($1,1) loop
+ if $1[i] < aux then aux := $1[i]; end if;
+ end loop;
+ return aux;
+ end;
+ $$ language plpgsql immutable strict;
+ select pleast(10,1,2,3,-16);
+ pleast
+ --------
+ -16
+ (1 row)
+
+ select pleast(10.2,2.2,-1.1);
+ pleast
+ --------
+ -1.1
+ (1 row)
+
+ select pleast(10.2,10, -20);
+ pleast
+ --------
+ -20
+ (1 row)
+
+ select pleast(10,20, -1.0);
+ pleast
+ --------
+ -1.0
+ (1 row)
+
+ drop function pleast(numeric[]);
*** ./src/test/regress/expected/polymorphism.out.orig 2008-06-24 16:10:52.000000000 +0200
--- ./src/test/regress/expected/polymorphism.out 2008-06-24 16:07:12.000000000 +0200
***************
*** 613,615 ****
--- 613,658 ----
SFUNC = add_group,
STYPE = int8[]
);
+ --test for variadic polymorphic function
+ create function myleast(variadic anyarray)
+ returns anyelement as $$
+ select min($1[i])
+ from generate_subscripts($1,1) g(i)
+ $$ language sql immutable strict;
+ select myleast(10, 1, 20, 33);
+ myleast
+ ---------
+ 1
+ (1 row)
+
+ select myleast(1.1, 0.22, 0.55);
+ myleast
+ ---------
+ 0.22
+ (1 row)
+
+ -- visibility test
+ select pg_catalog.pg_function_is_visible('myleast(anyarray)'::regprocedure::int);
+ pg_function_is_visible
+ ------------------------
+ t
+ (1 row)
+
+ drop function myleast(anyarray);
+ create or replace function concat(varchar, variadic anyarray)
+ returns varchar as $$
+ select array_to_string($2, $1);
+ $$ language sql immutable strict;
+ select concat('%', 1, 2, 3, 4, 5);
+ concat
+ -----------
+ 1%2%3%4%5
+ (1 row)
+
+ select concat('|', 'a'::text, 'b', 'c');
+ concat
+ --------
+ a|b|c
+ (1 row)
+
+ drop function concat(varchar, anyarray);
*** ./src/test/regress/sql/plpgsql.sql.orig 2008-06-24 16:01:55.000000000 +0200
--- ./src/test/regress/sql/plpgsql.sql 2008-06-24 16:30:50.000000000 +0200
***************
*** 2878,2880 ****
--- 2878,2913 ----

drop function catch();
drop function case_test(bigint);
+
+ -- variadic fuction test
+ create or replace function vari(variadic int[])
+ returns void as $$
+ begin
+ for i in array_lower($1,1)..array_upper($1,1) loop
+ raise notice '%', $1[i];
+ end loop; end;
+ $$ language plpgsql;
+
+ select vari(1,2,3,4,5);
+ select vari(3,4,5);
+
+ drop function vari(int[]);
+
+ -- coerce test
+ create or replace function pleast(variadic numeric[])
+ returns numeric as $$
+ declare aux numeric = $1[array_lower($1,1)];
+ begin
+ for i in array_lower($1,1)+1..array_upper($1,1) loop
+ if $1[i] < aux then aux := $1[i]; end if;
+ end loop;
+ return aux;
+ end;
+ $$ language plpgsql immutable strict;
+
+ select pleast(10,1,2,3,-16);
+ select pleast(10.2,2.2,-1.1);
+ select pleast(10.2,10, -20);
+ select pleast(10,20, -1.0);
+
+ drop function pleast(numeric[]);
*** ./src/test/regress/sql/polymorphism.sql.orig 2008-06-24 16:01:52.000000000 +0200
--- ./src/test/regress/sql/polymorphism.sql 2008-06-24 16:04:16.000000000 +0200
***************
*** 426,428 ****
--- 426,453 ----
SFUNC = add_group,
STYPE = int8[]
);
+
+ --test for variadic polymorphic function
+ create function myleast(variadic anyarray)
+ returns anyelement as $$
+ select min($1[i])
+ from generate_subscripts($1,1) g(i)
+ $$ language sql immutable strict;
+
+ select myleast(10, 1, 20, 33);
+ select myleast(1.1, 0.22, 0.55);
+ -- visibility test
+ select pg_catalog.pg_function_is_visible('myleast(anyarray)'::regprocedure::int);
+
+ drop function myleast(anyarray);
+
+ create or replace function concat(varchar, variadic anyarray)
+ returns varchar as $$
+ select array_to_string($2, $1);
+ $$ language sql immutable strict;
+
+ select concat('%', 1, 2, 3, 4, 5);
+ select concat('|', 'a'::text, 'b', 'c');
+
+ drop function concat(varchar, anyarray);
+
Hello

this version implements syntax based on argmodes.


CREATE FUNCTION mleast(variadic numeric[]) RETURNS numeric AS $$
SELECT min($1[i])
FROM generate_subscripts($1,1) g(i);
$$ LANGUAGE SQL;

Regards
Pavel Stehule

2008/6/24 Tom Lane <tgl@sss.pgh.pa.us>:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> But if I have
>> foo( a text, b int[])
>> it looks odd if both these calls are legal:
>> foo('a',1,2,3,)
>> foo('a',ARRAY[1,2,3])
>> which I understand would be the case with the current patch.
>
> Maybe I misunderstand what is supposed to happen, but I believe that
> if the function is marked VARIADIC then the second case would in fact
> be rejected: the signature of the function for parameter-matching
> purposes is text followed by one or more ints, never text and int[].
>
>> I'm also still curious to know how the following would be handled:
>> foo(a text[], b text[])
>
> I think a is just text[], full stop. Only the last parameter is
> interpreted differently for variadic.
>
> Your point about the syntax is good though. It would be better if
> the syntax were like
>
> create function foo (a text, variadic b int[])
>
> or maybe even better
>
> create function foo (a text, variadic b int)
>
> since (a) this makes it much more obvious to the reader what the
> function might match, and (b) it leaves the door open for marking
> multiple parameters as variadic, if we can figure out what that means.
>
> regards, tom lane
>

Re: [GENERAL] backslashes in 8.3.3

"Brandon Metcalf" <bmetcalf@nortel.com> writes:
> t == tgl@sss.pgh.pa.us writes:
> t> See standard_conforming_strings and escape_string_warning.

> Excellent. I had missed the standard_conforming_strings and will turn
> this on. Hold on. Yes, that did it. Thanks so much.

Well, if your intent is to replicate 8.1's behavior, you should instead
frob the other switch.

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

[pgsql-es-ayuda] slony u otro similar para postgresql 8.3. en windows

Hola que tal,
 
quisiera saber si existe alguna version de slony para postgresql 8.3 o informacion sobre otro software que haga replicas de base de datos y que funcione sobre postgresql 8.3 y en windows xp o superior
 
Gracias de antemano por la ayuda,
saludos.

Re: [ADMIN] plpgsql function seems to be leaking memory

Marc Cousin <mcousin@sigma.fr> writes:
> I'm having a problem with plpgsql functions leaking memory.

Your example shows absolutely no memory leak here, in either 8.3.3
or CVS HEAD.

> I see the postgresql process growing from 8MB to about 400 MB during this
> run...

What do you have shared_buffers set to? I think you might be getting
fooled by top's treatment of shared memory (ie, it starts to count
shared pages after the process touches them for the first time).

regards, tom lane

--
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] Git Repository for WITH RECURSIVE and others

On Tue, Jun 24, 2008 at 03:26:36PM +0900, Yoshiyuki Asaba wrote:
> Hi,
>
> From: David Fetter <david@fetter.org>
> Subject: [HACKERS] Git Repository for WITH RECURSIVE and others
> Date: Mon, 23 Jun 2008 21:38:11 -0700
>
> > With lots of help from Greg Sabino Mullane, I've set up a git
> > repository for the WITH RECURSIVE patches on
> > <http://git.postgresql.org/>.
>
> Thank you very much.
>
> I tried git-clone, but I could not access the repository.
>
> % git-clone git://git.postgresql.org/git/~davidfetter/postgresql/.git
> Initialized empty Git repository in /home/y-asaba/x/postgresql/.git/
> fatal: The remote end hung up unexpectedly
> fetch-pack from 'git://git.postgresql.org/git/~davidfetter/postgresql/.git' failed.

I ran git-update-server-info on the server, and it should work now. :)

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

--
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] what are rules for?

Adam Rich wrote:

> One interesting example is having rules and triggers watching for
> deletes or updates on a table. If many rows are modified, rules
> can be faster. Take this statement:
>
> DELETE FROM mydata WHERE idval BETWEEN 10000 and 20000;
>
> Say this statement deletes 10,000 rows. The delete trigger would
> get called 10,000 times whereas the rule is essentially executed
> once, since it can share the WHERE clause of the user's query.

This is a use case we should be able to better implement using FOR EACH
STATEMENT triggers, it seems. We just need to be able to pass the list
of affected tuples to the trigger function, which until now has remained
unimplemented.

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

Re: [GENERAL] backslashes in 8.3.3

t == tgl@sss.pgh.pa.us writes:

t> "Brandon Metcalf" <bmetcalf@nortel.com> writes:
t> > I just upgraded to 8.3.3 from 8.1.5 and noticed that backslashes are
t> > handled completely differently now. For example,

t> See standard_conforming_strings and escape_string_warning.


Excellent. I had missed the standard_conforming_strings and will turn
this on. Hold on. Yes, that did it. Thanks so much.


--
Brandon

--
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] Dept of ugly hacks: eliminating padding space in system indexes

Teodor Sigaev <teodor@sigaev.ru> writes:
>> dead easy to implement this: effectively, we just decree that the
>> index column storage type for NAME is always CSTRING. Because the

> Isn't it a reason to add STORAGE option of CREATE OPERATOR CLASS to BTree? as
> it's done for GiST and GIN indexes.

Hmm ... I don't see a point in exposing that as a user-level facility,
unless you can point to other use-cases besides NAME. But it would be
cute to implement the hack by changing the initial contents of
pg_opclass instead of inserting code in the backend. I'll give that
a try.

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

[pgsql-it-generale] == Postgres Weekly News - 22 giugno 2008 ==

Nuovo Sondaggio: Quale TODO vi piace di più?
http://www.postgresql.org/community/

== Offerte di lavoro legate a PostgreSQL per il mese di Giugno ==

http://archives.postgresql.org/pgsql-jobs/2008-06/threads.php


== PostgreSQL news locali ==

Il primo meeting del TorontoPUG ci sarà il 23 giugno al Rhino.
http://pugs.postgresql.org/blog/159

L'Oklahoma PUG terrà il suo primo meeting il 23 giugno dalle 19:00
alle 21:00 presso Coach's, Norman, OK.
http://pugs.postgresql.org/node/408

Il meeting di preparazione al PgDay italiano ci sarà mercoledi 25
giugno alle ore 2130 CET via IRC.
irc://irc.freenode.net/pgday-it

Il pgDay di Portland ci sarà il 20 luglio. Poco prima di OSCON.
http://pugs.postgresql.org/node/400

Il PGCon Brasile 2008 ci sara' il 26 e 27 settembre 2008 a Unicamp, Campinas.
http://pgcon.postgresql.org.br/index.en.html

Il PGDay.IT 2008 ci sarà il 17 e 18 ottobre a Prato.
http://www.pgday.org/it/

== News su PostgreSQL ==

Planet PostgreSQL: http://www.planetpostgresql.org/

General Bits, archivi e nuovi articoli occasionali:
http://www.varlena.com/GeneralBits/

PostgreSQL Weekly News è stato spedito questa settimana grazie a David
Fetter e Josh Berkus.

Per segnalare news e annunci invia un email in inglese entro le ore 15,
fuso orario della costa orientale degli U.S.A, di domenica.

Per segnalazioni in inglese david@fetter.org, per segnalazioni in
Tedesco pwn@pgug.de, per segnalazioni in italiano pwn@itpug.org


== Patch applicate ==
Tom Lane committed:

- Clean up a number of bogosities around pltcl's handling of the Tcl
"result": 1. Directly reading interp->result is deprecated in Tcl
8.0 and later; you're supposed to use Tcl_GetStringResult. This
code finally broke with Tcl 8.5, because Tcl_GetVar can now have
side-effects on interp->result even though it preserves the logical
state of the result. (There's arguably a Tcl issue here, because
Tcl_GetVar could invalidate the pointer result of a just-preceding
Tcl_GetStringResult, but I doubt the Tcl guys will see it as a bug.)
2. We were being sloppy about the encoding of the result: some
places would push database-encoding data into the Tcl result, which
should not happen, and we were assuming that any error result coming
back from Tcl was in the database encoding, which is not a good
assumption. 3. There were a lot of calls of Tcl_SetResult that
uselessly specified TCL_VOLATILE for constant strings. This is only
a minor performance issue, but I fixed it in passing since I had to
look at all the calls anyway. #2 is a live bug regardless of which
Tcl version you are interested in, so back-patch even to branches
that are unlikely to be used with Tcl 8.5. I went back as far as
8.0, which is as far as the patch applied easily; 7.4 was using a
different error processing scheme that has got its own problems :-(

- In pgsql/src/backend/optimizer/plan/setrefs.c, fix the code that
adds regclass constants to a plan's list of relation OIDs that it
depends on for replan-forcing purposes. We need to consider plain
OID constants too, because eval_const_expressions folds a
RelabelType atop a Const to just a Const. This change could result
in OID values that aren't really for tables getting added to the
dependency list, but the worst-case consequence would be occasional
useless replans. Per report from Gabriele Messineo.

- Clean up some problems with redundant cross-type arithmetic
operators. Add int2-and-int8 implementations of the basic
arithmetic operators +, -, *, /. This doesn't really add any new
functionality, but it avoids "operator is not unique" failures that
formerly occurred in these cases because the parser couldn't decide
whether to promote the int2 to int4 or int8. We could alternatively
have removed the existing cross-type operators, but experimentation
shows that the cost of an additional type coercion expression node
is noticeable compared to such cheap operators; so let's not give up
any performance here. On the other hand, I removed the
int2-and-int4 modulo (%) operators since they didn't seem as
important from a performance standpoint. Per a complaint last
January from ykhuang.

- In pgsql/src/backend/storage/ipc/sinvaladt.c, remove freeBackends
counter from the sinval shared memory area. We used to use it to
help enforce superuser_reserved_backends, but since 8.1 it's just
been dead weight.

- Improve error reporting for problems in text search configuration
files by installing an error context subroutine that will provide
the file name and line number for all errors detected while reading
a config file. Some of the reader routines were already doing that
in an ad-hoc way for errors detected directly in the reader, but it
didn't help for problems detected in subroutines, such as encoding
violations. Back-patch to 8.3 because 8.3 is where people will be
trying to debug configuration files.

- In pgsql/src/backend/utils/mb/mbutils.c, fix compiler warning
introduced by recent patch. Tsk tsk.

- Fix a few places that were non-multibyte-safe in tsearch
configuration file parsing. Per bug #4253 from Giorgio Valoti.

- Rewrite the sinval messaging mechanism to reduce contention and
avoid unnecessary cache resets. The major changes are: 1. When the
queue overflows, we only issue a cache reset to the specific backend
or backends that still haven't read the oldest message, rather than
resetting everyone as in the original coding. 2. When we observe
backend(s) falling well behind, we signal SIGUSR1 to only one
backend, the one that is furthest behind and doesn't already have a
signal outstanding for it. When it finishes catching up, it will in
turn signal SIGUSR1 to the next-furthest-back guy, if there is one
that is far enough behind to justify a signal. The
PMSIGNAL_WAKEN_CHILDREN mechanism is removed. 3. We don't attempt
to clean out dead messages after every message-receipt operation;
rather, we do it on the insertion side, and only when the queue
fullness passes certain thresholds. 4. Split SInvalLock into
SInvalReadLock and SInvalWriteLock so that readers don't block
writers nor vice versa (except during the infrequent queue cleanout
operations). 5. Transfer multiple sinval messages for each
acquisition of a read or write lock.

- In pgsql/src/backend/storage/ipc/sinvaladt.c, seems I was too
optimistic in supposing that sinval's maxMsgNum could be read and
written without a lock. The value itself is atomic, sure, but on
processors with weak memory ordering it's possible for a reader to
see the value change before it sees the associated message written
into the buffer array. Fix by introducing a spinlock that's used
just to read and write maxMsgNum. (We could do this with less
overhead if we recognized a concept of "memory access barrier"; is
it worth introducing such a thing? At the moment probably not --- I
can't measure any clear slowdown from adding the spinlock, so this
solution is probably fine.) Per buildfarm results.

Bruce Momjian committed:

- Move USE_WIDE_UPPER_LOWER define to c.h, and remove TS_USE_WIDE and
use USE_WIDE_UPPER_LOWER instead.

- In pgsql/src/backend/utils/mb/README, add URL for introduction to
multibyte programming in C.

- Move wchar2char() and char2wchar() from tsearch into /mb to be
easier to use for other modules; also move pnstrdup(). Clean up
code slightly.

- Add URL for TODO: "Allow pg_hba.conf to specify host names along
with IP addresses."

Neil Conway committed:

- In pgsql/doc/src/sgml/monitoring.sgml, fix a few typos in the DTrace
docs. Patch from Euler Taveira de Oliveira, along with an
additional typo I noticed along the way.

Alvaro Herrera committed:

- Improve our #include situation by moving pointer types away from the
corresponding struct definitions. This allows other headers to
avoid including certain highly-loaded headers such as rel.h and
relscan.h, instead using just relcache.h, heapam.h or genam.h, which
are more lightweight and thus cause less unnecessary dependencies.

== Patch rigettate (per ora) ==
Nessuno è stato scontentato questa settimana ;)

== Patch in attesa ==
Zoltan Boszormenyi sent in another revision of his POSIX fadvise
patch.

Simon Riggs sent in a patch to improve performance via hint bits for
write I/O.

--
(all opinions expressed are my own)
Federico Campoli
PostgreSQL Consulting -> PGHost http://www.pghost.eu

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

[GENERAL] Probably been asked a hundred times before.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Which disto is best for running a Postgres server?
I just installed OpenSuse and downloaded and compiled the latest version
of Postgres. It isn't that big of a hassle but I noticed that almost
none of the big distros keep all that up to date with Postgres as far as
what they have in their repositories.

I was wondering if anybody has made an Postgres centric distro? Just a
nice stripped down server Distro that is ideal for running a database
server on?

More just curious since I already got mine installed and compiled.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQEVAwUBSGEE9uLnn4qAcbUGAQJpkQf/VkeYeG9aCklcybj6qFPAgNRxT7foIiqt
sbjQI/Geik1qDX3WwD7o9bbPR7V8VmZqcY8JhXjsxD8ggNA9qi92YI5Sx/l7Nmaq
yhCPUPZfaexyGynI5DgUxx7glgZP4iPZfYcbjoy0nyaZPLXXDR11i3q8CXvdPhoE
oTGQBT07CijtGPN6y4h2ymlgePUQKoN0NPT9JQ5KQOc8PECpqJsFDUuIon0BtbeN
S+TB1lwAgiceINQBys6wYpw1epbYb3LV2zuN6GjEx41SQQO+8vF1tBpJTvkXBHZI
G3j457pL4NaRgbZtGC0aAz90G2QFFV1MJ9ocMX4Im6HYL2SYOBbDyQ==
=n84g
-----END PGP SIGNATURE-----

--
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] backslashes in 8.3.3

"Brandon Metcalf" <bmetcalf@nortel.com> writes:
> I just upgraded to 8.3.3 from 8.1.5 and noticed that backslashes are
> handled completely differently now. For example,

See standard_conforming_strings and escape_string_warning.

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] backslashes in 8.3.3

I just upgraded to 8.3.3 from 8.1.5 and noticed that backslashes are
handled completely differently now. For example,

db=# insert into junk (cifs) values ('\\foooo\bar');
WARNING: nonstandard use of \\ in a string literal
LINE 1: insert into junk (cifs) values ('\\foooo\bar');
^
HINT: Use the escape string syntax for backslashes, e.g., E'\\'.
INSERT 0 1
db=# select * from junk;
cifs
--------------
\foooo\x08ar
(1 row)

Is there anyway to disable this behavior or fix this on the server
side? I really don't want to have to rework all of our code that
inserts or queries data.

It seems this works,

db=# insert into junk (cifs) values (E'\\\\foobar\\bar');
INSERT 0 1

--
Brandon

--
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] Bulk load data from one table to another

Nikola <XLPizza@gmail.com> writes:
> Currently, I truncate the destination table, drop the indexes,
> execute:
> "INSERT INTO destination SELECT * FROM source_partition"
> and recreate indexes.

> This loads about 66.5 million rows into the destination table in about
> 1 hour. Recreating of indexes (4 of them) takes additional 2 hours. Is
> there a more efficient way to perform this procedure?

Do you have maintenance_work_mem set to a suitable value for building
the indexes?

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