Monday, September 15, 2008

Re: [ADMIN] Trouble setting up access privileges

mkrist@binf.ku.dk writes:
> The relevant line in pg_hba.conf is this:
> host all mette,mkrist 10.10.0.0 255.255.0.0 md5

What are the *other* lines in pg_hba.conf?

> I can't find anything in the documentation about exceptions from the
> pg_hba.conf rules,

There aren't any. The likely explanations are that (1) some earlier
line in pg_hba.conf is capturing the connection, (2) you are looking
at the wrong copy of pg_hba.conf, (3) you edited pg_hba.conf but
forgot to SIGHUP the postmaster, (4) you have a ~/.pgpass file on
the client side that is silently supplying a password in some of
these cases.

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] Transaction Snapshots and Hot Standby

On Friday 12 September 2008 07:44:36 Csaba Nagy wrote:
> And then
> the actually interesting question: what will the slave do with views,
> rules, triggers ? I guess triggers are out of the question to be
> executed, what about rules ? Probably must be also ignored... user
> functions will probably get errors if they try to update something...
> Views should probably function correctly.
>

If we dont have rules, we dont get views, so those need to be. Really we
should allow anything that would work in the context of a read only
transaction. (ie. functions that dont change anything should be fine to call)

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

--
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] Oracle and Postgresql

On Mon, Sep 15, 2008 at 11:35:30AM -0400, Jonathan Bond-Caron wrote:
> Harald wrote:
>
> > > If you are,
> > > it's an argument for security by obscurity, a system with a lot of
> > > deep known flaws.
>
> > That would be more the "Oracle stored procedures can be encrypted."
> > Which is an argument for ISVs, as they can easier force their
> > customers to pay "software maintainance".
>
> > With open code, clients could buy support from others, who may be
> > cheaper or, even more dangerous, more qualified.
>
> > As long as the disease of "Intellectual property" is running around,
> > that "I can encrypt my code" will provide some felt benefit for
> > PHBs....
>
> I have to disagree here. Encrypting stored procedures is not just
> about forcing customers to pay software maintenance.

Please to explain how you imagine this to be so.

> For us, it's about *protecting hard work and intellectual property*.

Yes, and of course nobody else does "hard work" either. Don't you
mean you're "protecting" this stuff by forcing people to pay for it?

> For example (very recent), we designed a fairly complicated
> inventory system using PL/pgSQL for a web platform. This customer
> is now looking into using Microsoft Dynamics CRM. This customer is
> looking for quotes from other companies to integrate their web
> platform (pgsql) with the CRM.

What of it?

> What now prevents these other companies from stealing our inventory
> system and putting it into MS SQL server?

What would motivate them to port the code, document same, develop
in-house expertise, etc., etc.? You've placed the burden of proof on
the wrong side here.

> And better yet, using the inventory system and selling it to other
> customers? Luckily copyright offers protection, but as we all know
> some companies always tend to stretch the rules as far as they can.

Copyright and contract law are precisely where you're going to be
fighting these battles anyhow, and that's why if you insist on this
kind of stuff, you hire attorneys with a good track record instead of
taking the fundamentally broken approach of obfuscating your code.

> For me, "Oracle stored procedures can be encrypted." is a very real
> and valuable argument.

It speaks to your judgement, and not favorably.

> It would certainly be a valuable feature in pgsql (in the enterprise
> space).

If by "enterprise" you mean "bloated and buggy," I quite agree.

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

Re: [pgsql-es-ayuda] consulta postgres

On 9/15/08, Gilberto Castillo Martínez <gilberto.castillo@etecsa.cu> wrote:
> Juan:
>
> Has probado hacerlo con slony?
>

no creo que le sirva, o al menos no sin complicarse un poco... para
empezar slony no es multi maestro, ademas el modo normal de operacion
es que *todos* los nodos esten disponibles todo el tiempo.

yo habia pensado en bucardo pero ese no funciona en win32 e imagino
que los clientes deberan tener postgres instalado...

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. (593) 87171157
--
TIP 3: Si encontraste la respuesta a tu problema, publícala, otros te lo agradecerán

Re: [HACKERS] rmgr hooks and contrib/rmgr_hook

On Mon, 2008-09-15 at 16:43 +0100, Gregory Stark wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
>
> > Bottom line is that any backup of Postgres needs to include plugin
> > directories, otherwise parts of the application could stop working
> > following restore. This patch doesn't change that.
>
> No, backups of executables are normally not the same backups as the data and
> in many cases -- minor upgrades for example -- cannot be.

So you advise your clients to do backup in two halves. Then complain
that this is a bad way to do a backup because it may cause
insurmountable problems on restore. And then seek to reject a patch
because of that, even though similar problems already exist in other
parts of the system. I'm sorry, but that is circular, then faulted
logic.

If you do a minor upgrade that changes the on-disk format of *any* part
of the system then you have just introduced a limitation into what
software can be used for restore. That could be a new version of a
custom datatype just as easily as it could be an rmgr plugin. Shall we
ban custom datatypes? Should we add a version number into every varlen
header just in case somebody switched release levels, then forgot?

> > * add the rmgr bms to the long header of each WAL file
> >
> > * change !RmgrIdIsValid() so that it causes FATAL by default. This then
> > allows people to correct a mistake and retry. We provide an option to
> > treat such errors as corrupt data and assume we have reached the end of
> > WAL.
>
> I'm not sure but I think this just begs the question. The problem is to ensure
> that the rmgrid means the same thing on the restoring database as it does on
> the original database, or at least a compatible version. I think this would
> mean having a long text description and version number to compare.

Why is that any different to using functions or other plugins? If you
restore data into a database where the functions have the same names,
yet do different things then you are in trouble. Period.

If you don't use an rmgr plugin at all then you have nothing different
to do, nor will you see any different messages. If you use *any*
external server software, expect to read the instructions or have
problems.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support


--
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] plpgsql is not translate-aware

Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > Actually this is wrong -- since the library is going to run with
> > "postgres" text domain, we need to add the files to the backend's
> > nls.mk:
>
> Can't we give it its own text domain? It seems fundamentally wrong
> for a plug-in language to require core support for its messages.
> (Now that I think about it, that may have been the reason we don't have
> localization for it already.) I suppose this must be possible,
> since e.g. glibc manages to have its own messages separate from
> whatever app it's linked with.

What glibc does is use dgettext() instead of plain gettext(), so they
are able to pass the domain along the message. See here, at the bottom:
http://github.com/bneumeier/glibc/tree/master/include/libintl.h
where _libc_intl_domainname is defined as "libc" elsewhere.

I guess one way to go about this is to add some way to pass the domain
from the caller, i.e.

ereport(ERROR,
(errdomain("plpgsql"),
errmsg(" ... ")))

but it seems a bit fragile, if only because it's easy to forget to add
it to new code, and easy to overlook a message that should have it.

Another idea would be to redefine errmsg() and friends within the
plpgsql sources, but that seems worse because every other library will
need to do the same.

Refinement of the previous idea: maybe we can add a compiler flag, to be
set in Makefiles, that defines the domain and passes it down to
EVALUATE_MESSAGE.

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

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

Re: [pgus-general] PgUS Memberships and Board Nominations Now Open

On Mon, 15 Sep 2008 09:38:44 -0700
"David E. Wheeler" <david@kineticode.com> wrote:

> On Sep 15, 2008, at 09:22, Joshua Drake wrote:
>
> >> That would be a shame.
> >
> > Why would that be? Honestly, I have never seen the point in OpenID.
> > (Not really interested in arguing either :)).
>
> There is, however, a point, and if pg.us could support it, it's only
> a good thing. Those who don't see the point don't have to use it.

Like I said, not interested in arguing. If people find use, people find
use. I am personally indifferent to the whole thing.

>
> > The idea of creating more maintenance for the website doesn't really
> > appeal to me but it certainly isn't only my decision.
>
> It's a bug. I really don't think supporting Open ID adds that much
> if you've already got the basics in place. And there'll be other
> bugs, too.

If someone would like to download Drupal, and diagnose the OpenID
authentication module -- rock on :). I am certainly not suggesting
someone not fix the problem.

Sincerely,

Joshua D. Drake


--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

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

[ADMIN] Functions

Dear PG members,
I want to know that does begin and end in plpgsql are related to begin transactions and commit? if yes/no how? If I start to execute a function of multiple statements does PG commits each transaction within a function, or whole function as a transaction. 
Also if first statement makes inserts/updates a row, does it automatically available to that particular function execution only or to any other instances of same function?
Please give the details.

In my system, function are extensively used and cab called by different clients as ODBC, JDBC and others.

Thanks for help,

CPK

Re: [GENERAL] Oracle and Postgresql

"Jonathan Bond-Caron" <jbondc@openmv.com> writes:

> What now prevents these other companies from stealing our inventory system
> and putting it into MS SQL server? And better yet, using the inventory
> system and selling it to other customers? Luckily copyright offers
> protection, but as we all know some companies always tend to stretch the
> rules as far as they can.

Well one thing which won't prevent it is DRM which an open source database has
the key to decrypt... All someone has to do is look at how Postgres decrypts
it and do the same thing.

Normally what prevents it is the value you offer in support and expertise with
the system you wrote. Why would someone want to put your inventory system in
an SQL Server anyways? You're not going to support it and they would be able
to support their system much better if they wrote it themselves.

The reality is that the value in software comes from the people supporting it.
Being able to add features as needed and fix problems that occur. The actual
bits of code are pretty worthless, they're cheap to produce.

--
Gregory Stark

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

Re: [pgsql-es-ayuda] consulta postgres

Juan:

Has probado hacerlo con slony?

Gilberto.

--
TIP 9: visita nuestro canal de IRC #postgresql-es en irc.freenode.net

Re: [pgsql-es-ayuda] Organizacion del PSDP-es

Colegas:

Disculpen .... no fue esa mi intención ... fue tan solo una sugerencia a
Guido .... veo me equivoque....

Disculpen nuevamente.

Gilberto.
El lun, 15-09-2008 a las 11:21 -0500, Jaime Casanova escribió:
> On 9/15/08, Gilberto Castillo Martínez <gilberto.castillo@etecsa.cu> wrote:
> >
> > Guido:
> >
> > Creo que si la registra como sociedad anónima .... quizás no tengamos
> > problemas en el futuro.
>
> no se que tratan de lograr pero la idea de una sociedad anonima no es
> la manera... hasta donde se, IANAL, una sociedad anonima implica
> accionistas (que aportaron dinero), implica que van a haber dividendos
> y utilidades (y debe llevar contabilidad claro)...
>

--
TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda

Re: [pgus-general] PgUS Memberships and Board Nominations Now Open

On Sep 15, 2008, at 09:22, Joshua Drake wrote:

>> That would be a shame.
>
> Why would that be? Honestly, I have never seen the point in OpenID.
> (Not really interested in arguing either :)).

There is, however, a point, and if pg.us could support it, it's only a
good thing. Those who don't see the point don't have to use it.

> The idea of creating more maintenance for the website doesn't really
> appeal to me but it certainly isn't only my decision.

It's a bug. I really don't think supporting Open ID adds that much if
you've already got the basics in place. And there'll be other bugs, too.

Best,

David

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

Re: [pgsql-es-ayuda] Organizacion del PSDP-es

Jaime Casanova escribió:
> On 9/15/08, Gilberto Castillo Martínez <gilberto.castillo@etecsa.cu> wrote:
> >
> > Guido:
> >
> > Creo que si la registra como sociedad anónima .... quizás no tengamos
> > problemas en el futuro.
>
> no se que tratan de lograr pero la idea de una sociedad anonima no es
> la manera... hasta donde se, IANAL, una sociedad anonima implica
> accionistas (que aportaron dinero), implica que van a haber dividendos
> y utilidades (y debe llevar contabilidad claro)...

Creo que se están creando montañas de soluciones y todavía no se ha
visto cuál es el problema a resolver.

De partida, ¿para qué quieren un dominio?

--
Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J
"La vida es para el que se aventura"
--
TIP 10: no uses HTML en tu pregunta, seguro que quien responda no podrá leerlo

Re: [ADMIN] ERROR: could not open relation 16388/24734/51896: Cannot open or remove a file containing a running program.

On Mon, 15 Sep 2008 11:31:21 -0400
KKreuzer@kbtoys.com wrote:

> Hi
> While running a VACUUM ANALYZE
> The process aborts and I receive the following message in the log:
>
> ERROR: could not open relation 16388/24734/51896: Cannot open or
> remove a file containing a running program.
> STATEMENT: VACUUM ANALYZE
>
> 51896 refers to an index on a table with over 10,000,000 rows.

Your index is corrupted. Drop the index and recreate it. See if that
solves the vacuum analyze problem. Note, you may have further
corruption.

Sincerely,

Joshua D. Drake
--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

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

Encrypted procedure code (was Re: [GENERAL] Oracle and Postgresql)

> I'll definitely look into that, but "PL that takes the encrypted code,
> decrypts it, and passes it to plpgsql, you can do it"
> at first sounds easier to maintain

Out of curiosity (having never used them), how does Oracle handle the
key for the encrypted code?

--
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] Oracle and Postgresql

On Mon Sep 15 11:48 AM, Scott Marlowe wrote:
> On Mon, Sep 15, 2008 at 9:35 AM, Jonathan Bond-Caron
> <jbondc@openmv.com> wrote:
>> For me, "Oracle stored procedures can be encrypted." is a very real
>> and valuable argument.
>> It would certainly be a valuable feature in pgsql (in the enterprise
> space).
>
> I don't see how that's any more effective than writing your stored
> procs in C in postgresql.

I'll definitely look into that, but "PL that takes the encrypted code,
decrypts it, and passes it to plpgsql, you can do it"
at first sounds easier to maintain

thanks for the tips


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

Re: [pgus-general] PgUS Memberships and Board Nominations Now Open

On Mon, 15 Sep 2008 12:03:51 -0400
Greg Sabino Mullane <greg@endpoint.com> wrote:

> > > I don't have an OpenID for testing; I'll have to check with JD
> > > to see what's up here.
> >
> > I say we just disable it.
>
> That would be a shame.

Why would that be? Honestly, I have never seen the point in OpenID.
(Not really interested in arguing either :)).

> Maybe it's as simple as some 'if openid, don't
> check captcha' code tweaks?

The idea of creating more maintenance for the website doesn't really
appeal to me but it certainly isn't only my decision.


Sincerely,

Joshua D. Drake


--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

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

Re: [pgsql-es-ayuda] Organizacion del PSDP-es

On 9/15/08, Gilberto Castillo Martínez <gilberto.castillo@etecsa.cu> wrote:
>
> Guido:
>
> Creo que si la registra como sociedad anónima .... quizás no tengamos
> problemas en el futuro.

no se que tratan de lograr pero la idea de una sociedad anonima no es
la manera... hasta donde se, IANAL, una sociedad anonima implica
accionistas (que aportaron dinero), implica que van a haber dividendos
y utilidades (y debe llevar contabilidad claro)...

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. (593) 87171157
--
TIP 5: ¿Has leído nuestro extenso FAQ?
http://www.postgresql.org/docs/faqs.FAQ.html

Re: [PERFORM] Effects of setting linux block device readahead size

On Thu, 11 Sep 2008, Scott Carey wrote:
> Preliminary summary:
>
> readahead  |  8 conc read rate  |  1 conc read rate
> 49152  |  311  |  314
> 16384  |  312  |  312
> 12288  |  304  |  309
>  8192  |  292  |
>  4096  |  264  |
>  2048  |  211  |
>  1024  |  162  |  302
>   512  |  108  |
>   256  |  81  | 300
>     8  |  38  |

What io scheduler are you using? The anticipatory scheduler is meant to
prevent this slowdown with multiple concurrent reads.

Matthew


--
And the lexer will say "Oh look, there's a null string. Oooh, there's
another. And another.", and will fall over spectacularly when it realises
there are actually rather a lot.
- Computer Science Lecturer (edited)
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [pgsql-es-ayuda] Organizacion del PSDP-es

Gilberto, no comprendo.

Sociedad Anonima es una figura legal en muchos paises, puntualmente
en el mio . No puedo registrar el dominio a nombre de ninguna Sociedad
a menos que sea tal. Escucho sugerencias.

gb.-

2008/9/15 Gilberto Castillo Martínez <gilberto.castillo@etecsa.cu>:
>
> Guido:
>
> Creo que si la registra como sociedad anónima .... quizás no tengamos
> problemas en el futuro.
> No estoy muy claro en ello ... pero es mi opinión ... Yo espero uno
> servidores que no están por llegar y pretendo tener en ellos un espejo
> del proyecto.
>
> Saludos,
> Gilberto.
>
>

--
http://www.linkedin.com/in/gbarosio
--
TIP 4: No hagas 'kill -9' a postmaster

[pgsql-de-allgemein] == Wöchentlicher PostgreSQL Newsletter - 14. September 2008 ==

Der Originalartikel befindet sich unter:
http://people.planetpostgresql.org/dfetter/index.php?/archives/191-PostgreSQL-Weekly-News-September-14-2008.html


== Wöchentlicher PostgreSQL Newsletter - 14. September 2008 ==

Commitfest Update: durch ein halbes Dutzend neuer Helfer zum Reviewen
konnten fast alle Patches zugewiesen werden. Dieses Commitfest könnte
in einer Woche abgeschlossen sein. Patches die diese Woche committed
wurden: to_date Formatprüfungen, GUC Parameter für Sourcecode Zeilen,
Boyer-Moore Stringsuche, Funktionen zum Auslesen des Funktionstextes,
Code coverage für Regressiontests, neue Zugriffsrechte für Truncate und
Verbesserungen in pg_bench, pg_dumpall, psql, PITR und Plan
Invalidierung. Diverse Patches wurden zurückgegeben weil mehr Arbeit
notwendig ist, dazu gehören Windowing Funktionen, PL/Proxy (wird es
leider nicht in 8.4 schaffen) und GRANT für Sequenzen.

Francisco J. Morosini von der Peruanischen PostgreSQL Gruppe hat
Postcast Nr. 3 erstellt mit David Fetter, PostgreSQL, DBI-Link, PL/Perl,
Erfashrungen mit PostgreSQL und Diskussionen in der Community und wie
man neue Leute Willkommen heißt.
http://www.postgresql.org.pe/?q=node/24

PgUS akzeptiert nun Mitglieder und Nominierungen für das Board.
https://www.postgresql.us/node/43

Der Kalender der Russischen PostgreSQL Community ist hier zu finden:
http://www.google.com/calendar/embed?src=4af2not88un2arkgnhhho2h7lk@group.calendar.google.com&ctz=Europe/Moscow

== PostgreSQL Produkt Neuigkeiten ==

Slony-I 1.2.15 erschienen.

== PostgreSQL Jobs im September ==

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

== PostgreSQL Lokal ==

Die Russische PostgreSQL Community trifft sich am 16. September in
Moskau.
http://postgresmen.ru/news/view/113

Selena Deckelmann und Gabrielle Roth werden eine Präsentation über
Dateisystem Performance für PostgreSQL auf der Linux Plumbers Konferenz
geben.
http://linuxplumbersconf.org/program/speakers/getspeaker.php?speaker=mwong.txt

PDXPUG trifft sich am 18. September. Tom Raney wird über sein
Visual Planner Tool sprechen.
http://pugs.postgresql.org/node/468

Die Prato Linux User Group wird PostgreSQL Vorträge im September
halten. Der Zeitplan:
http://www.prato.linux.it/serate_a_tema_2008

PGCon Brazil 2008 wird vom 26.-27. September auf dem Unicamp in
Campinas stattfinden.
http://pgcon.postgresql.org.br/index.en.html
Registrierung:
http://pgcon.postgresql.org.br/inscricoes.en.html

PgDay.fr wird am 4. Oktober in Toulouse. Der Call for Papers ist
eröffnet:
http://www.postgresqlfr.org/?q=node/1686
Registrierung:
http://www.pgday.fr/doku.php/inscription

Die Highload++ Konferenz wird vom 6.-8- Oktober in Moskau, Russland
statfinden. Gavin Roy, Asko Oja und Maxim Boguk sprechen über
PostgreSQL Dinge.
http://highload.ru

Die PostgreSQL West Konferenz 2008 wird vom 12. bis 12. Oktober in
Portland, State University in Portland, Oregon stattfinden.
http://www.postgresqlconference.org/
Die PostgreSQL West Konferenz vom 10.-12. Oktober 2008 akzeptiert
jetzt Registrierungen.
http://www.postgresqlconference.org/west08/register

PGDay.(IT|EU) 2008 wird am 17. und 18. Oktober in Prato stattfinden.
Die Registrierung ist bald möglich.
http://www.pgday.org/en/

PostgreSQL hat einen Stand auf der LinuxLive, Olymbia, in Londok (GB)
vom 23-25. Oktober 2008. Schreibe Dave Page wenn du teilnehmen möchtest.
dpage AT pgamin DOT org

== PostgreSQL in den News ==

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

Dieser wöchentliche PostgreSQL Newsletter wurde erstellt von David
Fetter Josh Berkus, Michael Brewer, Joshua Drake, Devrim GUNDUZ,
Francisco J. Morosini und Nikolay Samokhvalov.

Sende Neuigkeiten und Ankündigungen bis Sonntag, 15 Uhr Pazifischer
Zeit. Bitte sende englische Beiträge an david@fetter.org, deutsche an
pwn@pgug.de, italienische an pwn@itpug.org.

== Angewandte Patches ==

Tom Lane committed:

- Make pg_dump --data-only try to order the table dumps so that
foreign keys' referenced tables are dumped before the referencing
tables. This avoids failures when the data is loaded with the FK
constraints already active. If no such ordering is possible because
of circular or self-referential constraints, print a NOTICE to warn
the user about it.

- Fix a couple of problems pointed out by Fujii Masao in the
2008-Apr-05 patch for pg_stop_backup. First, it is possible that
the history file name is not alphabetically later than the last WAL
file name, so we should explicitly check that both have been
archived. Second, the previous coding would wait forever if a
checkpoint had managed to remove the WAL file before we look for it.
Simon Riggs, plus some code cleanup by me.

- Improve the plan cache invalidation mechanism to make it invalidate
plans when user-defined functions used in a plan are modified. Also
invalidate plans when schemas, operators, or operator classes are
modified; but for these cases we just invalidate everything rather
than tracking exact dependencies, since these types of objects
seldom change in a production database. Tom Lane; loosely based on
a patch by Martin Pihlak.

- In pgsql/src/pl/plpgsql/src/gram.y, fix a couple of places where the
plpgsql grammar would produce an unhelpful 'syntax error' message,
rather than something that might draw one's attention to a missing
or wrong-type variable declaration. Per recent gripe.

- In pgsql/src/interfaces/libpq/fe-exec.c, avoid using sprintf() for a
simple octal conversion in PQescapeByteaInternal. Improves
performance, per suggestion from Rudolf Leitgeb (bug #4414). The
backend did this right already, but not libpq.

- Make our parsing of INTERVAL literals spec-compliant (or at least a
heck of a lot closer than it was before). To do this, tweak
coerce_type() to pass through the typmod information when invoking
interval_in() on an UNKNOWN constant; then fix DecodeInterval to pay
attention to the typmod when deciding how to interpret a units-less
integer value. I changed one or two other details as well. I
believe the code now reacts as expected by spec for all the literal
syntaxes that are specifically enumerated in the spec. There are
corner cases involving strings that don't exactly match the set of
fields called out by the typmod, for which we might want to tweak
the behavior some more; but I think this is an area of user
friendliness rather than spec compliance. There remain some
non-compliant details about the SQL syntax (as opposed to what's
inside the literal string); but at least we'll throw error rather
than silently doing the wrong thing in those cases.

- In pgsql/src/backend/utils/misc/guc.c, tweak newly added
set_config_sourcefile() so that the target record isn't left corrupt
if guc_strdup should fail.

- Adjust the parser to accept the typename syntax INTERVAL ...
SECOND(n) and the literal syntax INTERVAL 'string' ... SECOND(n), as
required by the SQL standard. Our old syntax put (n) directly after
INTERVAL, which was a mistake, but will still be accepted for
backward compatibility as well as symmetry with the TIMESTAMP cases.
Change intervaltypmodout to show it in the spec's way, too. (This
could potentially affect clients, if there are any that analyze the
typmod of an INTERVAL in any detail.) Also fix interval input to
handle 'min:sec.frac' properly; I had overlooked this case in my
previous patch. Document the use of the interval fields qualifier,
which up to now we had never mentioned in the docs. (I think the
omission was intentional because it didn't work per spec; but it
does now, or at least close enough to be credible.)

- Tighten up to_date/to_timestamp so that they are more likely to
reject erroneous input, rather than silently producing bizarre
results as formerly happened. Brendan Jurd

- Add a duration option to pgbench, so that test length can be
specified in seconds instead of by number of transactions to run.
Takahiro Itagaki

- In pgsql/src/backend/optimizer/path/indxpath.c, skip opfamily check
in eclass_matches_any_index() when the index isn't a btree. We
can't easily tell whether clauses generated from the equivalence
class could be used with such an index, so just assume that they
might be. This bit of over-optimization prevented use of non-btree
indexes for nestloop inner indexscans, in any case where the join
uses an equality operator that is also a btree operator --- which in
particular is typically true for hash indexes. Noted while trying
to test the current hash index patch.

- In pgsql/doc/src/sgml/citext.sgml, update citext's documentation to
match the recently-applied patch, per David Wheeler.

Alvaro Herrera committed:

- In pgsql/src/pl/plpgsql/src/pl_exec.c, improve plpgsql's ability to
report tuple incompatibility problems. Volkan YAZICI.

- Add "source file" and "source line" information to each GUC
variable. initdb forced due to changes in the pg_settings view.
Magnus Hagander and Alvaro Herrera.

- Initialize the minimum frozen Xid in vac_update_datfrozenxid using
GetOldestXmin() instead of RecentGlobalXmin; this is safer because
we do not depend on the latter being correctly set elsewhere, and
while it is more expensive, this code path is not
performance-critical. This is a real risk for autovacuum, because
it can execute whole cycles without doing a single vacuum, which
would mean that RecentGlobalXmin would stay at its initialization
value, FirstNormalTransactionId, causing a bogus value to be
inserted in pg_database. This bug could explain some recent reports
of failure to truncate pg_clog. At the same time, change the
initialization of RecentGlobalXmin to InvalidTransactionId, and
ensure that it's set to something else whenever it's going to be
used. Using it as FirstNormalTransactionId in HOT page pruning
could incur in data loss. InitPostgres takes care of setting it to
a valid value, but the extra checks are there to prevent "special"
backends from behaving in unusual ways. Per Tom Lane's detailed
problem dissection in 29544.1221061979@sss.pgh.pa.us

Peter Eisentraut committed:

- In pgsql/doc/src/sgml/docguide.sgml, update man page build
instructions.

== Abgelehnte Patches (bis jetzt) ==

No one was disappointed this week :-)

== Eingesandte Patches ==

Brendan Jurd sent in another revision of his patch to add validation
to to_date().

Alvaro Herrera sent in a patch to make GUC source file and line number
visible.

Tatsuo Ishii sent in another revision of the Common Table Expressions
patch.

Tom Lane sent in a patch to make SQL interval literal syntax conform
to SQL:2008

Heikki Linnakangas sent in another revision of his FSM patch.

Ramon Lawrence sent in two revisions of a patch to disable the
physical-tlist optimization for hash join if the number of batches is
greater than 1.

Simon Riggs sent in another revision of his recovery infrastructure
patch.

David Wheeler sent in two revisions of a patch which adds support for
char to case-insensitive text.

Heikki Linnakangas sent in a set of performance tests for his FSM
patch.

KaiGai Kohei sent in another set of patches for SE-PostgreSQL.

Asif Naeem sent in a patch which correctly copies plugins to the
lib/plugins directory.

--
Andreas 'ads' Scherbaum
Deutsche PostgreSQL User Group: http://www.pgug.de
DPWN: http://andreas.scherbaum.la/blog/categories/18-PWN

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

[pgsql-es-ayuda] Organizacion del PSDP-es

Guido:

Creo que si la registra como sociedad anónima .... quizás no tengamos
problemas en el futuro.
No estoy muy claro en ello ... pero es mi opinión ... Yo espero uno
servidores que no están por llegar y pretendo tener en ellos un espejo
del proyecto.

Saludos,
Gilberto.

--
TIP 9: visita nuestro canal de IRC #postgresql-es en irc.freenode.net

Re: [GENERAL] Security issue for postgresql

aravind chandu wrote:
> Hi,
>
> I have a .h file in that there is a function in which there
> arguments were username and password for the database so that the user
> should be logged in,for that i need to write my own program.This is
> something about administrator privileges etc... can any one of you tell
> me the procedure to do this so that i will start working on it.

Maybe you can rephrase your question a bit? Its not clear what you
really want. If its all about credential storage on the client
you might check pgpass:

http://www.postgresql.org/docs/8.3/interactive/libpq-pgpass.html

Tino

Re: [pgus-general] PgUS Memberships and Board Nominations Now Open

-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkjOh24ACgkQvJuQZxSWSsjoZwCfUSEvy2pL3qk2E+L+a0p4g9vf
vGkAnA2JvNqvjdAwUaea9gnBMbfkXmiH
=vMw4
-----END PGP SIGNATURE-----
> > I don't have an OpenID for testing; I'll have to check with JD to see
> > what's up here.
>
> I say we just disable it.

That would be a shame. Maybe it's as simple as some 'if openid, don't
check captcha' code tweaks?

--
Greg Sabino Mullane greg@endpoint.com
End Point Corporation

[GENERAL] Security issue for postgresql

Hi,

        I have a .h file in that there is a function in which there arguments were username and password for the database so that the user should be logged in,for that i need to write my own program.This is something about administrator privileges etc... can any one of you tell me the procedure to do this so that i will start working on it.

Thank You,
Avin.

[pgadmin-hackers] SVN Commit by dpage: r7470 - in trunk/pgadmin3/pgadmin: include schema

Author: dpage

Date: 2008-09-15 16:56:48 +0100 (Mon, 15 Sep 2008)

New Revision: 7470

Revision summary: http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/?rev=7470&view=rev

Log:
Update the *nix server detection code to use the actual registry file format used in the one-click installers.

Modified:
trunk/pgadmin3/pgadmin/include/pgAdmin3.h
trunk/pgadmin3/pgadmin/schema/pgServer.cpp

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

Re: [pgsql-www] Mailserver/Majordomo problem

Andreas 'ads' Scherbaum wrote:
> On Sun, 14 Sep 2008 13:52:48 -0400 Alvaro Herrera wrote:
>
> > Andreas 'ads' Scherbaum wrote:

> > > As i said: tried to sbscribe to committers list and clicked the
> > > "subscribe" button. After several minutes i got the 500 error.
> > >
> > > http://mail.postgresql.org/mj/mj_wwwusr/domain=postgresql.org?func=lists-long-full&extra=pgsql-committers
> >
> > It works for me.
>
> This link works for me, of course.
> But i cannot subscribe myself to committers list.

I just subscribed to pgsql-committers using that link.

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

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

Re: [GENERAL] Oracle and Postgresql

In response to "Scott Marlowe" <scott.marlowe@gmail.com>:

> On Mon, Sep 15, 2008 at 9:35 AM, Jonathan Bond-Caron <jbondc@openmv.com> wrote:
> > For me, "Oracle stored procedures can be encrypted." is a very real and
> > valuable argument.
> > It would certainly be a valuable feature in pgsql (in the enterprise space).
>
> I don't see how that's any more effective than writing your stored
> procs in C in postgresql.

Perhaps the fact that the implementation time/effort for a C procedure
is something on the order of 10x that for a pl/pgsql procedure?

--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/

wmoran@collaborativefusion.com
Phone: 412-422-3463x4023

--
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] Heavy postgres process

Run top, hit M and the attach the output to a reply here and we'll take a look.

On Mon, Sep 15, 2008 at 5:33 AM, Vivek_Sharan <Vivek_Sharan@infosys.com> wrote:
> Thanks for your reply but how would I calculate which processes are eating up more memory, When I check process list, its only postgres and apache processes running on my system and only postgres processes are heavy. System runs out of memory quickly.
>
> Regards,
> ~Vivek
>
>
> -----Original Message-----
> From: Scott Marlowe [mailto:scott.marlowe@gmail.com]
> Sent: Friday, September 12, 2008 11:18 PM
> To: Vivek_Sharan
> Cc: pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] Heavy postgres process
>
> On Fri, Sep 12, 2008 at 2:12 AM, Vivek_Sharan <Vivek_Sharan@infosys.com> wrote:
>> Hi Admin,
>>
>> I'm new to this I have few queries as listed below
>>
>> 1) Number of connections made with a particular database.
>
> Wait, how to find out how many connections there are, or how many can
> a particular db handle.
>
> For this kind of thing, look at the admin functions in the pgsql-sql docs:
>
> http://www.postgresql.org/docs/8.3/interactive/functions-admin.html
>
> specifically you want something like:
>
> select datname from pg_stat_activity;
> select datname, count(datname) from pg_stat_activity group by datname;
>
>> 2) And how can I check which process (PID) is responsible for the
>> connection and
>
> That table up there ^^^
>
>> 3) what all can make a postgres process as heavy as 70-80 MB in size
>
> you may not be measuring properly. When you say it's using 70-80 MB
> how do you know this? The numbers you see in top aren't necessarily
> what some folks think they ar.
>
> **************** CAUTION - Disclaimer *****************
> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
> for the use of the addressee(s). If you are not the intended recipient, please
> notify the sender by e-mail and delete the original message. Further, you are not
> to copy, disclose, or distribute this e-mail or its contents to any other person and
> any such actions are unlawful. This e-mail may contain viruses. Infosys has taken
> every reasonable precaution to minimize this risk, but is not liable for any damage
> you may sustain as a result of any virus in this e-mail. You should carry out your
> own virus checks before opening the e-mail or attachment. Infosys reserves the
> right to monitor and review the content of all messages sent to or from this e-mail
> address. Messages sent to or from this e-mail address may be stored on the
> Infosys e-mail system.
> ***INFOSYS******** End of Disclaimer ********INFOSYS***
>

--
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] Oracle and Postgresql

On Mon, Sep 15, 2008 at 9:35 AM, Jonathan Bond-Caron <jbondc@openmv.com> wrote:
> For me, "Oracle stored procedures can be encrypted." is a very real and
> valuable argument.
> It would certainly be a valuable feature in pgsql (in the enterprise space).

I don't see how that's any more effective than writing your stored
procs in C in postgresql.

--
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] [PgFoundry] Unsigned Data Types [1 of 2]

On 9/15/08, Ryan Bradetich <rbradetich@gmail.com> wrote:
> Hello Jaime,
>
> I have the code and regression tests updated to solve the problems you initially
> discovered.

great, i will test during this week...

--
regards,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. (593) 87171157

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

Re: [GENERAL] Oracle and Postgresql

Jonathan Bond-Caron escribió:

> For me, "Oracle stored procedures can be encrypted." is a very real and
> valuable argument.
> It would certainly be a valuable feature in pgsql (in the enterprise space).

Fortunately for you, PostgreSQL is extensible, even in the procedural
languages area. This means that if you want to create a new PL that
takes the encrypted code, decrypts it, and passes it to plpgsql, you can
do it. It shouldn't be very difficult. There was some talk about doing
this as a pgfoundry project, but no one stepped up to actually doing the
work.

Of course, as pointed out by Scott Marlowe, any half-decent hacker will
be able to get the actual code out just like he would on encrypted
PL/SQL, but the barrier for stealing the code got considerably higher at
that point.

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

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

[ADMIN] Trouble setting up access privileges

Hi pgsql-admin mailing list,

I'm having some problems setting up access privileges via pg_hba.conf. The
problem is that it seems that some Linux user accounts have password-less
access to the pgsql databases via the 'pgsql' CLI tool even though I try to
enforce md5 password protection.

The relevant line in pg_hba.conf is this:
host all mette,mkrist 10.10.0.0 255.255.0.0 md5

If I'm logged in as the Linux user "mkrist" and try to log in to a database as
either the pgsql user "mette" or the pgsql user "mkrist" it requires me to
enter a password (which it then accepts and logs me in).

But if I'm OTOH logged in as the Linux user "mette" it only requires me to
enter a password if I try to login to a database with the pgsql user "mkrist"
(which it then accepts). If I try to login as the pgsql user "mette" it logs
in without asking for a password.

I can't find anything in the documentation about exceptions from the
pg_hba.conf rules, so I'm quite surprised by this behaviour.

Thank you, I'd appreciate any help.

--
Michael Kristensen <mkrist@binf.ku.dk>
IT-studentermedhjælper / Sysadm student aid
BINF

--
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] rmgr hooks and contrib/rmgr_hook

Simon Riggs <simon@2ndQuadrant.com> writes:

> Bottom line is that any backup of Postgres needs to include plugin
> directories, otherwise parts of the application could stop working
> following restore. This patch doesn't change that.

No, backups of executables are normally not the same backups as the data and
in many cases -- minor upgrades for example -- cannot be.

> * add the rmgr bms to the long header of each WAL file
>
> * change !RmgrIdIsValid() so that it causes FATAL by default. This then
> allows people to correct a mistake and retry. We provide an option to
> treat such errors as corrupt data and assume we have reached the end of
> WAL.

I'm not sure but I think this just begs the question. The problem is to ensure
that the rmgrid means the same thing on the restoring database as it does on
the original database, or at least a compatible version. I think this would
mean having a long text description and version number to compare.

And as Tom points out startup isn't often enough. Would WAL headers even be
often enough? We would have to ensure there was never two versions of the
plugin in the same WAL file.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning

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

Alfredo Guzmán escribió:
> Alvaro:
>
> Adjunto el archivo (formato excel).

Con estos valores es muy dudoso que el culpable sea Postgres. El valor
de work_mem es un poco alto, pero no exageradamente, y se liberará al
terminar cada consulta. Yo diría que tu problema está en otra parte.


--
Alvaro Herrera Valdivia, Chile ICBM: S 39º 48' 55.3", W 73º 15' 24.7"
"La naturaleza, tan frágil, tan expuesta a la muerte... y tan viva"
--
TIP 7: no olvides aumentar la configuración del "free space map"

Re: [GENERAL] Oracle and Postgresql

Harald wrote:

>> protection of database code, etc.
> Are you saying that the fact that the source isn't legally available
> to the population at large is a feature?  If you are, it's an argument
> for security by obscurity, a system with a lot of deep known flaws.

> That would be more the "Oracle stored procedures can be encrypted." Which
is an argument for ISVs, as they can easier force their customers to pay >
"software maintainance".

> With open code, clients could buy support from others, who may be cheaper
or, even more dangerous, more qualified. 

> As long as the disease of "Intellectual property" is running around, that
"I can encrypt my code" will provide some felt benefit for PHBs....

I have to disagree here. Encrypting stored procedures is not just about
forcing customers to pay software maintenance.

For us, it's about *protecting hard work and intellectual property*. For
example (very recent), we designed a fairly complicated inventory system
using PL/pgSQL for a web platform. This customer is now looking into using
Microsoft Dynamics CRM. This customer is looking for quotes from other
companies to integrate their web platform (pgsql) with the CRM.

What now prevents these other companies from stealing our inventory system
and putting it into MS SQL server? And better yet, using the inventory
system and selling it to other customers? Luckily copyright offers
protection, but as we all know some companies always tend to stretch the
rules as far as they can.

For me, "Oracle stored procedures can be encrypted." is a very real and
valuable argument.
It would certainly be a valuable feature in pgsql (in the enterprise space).

--
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] consulta postgres

Hola que tal. Disculpame la molestia.
Necesito desarrollar una aplicación que permita que usuarios de varios lugares de la ciudad se conecten mediante una aplicación desktop a una base de datos. El tema es que esta aplicacion desktop debe permitir que por mas que no haya internet, el usuario pueda seguir trabajando. ( y a lo sumo subir los cambios cuando vuelva la conexion)
Yo pense en una replicacion master-master.
Como puedo llevar a cabo este sistema con postgre? Necesito aplicaciones gratuitas y que no estén en versiones beta. Los clientes son windows, asique el pgCluster no me sirve

Muchisimas gracias de antemano!


Descargá ya gratis y viví la experiencia Windows Live. Descubre Windows Live

Re: [LIKELY_SPAM]Re: [GENERAL] Oracle and Postgresql

On Mon, Sep 15, 2008 at 8:31 AM, Roberts, Jon <Jon.Roberts@asurion.com> wrote:
>
> Roberts, Jon wrote:
>> > My top 10 reasons why companies pick Oracle.
>>
>> Do you mean they actually get these things, or they imagine they do?
>>
> Huh? Companies buy Oracle all of the time.

I think he meant the features, not the db.

>> > 2. Security: Patches,
>>
>> When they get good and ready. There are outstanding security issues
>> in Oracle that have been there for years.
>>
>
> I'm not saying Oracle is more or less secure. I think people feel
> better about security from a company like Oracle rather than a bunch of
> hackers on an email list. It is perceived as more secure by many,
> especially large companies.

Oracle has had security issues that they've sat on for years in the
past. years. Google for more info. I have never seen the "hackers
on an email list" who make pgsql do that. You find a security hole,
they patch it.

>> > encryption,
>>
>> We have it.
>>
> PG can't encrypt code.

PG can compile to C.

I'm willing to bet any halfway decent hacker could get the plsql code
out of an encrypted oracle procedure.

>> Are you saying that the fact that the source isn't legally available
>> to the population at large is a feature? If you are, it's an argument
>> for security by obscurity, a system with a lot of deep known flaws.
>>
> No, I'm saying that if I create a function in PG, ANYONE with access to
> the database can see my code. That is not secure. It is a security
> hole for the database.

It is NOT a security hole. Seeing the code and running the code are
two entirely different things.

>> > 3. Software indemnification (which is open source's biggest
>> > problem)
>>
>> Are you kidding?!? Read the EULA for Oracle or any other proprietary
>> software package and then read the BSD license. They both indemnify
>> about the same thing, i.e. nothing. If you have any examples in case
>> law that show otherwise, they'd be a great thing to bring forth.
>
> The contracts you sign when you buy Oracle indemnify you from lawsuits.
> For instance, Oracle bundles Apache with various products. If someone
> sues a company for using Oracle HTTP Server because it uses Apache and
> Apache was allegedly illegally contributed to by a rogue employee, then
> Oracle protects their customers.
>
> After SCO went after companies using Linux, it is a concern of large
> companies and worth the extra cost of paying Oracle for Apache rather
> than using Apache all by itself.

Any PHB who was scared of SCO's arm waving legal arguments deserves to
be run out of town on a rail. If SCO is the sum total of your
argument for software indemnifictation, you really don't have an
argument, except in the most abstract sense, that somewhere some PHB
is worried about a non-issue.

>> > 4. Scalability of shared disk (Oracle RAC)
>>
>> RAC doesn't scale outside Oracle's sales literature, as far as I've
>> seen.
>
> I have.

Sadly, you can't publish any numbers to prove it. :)

Seriously, very few instances is RAC any faster than just throwing
more hardware in a single image at the problem. Given the cost of the
sysadmins, licenses, crazy expensive SAN hardware, and extra
machinery, you're better off just buying a monstrously huge SUN with
100 disk RAID-10 array under it.

>> > 6. Best, oldest, and most proven concurrency model for any
>> > commercial database product
>>
>> It's none of those things.
>>
> Which commercial database is better? MS SQL Server, Sybase, DB2, what?

Every db has advantages and disadvantages in it's concurrency handling
ability. I'm willing to bet that to this TPF will outperform oracle.
But I don't want to run either of those.

OTOH, I have set up benchmarks that ran for weeks to burn in pgsql on
decent sized machines that hadd 1,000 concurrent accesses, and this
slowed queries down to 1 to 5 seconds instead of the usual sub
millisecond performance.

I'd like to say I've tested or seen others test Oracle like this and
it ran well, but whether or not I have, I am forbidden to tell you by
Oracle's licensing scheme.

>> > 7. Runs great on various platforms not just Linux or just Windows
>>
>> Is this different from some other RDBMS(s) out there, and if so, which
>> one(s)? The only "just Windows" RDBMS I've ever heard of is MS SQL
>> Server, and I know of no "just Linux" ones.
>>
> PG doesn't scale well on Windows. DB2 seems to work best on a
> mainframe. Sybase works best on Unix. MS SQL Server only runs on
> Windows.

Oh no! That means we can only run pgsql on various flavours of unix
with good performance. That only gives us Linux, BSD(s), Solaris,
AIX, HPUX and a few others.

Sure, Oracle runs fast on those too, but don't try to tell me oracle
runs as fast and scales as well on Windows. That I know isn't true,
I've seen the performance myself a few times.

>> > 9. Deep, deep discounts. I've never seen any company pay list
>> > price for Oracle products. It has always been at least 50% off if
>> > not more.
>>
>> 50% off a price that's bloated by 1000% or more isn't much of a
>> muchness.
>>
> It is only the perception of a good deal. So what?

Really? Do you light your cigars with 100 dollar bills or something?
I can't just throw $250k at a problem at work without justification.
The fact that 250k is half the retail price of $500k doesn't really
fly with my boss, as much as he loves a deal.

>> > 10. Sales employees that will do anything to retain or grow your
>> > business.
>>
>> That's just great if you prefer hookers and blow to a working RDBMS.
>>
> LOL. That is pretty funny. I'm talking about doing free work like a
> proof of concepts, demonstrations of products, etc. I've even seen
> technical sales guys help out onsite for free for performance tuning an
> application.

Well, I never got that kind of treatment at my last company. Oracle
was quite willing to renegotiate pricing (i.e. 500k to 250k woohoo!)
but never once stepped foot in our office, and we were having massive
problems getting RAC working.

>> > The initial price of the product factors into the equation for big
>> > companies but when you look at all the value add of Oracle, it is
>> > very tempting.
>>
>> Their sales and marketing people have certainly done an excellent job
>> creating the perceptions above, among others, and spreading them
>> around the industry.
>
> Perception = sales.

Yes. If the person doing the buying is easily entertained by small
shiny objects, yes, that's true.

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

[ADMIN] ERROR: could not open relation 16388/24734/51896: Cannot open or remove a file containing a running program.


Hi
While running a VACUUM ANALYZE
The process aborts and I receive the following message in the log:

ERROR: could not open relation 16388/24734/51896: Cannot open or remove a file containing a running program.
STATEMENT: VACUUM ANALYZE

51896 refers to an index on a table with over 10,000,000 rows.

The process runs nightly with this being the first time I have a problem.
It runs at 2:45 am where there should be no contention.

select version() ;
"PostgreSQL 8.2.6 on powerpc-ibm-aix5.2.0.0, compiled by GCC gcc (GCC) 4.0.0"

Any input would be appreciated.


Keith Kreuzer
ext 3424

Re: [pgsql-www] Mailserver/Majordomo problem

On Sun, 14 Sep 2008 13:52:48 -0400 Alvaro Herrera wrote:

> Andreas 'ads' Scherbaum wrote:
> > On Fri, 12 Sep 2008 23:41:02 -0300 Marc G. Fournier wrote:
> >
> > > I don't know of any problems ... what URL?
> >
> > As i said: tried to sbscribe to committers list and clicked the
> > "subscribe" button. After several minutes i got the 500 error.
> >
> > http://mail.postgresql.org/mj/mj_wwwusr/domain=postgresql.org?func=lists-long-full&extra=pgsql-committers
>
> It works for me.

This link works for me, of course.
But i cannot subscribe myself to committers list.

Tried with Firefox 2 behind my proxy, Konqueror 3.5 behind my proxy and
lynx from another host outside. Each request get's a 500 error.


Kind regards

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group

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

Re: [pgus-general] PgUS Memberships and Board Nominations Now Open

Michael Alan Brewer wrote:
> On Sun, Sep 14, 2008 at 12:13 PM, Greg Sabino Mullane <greg@endpoint.com> wrote:
>> The OpenID login seems not to work, once you login via OpenID, you get
>> returned to the site and an "Invalid CAPTCHA token." error pops up,
>> despite their not being a captcha on the openid login page. Anyone found a
>> workaround?
>
> I don't have an OpenID for testing; I'll have to check with JD to see
> what's up here.

I say we just disable it.

>
>> The main page invites people to view the bylaws, but a "permission denied"
>> error appears when you try to do so. If a login is required to view the
>> bylaws (which seems a bad idea), the pages should state so.
>
> Have added a parenthetical "login required" statement to the link.

As a note: We are not trying to restrict to login only but for some
reason, since its an attachment it doesn't let it be downloaded unless
it you are logged in. I will take a look and see if I can figure out
what the perms are doing.

Joshua D. Drake


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

RE: [pgsql-es-ayuda] Consulta

Alvaro:

Adjunto el archivo (formato excel).

Saludos


Alfredo Guzmán

-----Mensaje original-----
De: pgsql-es-ayuda-owner@postgresql.org
[mailto:pgsql-es-ayuda-owner@postgresql.org] En nombre de Alvaro Herrera
Enviado el: Lunes, 15 de Septiembre de 2008 10:02 a.m.
Para: Alfredo Guzmán
CC: pgsql-es-ayuda@postgresql.org
Asunto: Re: [pgsql-es-ayuda] Consulta

Alfredo Guzmán escribió:
> Sres.
>
> Entiendo que deberia ser normal que tome la mayor cantidad de memoria,
> sin embargo estos valores de uso permanecen en el tiempo y no son
> liberados. Si luego de ello se activa una aplicación el servidor tiene
> que Swapear y eso no es lo más recomendable. Inicialmente se le tuvo
> que incrementar la cantidad de memoria a 8.0 GB y aun asi se consume.

¿Hmm? El "exceso" de consumo de memoria deberia ser en cache de archivos,
por parte del kernel. Eso se libera automaticamente a medida que se
necesita. Si no es asi, tienes el servidor mal configurado. Por favor
muestra select * from pg_settings where source <> 'default';

--
Alvaro Herrera
http://www.amazon.com/gp/registry/5ZYLFMCVHXC
"Hoy es el primer día del resto de mi vida"
--
TIP 7: no olvides aumentar la configuración del "free space map"
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.169 / Virus Database: 270.6.21/1672 - Release Date: 15/09/2008
9:21

Re: [pgsql-es-ayuda] ayuda con jdbc

Si quieres puedes colocar el driver JDBC
(postgresql-X.X-XXX.jdbcX.jar) dentro del directorio jre/lib/ext

De esta manera no tendrás que especificarlo en el CLASSPATH

----
Neil Peter Braggio
pbraggio@gmail.com

On Sat, Sep 13, 2008 at 6:32 AM, Rodriguez Fernando
<rodriguez@ort.edu.uy> wrote:
> Marco Vinicio Jimenez Rojas escribió:
>>
>> Tengo un sistema en Java funcionando perfectamente, todo trabaja con
>> linux, pero para trabajar en windows necesito colocar el jdbc donde el jvm
>> lea los dirvers, se hacerlo en linux y gogliando se encuentra dicha direcion
>> pero en linux, no se donde tengo que ponerlo en windows y no encuentro
>> donde, si alguein me ayuda lo agradeceria.
>>
>> --
>>
>> -----------------------
>> MVJR
>
> Hola, que version usas?,
> si lo pones en directorio lib de la aplicacion te funciona en cualquier
> plataforma.
>
>
> Saludos Fernando
> --
> TIP 3: Si encontraste la respuesta a tu problema, publícala, otros te lo
> agradecerán
>
--
TIP 10: no uses HTML en tu pregunta, seguro que quien responda no podrá leerlo

[pgsql-es-ayuda] Fwd: traduccion manuales Postgresql

Hola foro
Al grupo de traduccion del manual postgresql, hay este software llamado atamiri que puede ayudar a traducir, pero tiene costo.
Reenvio el mail
Fernando Lopez


---------- Mensaje reenviado ----------
De: Iván Guzmán de Rojas <igr@atamiri.cc>
Fecha: 13 de septiembre de 2008 14:12
Asunto: Re: traduccion manuales Postgresql
Para: Luis Fernando Lopez Aguilar <flopezg333@gmail.com>


Estimado Fernando:

Si, justamente Atamiri ha demostrado su eficacia en traducción de manuales técnicos. Yo requeriría el glosario bilingüe de los términos técnicos que utilizan para alimentarlo a nuestra base de datos lexicográfica. Si prefieren, este glosario podríamos crearlo conjuntamente (tiene costo aparte).

El costo de la traducción en fino, después de posteditar (afinar) la traducción en bruto, es de aproximadamente 8 centavos de dólar por palabra. Podemos hacer pruebas para que vean la calidad de la traducción en bruto, quizás así ustedes mismos quieran hacer el trabajo de postedición, que desde luego va muchísimo más rápido que traducir de cero. El costo de la traducción en bruto es de aproximadamente 2 UScents/palabra.

Cordialmente,
Iván Guzmán de Rojas



On 9/13/08, Luis Fernando Lopez Aguilar <flopezg333@gmail.com> wrote:
Estimado Ingeniero Rojas.

Postgresql es un DBMS administrador de base de datos relacional de uso libre sin pago de licencias, y es un serio competidor de Oracle.

Actualmente esta en la version 8.xx y el problema con que tropezamos la gente de habla hispana es para algunos una gran dificultad el idioma de los manuales.

Recientemente en el foro postresql se esta organizando un equipo de traduccion del ultimo manual.

Ahora mi pregunta es.... Existiria alguna posibilidad de utilizar el Atamiri para la traduccion de estos manuales?

Un saludo muy cordial
Fernando Lopez
Santa Cruz - Bolivia



Re: [HACKERS] Transaction Snapshots and Hot Standby

On Mon, 2008-09-15 at 16:26 +0300, Heikki Linnakangas wrote:
> In any case,
> we'll need the capability in the slave to notice when it's about to
> remove a tuple that's still visible to a snapshot in the slave.

Looks like what I'll do is this:

Alter functions in pruneheap.c so that we bubble up the latest xid that
is being removed as part of block cleaning. We then add that xid into
the WAL record for cleaning.

If latest xid of clean is ahead of oldestxmin of running queries on
standby then Startup process needs to take action, of some kind.

Re-examining the tuples in WAL apply seems bad plan, since we'd have to
touch stuff in the block twice and juggle the locks.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support


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

[HACKERS] Integrating hash index tupledesc hack a bit better

A few days ago I complained that the lossy-hash-indexes patch needed a
better solution for letting catalog/index.c know that hash indexes will
really store only hashcodes and not the underlying column type. The
current version of the patch puts some hard-wired knowledge into
index.c:

/* HACK: make hash always use int4 as storage (really it's uint32) */
if (opclassTup->opcmethod == HASH_AM_OID)
keyType = INT4OID;
else
keyType = opclassTup->opckeytype;

which might not exactly be a stop-ship issue but it still seems pretty
distasteful.

We could avoid the problem if all hash opclasses were marked as having
storage type int4, but that seems to just move the problem over to
opclass creation --- I doubt we want to insist on user-defined opclasses
changing to accommodate this, so we'd have to force this marking
internally in CREATE OPERATOR CLASS.

The idea that seems most attractive to me at the moment is to add a
column to pg_am, probably defined like pg_opclass.opckeytype but
applying to all opclasses of the index type.

Another possibility is the idea I floated before of adding an AM entry
point to let it manipulate the index tupledesc in a more general fashion
during CREATE INDEX. However it's unclear how much flexibility that
would really buy us given the assumptions that are wired into various
places, so I'm thinking it's probably just useless complication.

Comments, better ideas?

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: [pgsql-www] Download links

On Sun, Sep 14, 2008 at 09:19:42AM -0400, Chander Ganesan wrote:

> This is exactly the sort of thing that I'm concerned about. Now company,
> Y, Z, etc. can do the same thing, or even OTG can re-package PostgreSQL and
> perform the same set of tasks.

Yes, of course. That's just a consequence of the BSD license, no?

A

--
Andrew Sullivan
ajs@commandprompt.com
+1 503 667 4564 x104
http://www.commandprompt.com/

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

Re: [pgsql-es-ayuda] Consulta

Alfredo Guzmán escribió:
> Sres.
>
> Entiendo que deberia ser normal que tome la mayor cantidad de memoria, sin
> embargo estos valores de uso permanecen en el tiempo y no son liberados. Si
> luego de ello se activa una aplicación el servidor tiene que Swapear y eso
> no es lo más recomendable. Inicialmente se le tuvo que incrementar la
> cantidad de memoria a 8.0 GB y aun asi se consume.

¿Hmm? El "exceso" de consumo de memoria deberia ser en cache de
archivos, por parte del kernel. Eso se libera automaticamente a medida
que se necesita. Si no es asi, tienes el servidor mal configurado. Por
favor muestra select * from pg_settings where source <> 'default';

--
Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC
"Hoy es el primer día del resto de mi vida"
--
TIP 7: no olvides aumentar la configuración del "free space map"

Re: [HACKERS] rmgr hooks and contrib/rmgr_hook

On Mon, 2008-09-15 at 10:04 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:

> > The version mismatch idea presumes that a code author would structure
> > their code in two pieces: one to generate the WAL and one to read it.
>
> No, the version mismatch problem is that you might try to read the WAL
> with a different version of the plugin than you wrote it with. Or maybe
> with a completely unrelated plugin that was unfortunate enough to choose
> the same rmgr ID. We can't afford to insert complete versioning
> information into each WAL record, so it's going to be pretty difficult
> to avoid this risk.

I'm happy to include additional things into the patch, but I don't see
anything to force rejection of the patch entirely, from what has been
said.

Bottom line is that any backup of Postgres needs to include plugin
directories, otherwise parts of the application could stop working
following restore. This patch doesn't change that.

I proposed a registration scheme to avoid one of those problems.

If a plugin changed its file format, it would clearly need to include a
version test within it. It wouldn't be the fault of the plugin API if
the plugin author didn't handle that. But if they can work out how to
build an index AM and write WAL, I'm sure they can handle version
management between software components and informative error messages if
problems occur. And if they can't, they'll get a bad rep and nobody will
use the plugin.

Few ideas:

* add the rmgr bms to the long header of each WAL file

* change !RmgrIdIsValid() so that it causes FATAL by default. This then
allows people to correct a mistake and retry. We provide an option to
treat such errors as corrupt data and assume we have reached the end of
WAL.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support


--
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] Heavy postgres process

Thanks for your reply but how would I calculate which processes are eating up more memory, When I check process list, its only postgres and apache processes running on my system and only postgres processes are heavy. System runs out of memory quickly.

Regards,
~Vivek


-----Original Message-----
From: Scott Marlowe [mailto:scott.marlowe@gmail.com]
Sent: Friday, September 12, 2008 11:18 PM
To: Vivek_Sharan
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] Heavy postgres process

On Fri, Sep 12, 2008 at 2:12 AM, Vivek_Sharan <Vivek_Sharan@infosys.com> wrote:
> Hi Admin,
>
> I'm new to this I have few queries as listed below
>
> 1) Number of connections made with a particular database.

Wait, how to find out how many connections there are, or how many can
a particular db handle.

For this kind of thing, look at the admin functions in the pgsql-sql docs:

http://www.postgresql.org/docs/8.3/interactive/functions-admin.html

specifically you want something like:

select datname from pg_stat_activity;
select datname, count(datname) from pg_stat_activity group by datname;

> 2) And how can I check which process (PID) is responsible for the
> connection and

That table up there ^^^

> 3) what all can make a postgres process as heavy as 70-80 MB in size

you may not be measuring properly. When you say it's using 70-80 MB
how do you know this? The numbers you see in top aren't necessarily
what some folks think they ar.

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
for the use of the addressee(s). If you are not the intended recipient, please
notify the sender by e-mail and delete the original message. Further, you are not
to copy, disclose, or distribute this e-mail or its contents to any other person and
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken
every reasonable precaution to minimize this risk, but is not liable for any damage
you may sustain as a result of any virus in this e-mail. You should carry out your
own virus checks before opening the e-mail or attachment. Infosys reserves the
right to monitor and review the content of all messages sent to or from this e-mail
address. Messages sent to or from this e-mail address may be stored on the
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

--
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] Transaction Snapshots and Hot Standby

On Sat, 2008-09-13 at 10:48 +0100, Florian G. Pflug wrote:

> The current read-only snapshot (which "current" meaning the
> corresponding state on the master at the time the last replayed wal
> record was generated) was maintained in shared memory. It' xmin field
> was continually updated with the (newly added) XLogRecord.xl_xmin
> field, which contained the xid of the oldest running query on the
> master, with a pruning step after each ReadOnlySnapshot.xmin update to
> remove all entries < xmin from the xid array. If a commit was seen for
> an xid, that xid was added to the ReadOnlySnapshot.xid array.
>
> The advantage of this concept is that it handles snapshotting on the
> slave without too much additional work for the master (The only change
> is the addition of the xl_xmin field to XLogRecord). It especially
> removes that need to track ShmemVariableCache->nextXid.

Snapshots only need to know which transactions are currently "running"
during WAL apply. The standby can't remove any tuples itself, so it
doesn't need to know what the master's OldestXmin is.

So passing xl_xmin from master to standby seems not necessary to me. The
standby's OldestXmin needs to be passed through to the master, not the
other way around so that WAL records for tuple removal are not
generated.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support


--
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] no XLOG during COPY?

On Thu, 2008-09-11 at 15:25 -0400, Andrew Dunstan wrote:

> Great, thanks (and also to Guillaume).
>
> It looks to me like the simple way around this issue would be to provide
> an option to have pg_restore emit:
> begin; truncate foo; copy foo ... commit;
>
> The truncate will be trivial as there won't be any data or indexes at
> that stage anyway.

Not sure which stage you're talking about. If this is a parallel restore
and you are running a create in one session and a load in another, then
ISTM you have no way of knowing that for certain.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support


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

[INTERFACES] Async processing of rows

Hi

I will be writing an EOF (http://en.wikipedia.org/wiki/Enterprise_Objects_Framework
) adaptor for Postgres. Due to the way these are structured, I want to
process the result data row by row and not in one big tuple array. I
looked into the pg-library and it seems that this is possible, albeit
not without adding something to the API.

PQgetResult seems to loop as long as PGASYNC_BUSY is set, and that
appears to be set as long as there are rows being sent from the
server. Correct ?

So I what I think I need to do is write a function PQgetNextResult
that only blocks if there is not enough data available for reading in
one row.

A cursory glance at pqParseInput3 shows, that I can't call it with
incomplete input, as data is discarded even if the parse is
incomplete, mainly, this piece of code discards 'id' if msgLength can
not be completely read, which makes me wary:

conn->inCursor = conn->inStart;
if (pqGetc(&id, conn))
return;
if (pqGetInt(&msgLength, 4, conn))
{
/* (nat) expected to see: pqUngetc( id, conn); */
return;
}

So am I missing something or is this basically correct ?

Ciao
Nat!
----------------------------------------------
I'd like to fly
But my wings have been so denied -- Cantrell


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

[HACKERS] New shapshot RPMs (Sep 15 2008) are ready for testing

Hi,

I just released new RPM sets, which is based on Sep 15 10:00 AM EEST CVS
snapshot.

These packages *do* require a dump/reload, even from previous 8.4
packages, because of a catversion update.

Over the last week, we have 70 more testers (now 220!) .

As usual, please find detailed info from:

http://yum.pgsqlrpms.org

A mini howto about 8.4devel release + RPMs is here:

http://yum.pgsqlrpms.org/news-8.4devel-ready-for-testing.php

The tarball I used is here:

http://yum.pgsqlrpms.org/srpms/8.4

(I will remove tarballs after a few weeks...)

Please report any packaging related errors to me. If you find any
PostgreSQL 8.4 bugs, please post them to pgsql-bugs@PostgreSQL.org or
fill out this form:

http://www.postgresql.org/support/submitbug 

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

Re: [HACKERS] rmgr hooks and contrib/rmgr_hook

On Mon, 2008-09-15 at 10:47 +0100, Gregory Stark wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
>
> > On Sat, 2008-09-13 at 10:59 +0300, Heikki Linnakangas wrote:
> >
> >> The 2nd use case, however, I find pretty unconvincing. I can't think of
> >> a good example of that. Anything that needs to define its own resource
> >> manager is very low-level stuff, and probably needs to go into the core
> >> anyway.
> >
> > New indexes are a big one, but I listed others also.
> >
> > Indexes have always been able to be added dynamically. Now they can be
> > recovered correctly as well.
>
> Hm, so currently if you want to add a new indexam you can't just insert into
> pg_am and make them recoverable. You basically have to build in your new index
> access method into Postgres with the new rmgr. That is annoying and a problem
> worth tackling.

Agreed.

> But I'm a bit worried about having this be an external plugin. There's no way
> to looking at a WAL file to know whether it will be recoverable with the
> plugins available. Worse, there's a risk you could have a plugin but not the
> *right* plugin.

That risk was discussed and is handled in the plugin. You are limited to
only insert data into WAL that has a current plugin that says it will
handle redo for that type.

> Perhaps this could be tackled simply by having startup insert
> a record listing all the rmgr's in use with identifying information and their
> version numbers.

Non-standard plugins in use are listed when in use, so we can all see
what's going on. Plugins can issue their own startup messages if they
choose, with version numbers and other details.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support


--
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] 8.3.3 compiler warnings with gcc 4.3

Tom Lane <tgl@sss.pgh.pa.us> writes:

> Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= <devrim@gunduz.org> writes:
>> I'm getting these on Fedora-9:
>> tqual.c:115: warning: inlining failed in call to ‘SetHintBits’: call is
>
> They're just cosmetic. We don't generally worry about fixing cosmetic
> warnings in back branches.

Are they? It seems like these were marked inline for a reason. SetHintBits has
at least one conditional in it which can often be optimized out (it's either
InvalidTransactionId or else has been tested already).

In the tuplestore case there's not much point in having that function if it's
not going to be inlined. I'm imagining that it was put in because someone did
verify that the non-inlined version was consuming significant time. -- Perhaps
a bit assumption though.

Also, is 8.3 really a "back branch"? It's the current release and anyone
downloading Postgres from source on the web site will be getting these
warnings -- and there are a lot of them. Enough that it looks like something's
gone wrong with the build.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!

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

[SQL] select from two tables

Hi.

I have two tables, images and duplicates. The images-table is our
current table and has approx. 90 mill. entries. I want to weed out
duplicate file-entries (based on the md5-checksum of the file and
user-id) and update the file name with the first entry found, if any.

The images-table is:

id serial primary key,
userid int,
filename text,
hashcode text,
and some additional fields like upload-time, exif-date etc.

Duplicates:
id serial primary key,
userid int,
filename text,
hashcode text,
ref_count int

Here is some pseudo-code (in rails) that I have tested. This is
somewhat slow and I want to speed it up:

a=0
while a < 10000

@image = select * from images where id = a;
if @image

@duplicate = select * from duplicates where userid = @image.userid
and hashcode = @image.hashcode
if @duplicates
update @duplicates set ref_count = @duplicates.ref_count + 1
else
insert into duplicates (foo) values (bar)
end

end
a++
end

What I'd like to do is to perform a single query where I select from
both tables and then test whether the file is all-ready in duplicates:

@rec = select * from images i and duplicates d where i.id = a and
d.userid = i.userid and d.hashcode = i.hashcode
if @rec.images and @rec.duplicates
update duplicates.ref_count
else
insert into duplicates (foo) values (bar)
end

--
regards
Claus

When lenity and cruelty play for a kingdom,
the gentler gamester is the soonest winner.

Shakespeare

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

[HACKERS] Mechanism to transmit multiple event notifications with one signal

Hi,

On Fri, Sep 12, 2008 at 12:41 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Markus Wanner <markus@bluegap.ch> writes:
>> Tom Lane wrote:
>>> Sooner or later we shall have to bite the bullet and set up a
>>> multiplexing system to transmit multiple event types to backends with
>>> just one signal. We already did it for signals to the postmaster.
>
>> Agreed. However, it's non-trivial if you want reliable queues (i.e. no
>> message skipped, as with signals) for varying message sizes.
>
> No, that's not what I had in mind at all, just the ability to deliver
> one of a specified set of event notifications --- ie, get around the
> fact that Unix only gives us two user-definable signal types.
>
> For signals sent from other backends, it'd be sufficient to put a
> bitmask field into PGPROC entries, which the sender could OR bits into
> before sending the one "real" signal event (either SIGUSR1 or SIGUSR2).
>
> I'm not sure what to do if we need signals sent from processes that
> aren't connected to shared memory; but maybe we need not cross that
> bridge here.
>
> (Also, I gather that the Windows implementation could already support
> a bunch more signal types without much trouble.)

There was discussion of event notification to backends from other process
in the thread, "Synchronous Log Shipping Replication"
(http://archives.postgresql.org/pgsql-hackers/2008-09/msg00802.php).

The problem is that it's difficult to define new event notification using signal
to backends since they already use SIGUSR1 and SIGUSR2. Attached is
a WIP patch for the mechanism to transmit multiple event notifications with
one signal. This mechanism would be useful for various uses, at least
I would use this for implementing synchronous replication.

In this patch,
* I put a bitmask field into PGPROC for the communication of event type
as advised by Tom in the above thread.
* I replaced CatchupInterruptHandler() by new signal handler for SIGUSR1,
adjusted the codes around "catchup interrupt" to this mechanism.
* remaining work is adjusting the comments around "catchup interrupt".

Comments welcome.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center