Tuesday, September 16, 2008

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

On Tue, Sep 16, 2008 at 8:43 PM, Ricardo Mendoza <pgsqlcol@gmail.com> wrote:
> No pongo en duda la eficiencia de su trabajo en responder ha la lista
> y demas contribuciones, lo que si cuestiono es su actitud al tratar a
> las personas, que de por si deja aun lado el trabajo que realiza, ¿de
> que te sirve un tipo que pueda hacer mucho en codigo y poco con las
> personas? de nada, ¿¿para que es postgres??, ¿para una maquina?,Noo
> para que una persona lo maneje, asi de sencillo. y ¿que es la lista?
> !!donde se encuentra la comunidad!! y si no puedes ser condendiente
> con un newbie, de que te sirve tener todos los meritos por hacer
> desarrollos, si lo haces pisoteando al mas debil de la comunidad. Es
> una regla simple de convivencia en la comunidad. Muy bien si sabes
> mucho, solo da las instrucciones,pero no tienes porque utilizar tu
> conocimiento para denigrar a las personas.
>
> Podra tener todos los meritos que quieras, hasta ser desarrollador,
> pero muchas veces la meritocracia se nutre del ego y se termina
> enalteciendo simplemente un hecho: los desarrollos, olvidando la
> integralidad: como lo haces junto a la comunidad, como tratas al mas
> vulnerable.
>
> Es tolerancia, lo que pido, respecto por las personas. Aunque en mi
> opinion deliberar en una comunidad no es perder el tiempo, porque
> muchas de las cosas que afectan a la misma tienen su origen ahi, en
> que se obstaculiza la accion de sus miembros, arraigados en la
> supuesta idoneidad de la cabeza, es por sus miembros que la comunida
> se debe y existe, y si un miembro trata asi, al menos experimentado,
> que podemos experar de el. solo despotismo.
>
> Sin el animo de ser protagonista, vengo realizando mi trabajo de
> traduccion localmente, pero no se trata de competir, o buscar el
> reconocimiento.
> lo hago por la necesidad de aprender, y crei que podria ser dinamizada aqui.
>
> Solo quiero señalar eso, no cambiar el proposito de la lista y muchos
> se enojaran por hacer esta aclaracion por que han sido domesticado a
> solo preguntar y recibir la solucion a sus problemas en la lista, sin
> realizar ningun esfuerzo por aprender y solucionar por sus propios
> medios una situacion. pero aun asi mucho veran mal que se diga esto
> aqui.
> --
> TIP 10: no uses HTML en tu pregunta, seguro que quien responda no podrá leerlo
>

Disculpen todos, pero solo para contextualizarme y entender tu
molestia hacia quien estas apuntando, pregunto porque me llego tu
primer correo sin hilo ni nada por el estilo, en todo caso yo
encuentro sano que se discutan temas extra tecnicos, pero tb entiendo
que existan miembros que se molesten al recibirlos.

En todo caso mi vision sin atacar personas es que en terminos
generales aqui existe un concepto de comunidad interesante,salvo
contadas excepciones, se ayuda y se entrega conocimiento a los que
preguntan (si bueno, este ultimo tiempo se han dado excepciones de
sarcasmos, y otras yerbas, pero bueno en la medida que las comunidades
crecen al igual que las sociedades, estos conflictos nacen y tenemos
que aprender a lidiar con ellos o no??? )

En terminos personales pido calma, si nos vamos a embarcar en un
proyecto de traduccion no le demos vueltas a comentarios viserales que
lo unico que hacen es desanimar, y truncar energias, por el bien de
cada lector avancemos, definamos plazos, responsables, tareas , etc
..

Creo que se habia avanzado en el tema he leido atentamente los correos
del proyecto de traduccion, no he respondido porque lo que se esta
tratando hasta ahora (compra de dominio, plataforma, responsable de
site, etc) se escapa de mis tiempos y aportes.

Como en algun momento a alguien le dije "Guarden las armas, y atras
sin golpes" avancemos!! :0)

Slds.

J.

--
Cumprimentos
jchavez
linux User #397972 on http://counter.li.org/
--
TIP 3: Si encontraste la respuesta a tu problema, publícala, otros te lo agradecerán

Re: [HACKERS] EXEC_BACKEND

Simon Riggs <simon@2ndQuadrant.com> writes:
> We keep talking about EXEC_BACKEND mode, though until recently I had
> misunderstood what that meant. I also realised that I have more than
> once neglected to take it into account when writing a patch - one recent
> patch failed to do this.

> I can't find anything coherent in docs/readme/comments to explain why it
> exists and what its implications are.

It exists because Windows doesn't have fork(), only the equivalent of
fork-and-exec. Which means that no state variables will be inherited
from the postmaster by its child processes, and any state that needs to
be carried across has to be handled explicitly. You can define
EXEC_BACKEND in a non-Windows build, for the purpose of testing code
to see if it works in that environment.

regards, tom lane

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

Re: [GENERAL] Question about indexes

As I told you, I use to design indexes based upon the queries, the WHERE
clauses especially.

My fear is that in PGSQL the runtime "index composition" can be a drawback to
the performances if compared to "static index composition".

Is this true accordingly to your experience?
Is there any "best common practice" for this issue in PGSQL?

Thanks again.

On Tuesday 16 September 2008 20:41:22 Scott Marlowe wrote:
> On Tue, Sep 16, 2008 at 12:24 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
> > On Tue, Sep 9, 2008 at 10:52 AM, regme please <regmeplease@gmail.com>
wrote:
> >> Hi all.
> >> I usually create indexes accordingly to the queries used in my software.
> >> This means the more often than not I have composited indexes over more
> >> than one column.
> >> What'd be in PGSQL (v8.3+) the pros and cons of having instead only
> >> one-column indexes?
> >> Thanks in advance.
> >
> > Pro:
> > Fewer number of smaller well traveled indexes (more efficient from
> > cache perspective).
> >
> > Con:
> > Operations that look up multiple fields simultaneously run slower
> > (sometimes much slower).
> >
> > Note that when reviewing sql written by other people in the
> > performance list, probably the most common optimization suggestion is
> > to use composite indexes.
>
> The other, closely related optimization is functional indexes. If you
> need to look up stuff based on date_trunc() then create indexes on
> that. Next I'd say partial indexes.

--
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] [HACKERS] Infrastructure changes for recovery

Simon Riggs <simon@2ndQuadrant.com> wrote:
> Testing takes a while on this, I probably won't complete it until
> Friday. So enclosed patch is for eyeballs only at this stage.

What's the status on that patch?

regards, tom lane

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

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

No pongo en duda la eficiencia de su trabajo en responder ha la lista
y demas contribuciones, lo que si cuestiono es su actitud al tratar a
las personas, que de por si deja aun lado el trabajo que realiza, ¿de
que te sirve un tipo que pueda hacer mucho en codigo y poco con las
personas? de nada, ¿¿para que es postgres??, ¿para una maquina?,Noo
para que una persona lo maneje, asi de sencillo. y ¿que es la lista?
!!donde se encuentra la comunidad!! y si no puedes ser condendiente
con un newbie, de que te sirve tener todos los meritos por hacer
desarrollos, si lo haces pisoteando al mas debil de la comunidad. Es
una regla simple de convivencia en la comunidad. Muy bien si sabes
mucho, solo da las instrucciones,pero no tienes porque utilizar tu
conocimiento para denigrar a las personas.

Podra tener todos los meritos que quieras, hasta ser desarrollador,
pero muchas veces la meritocracia se nutre del ego y se termina
enalteciendo simplemente un hecho: los desarrollos, olvidando la
integralidad: como lo haces junto a la comunidad, como tratas al mas
vulnerable.

Es tolerancia, lo que pido, respecto por las personas. Aunque en mi
opinion deliberar en una comunidad no es perder el tiempo, porque
muchas de las cosas que afectan a la misma tienen su origen ahi, en
que se obstaculiza la accion de sus miembros, arraigados en la
supuesta idoneidad de la cabeza, es por sus miembros que la comunida
se debe y existe, y si un miembro trata asi, al menos experimentado,
que podemos experar de el. solo despotismo.

Sin el animo de ser protagonista, vengo realizando mi trabajo de
traduccion localmente, pero no se trata de competir, o buscar el
reconocimiento.
lo hago por la necesidad de aprender, y crei que podria ser dinamizada aqui.

Solo quiero señalar eso, no cambiar el proposito de la lista y muchos
se enojaran por hacer esta aclaracion por que han sido domesticado a
solo preguntar y recibir la solucion a sus problemas en la lista, sin
realizar ningun esfuerzo por aprender y solucionar por sus propios
medios una situacion. pero aun asi mucho veran mal que se diga esto
aqui.
--
TIP 10: no uses HTML en tu pregunta, seguro que quien responda no podrá leerlo

Re: [HACKERS] Common Table Expressions (WITH RECURSIVE) patch

Jeff Davis <pgsql@j-davis.com> writes:
> I think the right approach is to try to complete it so that everyone is
> happy. I will work on this, but unfortunately I don't have a lot of time
> right now, so I can't make any promises.

I think there are two significant bits there:

* Fixing the parsetree representation so that the distinction between
a CTE and an RTE that references the CTE is preserved.

* Implementing some kind of "multiple readout tuplestore" to permit
multiple RTEs to scan a CTE plan without causing any row to be
evaluated more than once.

The first of these seems relatively straightforward: the WITH clause
has to be preserved explicitly in the Query representation, and RTEs
for CTEs should just carry indexes into the WITH list, not copies of
the subqueries. (Hm, we might need both an index and a levelsup
counter, to deal with nested queries...) This would solve ruleutils'
problem, too.

I haven't thought much about the multiple readout tuplestore though.
Anyone have a clear idea how to do that? In particular, can the
existing tuplestore code be enhanced to do it (without sacrificing
performance in the simple case), or do we need something new?

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

[HACKERS] EXEC_BACKEND

We keep talking about EXEC_BACKEND mode, though until recently I had
misunderstood what that meant. I also realised that I have more than
once neglected to take it into account when writing a patch - one recent
patch failed to do this.

I can't find anything coherent in docs/readme/comments to explain why it
exists and what its implications are. The why is "Windows", AFAICS, but
the full implications are far from clear in my blissful, mostly
Window-less world.

Can someone either point me to or write a coherent explanation of this,
so that we can add it to the code somewhere handy? I want to make sure
that everything I'm working on covers the main points the first time I
wrote code.

Thanks,

--
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: [GENERAL] foreign key problem

Brent Wood
DBA/GIS consultant
NIWA, Wellington
New Zealand
>>> Jorge Godoy <jgodoy@gmail.com> 09/17/08 1:36 AM >>>
Em Monday 15 September 2008 19:05:25 pcreso@pcreso.com escreveu:
> Hi,
>
> I need a foreign key (or equivalent) where the referenced table cannot have
> a unique constraint.
>
> For fisheries surveys we have a table of catch records. For a given event,
> several species are caught, and are weighed by one or more methods. Thus a
> given event may have more than one record for the same spaecies, as parts
> of the catch may be weighed differently.
>
> When we sample a species for measuring, the event is recorded, but as the
> sample may include individuals from throughout the catch, it does not
> necessarily relate to the catch-with-method table.

Looks like you need a composite primary key here, i.e. a primary key for the
"category" of the record will have more than one column (such as species and
method of catch).

With that you'll be able to uniquely identify the "event" and then associate
it with the record.


Thanks Jorge,

There are many catches per event, one for each species/method, so a composite key would be on event/species/method for the catch.

For lengths it would be on event/species (there is no catch weigh method here). There should only be a length record for a matching event/species in the catch (normally constrained via a foreign key) but I cannot create a composite key on catch without including method, so there is no possible unique key on catch to match to the primary key on length.


--
Jorge Godoy <jgodoy@gmail.com>


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

Re: [ADMIN] Help request: how to tune performance?

On Tue, Sep 16, 2008 at 11:10:01AM -0600, Scott Marlowe wrote:
> On Tue, Sep 16, 2008 at 2:31 AM, Mauri Sahlberg
> <Mauri.Sahlberg@claymountain.com> wrote:
> > Hi,
> >
> > We just upgraded Best Practical's RT from 3.6 to 3.81 and gave the
> > database completely own machine. And the users still complain that it is
> > dog slow.
>
> Moved up from below:
>
> > Version : 8.1.11 Vendor: CentOS
>
> So, you built it its own machine, but you didn't upgrade to at least 8.2?
>
> Last place I worked we ran rt 3.6.1 and got a noticeable performance
> boost from switching to 8.2 but the only thing that was ever really
> slow was viewing the rather large approval queue.
>
> > :-( I installed pg_top and it seems that at the beginning of
> > the ticket display RT-issues a query that eats everything the database
> > has. Query is as follows:
> >
> > SELECT DISTINCT main.* FROM Users main CROSS JOIN ACL ACL_2 JOIN
> > Principals Principals_1 ON ( Principals_1.id = main.id ) JOIN
> > CachedGroupMembers CachedGroupMembers_3 ON
> > ( CachedGroupMembers_3.MemberId = Principals_1.id ) WHERE
> > (Principals_1.Disabled = '0') AND (ACL_2.PrincipalId =
> > CachedGroupMembers_3.GroupId) AND (Principals_1.id != '1') AND
> > (ACL_2.PrincipalType = 'Group') AND (Principals_1.PrincipalType =
> > 'User') AND (ACL_2.RightName = 'OwnTicket') AND ((ACL_2.ObjectType =
> > 'RT::Queue' AND ACL_2.ObjectId = 18) OR (ACL_2.ObjectType =
> > 'RT::System')) ORDER BY main.Name ASC
>

What is your version of DBIx-SearchBuilder? In particular, the
DISTINCT definition was changed from:

$$statementref = "SELECT DISTINCT main.* FROM $$statementref";

to:

$$statementref = "SELECT main.* FROM ( SELECT DISTINCT main.id FROM $$statementref ) distinctquery, $table main WHERE (main.id = distinctquery.id) ";

You can change the line in your version of SearchBuilder and restart
RT with a cache flush to get approximately the same benefit.

Ken

--
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] Setting Effective Cache Size

On Tue, Sep 16, 2008 at 9:30 AM, kevin kempter
<kevin@kevinkempterllc.com> wrote:
> Hi All;
>
> Is there an easy way to determine the actual OS disk cache size or at least
> a set of guidelines based on the OS and disk subsystem type ?

On a DB only machine, you can expect the OS to use most of the spare
memory for disk cache eventually. So, if you've got a 16Gig machine
and pgsql and the OS are using ~ 2 Gigs or so, the effective cache
size will be what's left.

OTOH, if the machine does other things (file / print server, web
server, etc...) then you kinda have to fudge factor it. Generally
pgsql will still use more disk cache than those other things, due to
having more disk access going on all the time, but really it depends
on your usage patterns.

Luckily Effective cache size is a big course knob so being off by a
gig or three isn't a really big deal.

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

[pgsql-advocacy] PHP Quebec call for speakers

Folks,

The organizers of the conference approached me about getting more
PostgreSQL+PHP speakers. Don't reply to me, contact them. Deadline is
October 18.

==========

Title : 2009 PHP Quebec Conference Call for Papers
Description:
=================
PHP Quebec is pleased to announce the seventh edition of the PHP
Quebec Conference. The Conference will take place in Montreal,
Canada between March 4 and 6th, 2009. We are looking for speakers
willing to share their expertise with Canadian and United States PHP
professionals.

The Conference features technical talks and Labs dedicated to advanced
software development techniques with PHP5 and PHP6, XML, web services,
databases, etc., project management where speakers and visitors
will try to find solutions to actual business problems.

With events such has the PHPLab, the Job Fair and the Cocktail, the
Conference
will be a great opportunity to meet with local experts, Core PHP Developers
and sponsors.

For more information, visit the website:
http://conf.phpquebec.com
==================

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

Re: [GENERAL] Question about indexes

On Tue, Sep 16, 2008 at 12:24 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
> On Tue, Sep 9, 2008 at 10:52 AM, regme please <regmeplease@gmail.com> wrote:
>> Hi all.
>> I usually create indexes accordingly to the queries used in my software.
>> This means the more often than not I have composited indexes over more than
>> one column.
>> What'd be in PGSQL (v8.3+) the pros and cons of having instead only
>> one-column indexes?
>> Thanks in advance.
>
> Pro:
> Fewer number of smaller well traveled indexes (more efficient from
> cache perspective).
>
> Con:
> Operations that look up multiple fields simultaneously run slower
> (sometimes much slower).
>
> Note that when reviewing sql written by other people in the
> performance list, probably the most common optimization suggestion is
> to use composite indexes.

The other, closely related optimization is functional indexes. If you
need to look up stuff based on date_trunc() then create indexes on
that. Next I'd say partial indexes.

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

Franz Marin escribió:
> la intruccion que ejecute fue
>
> /usr/local/pgsql/bin/pg_ctl -D /datos1/interaseo/db/ restart
>
> despues de un momento me dice proceso fallido y desde ahi no me deja
> conectar a la db
>
> la versiion de postgres es 8.2.4 y el sistema operativo es linux white
> box
>
>
>
> --------------------------------------------------
> From: "TeófiloOviedo" <teus79@active.com.py>
> Sent: Monday, September 15, 2008 3:41 PM
> To: "Franz Marin" <frarimava@hotmail.com>
> Cc: "Lista Postgres ES" <pgsql-es-ayuda@postgresql.org>
> Subject: Re: [pgsql-es-ayuda] ayuda
>
>> Franz,
>>
>> Sería recomendable que indiques tu sistema operativo, la versión de tu
>> postgres y qué pasos hiciste para que te salga ese error.
>>
>> De otro modo... por mi parte no he estudiado adivinanzas.
>>
>>
>> El lun, 15-09-2008 a las 15:36 -0500, Franz Marin escribió:
>>> buenas tardes tengo un problema cuando me voy a conectar al servidor
>>> de mi base de datos me saca el siguiente error
>>>
>>> error connecting to the server: FATAL el sistema de base de datos esta
>>> apagandose
>>>
>>>
>>> que puedo hacer
>> --
>> Teófilo Oviedo
>> ACTIVE S.R.L.
>> http://www.active.com.py
>>
>>
> --
> TIP 6: �Has buscado en los archivos de nuestra lista de correo?
> http://archives.postgresql.org/pgsql-es-ayuda
>
Hola , podes mandar el log?

Saludos Fernando

--
TIP 8: explain analyze es tu amigo

Re: [HACKERS] Common Table Expressions (WITH RECURSIVE) patch

Tatsuo Ishii <ishii@postgresql.org> writes:
> Included is the latest patches against CVS HEAD.

I spent some time reading this patch. Here are a few comments in
no particular order:

RangeRecursive node lacks copyfuncs/equalfuncs support.

Query.recursive is missed in equalfuncs.c. But rather than fix that,
get rid of it entirely. AFAICS the only use is in qual_is_pushdown_safe,
and what is the value of that test? The callers know perfectly well
whether they are operating on a recursive RTE or not. You might as well
just delete all the useless qual-pushdown-attempt code from
set_recursion_pathlist, and not need to touch qual_is_pushdown_safe
at all.

Is physical_tlist optimization sensible for RecursiveScan? We seem
to use it for every other Scan node type.

I dislike putting state into ExecutorState; that makes it impossible
to have multiple recursion nodes in one plan tree. It would probably
be better for the Recursion and RecursiveScan nodes to talk to each
other directly (compare HashJoin/Hash); although since they are not
adjacent in the plan tree I admit I'm not sure how to do that.

es_disallow_tuplestore doesn't seem to need to be in ExecutorState
at all, it could as well be in RecursionState.

I don't really like the way that Append nodes are being abused here.
It would be better to allow nodeRecursion.c to duplicate a little code
from nodeAppend.c, and have the child plans be direct children of
the Recursion node. BTW, is it actually possible to have more than
two children? I didn't spend enough time analyzing the restrictions
in parse_cte to be sure. If there are always just two then you could
simplify the representation by treating it like a join node instead
of an append. (The RTE_RECURSIVE representation sure makes it look
like there can be only two...)

Mark/restore support seems useless ... note the comment on
ExecSupportsMarkRestore (which should be updated if this code
isn't removed).

RecursiveScan claims to support backwards fetch, but does not in fact
contain code to do so. (Given that it will always be underneath
Recursion, which can't do backwards fetch, I see little point in adding
such code; fix execAmi.c instead.)

ExecInitRecursion doesn't seem to be on the same page about whether
it supports backward scan as execAmi.c, either.

This comment in nodeRecursivescan.c seems bogus:
/*
* Do not initialize scan tuple type, result tuple type and
* projection info in ExecInitRecursivescan. These types are
* initialized after initializing Recursion node.
*/
because the code seems to be doing exactly what the comment says it
doesn't.

Numerous comments appear to have been copied-and-pasted and not modified
from the original. Somebody will have to go over all that text.

ruleutils.c fails completely for non-recursive WITH. It *must* regenerate
such a query with a WITH clause, not as a flattened subquery which is what
you seem to be doing. This isn't negotiable because the semantics are
different. This will mean at least some change in the parsetree
representation. Perhaps we could add a bool to subquery RTEs to mark them
as coming from a nonrecursive WITH? The tests added for RTE_RECURSIVE
seem a bit ugly too. If it thinks that can't happen it should Assert so,
not just fall through silently.

commentary for ParseState.p_ctenamespace is gratuitously unlike the
comment style for the other fields, and p_recursive_namespace isn't
documented at all.

ParseState.p_in_with_clause is unused, should be removed.

The WithClause struct definition is poorly commented. It should be
stated that it is used only pre-parse-analysis (assuming that continues
to be true after you get done fixing ruleutils.c...), and it doesn't
say what the elements of the subquery list are (specifically, what
node type). A lot of the other added structs and fields could use
better commenting too.

For that matter "subquery" is a poor name for WithClause's list of CTEs,
especially so since it's hard to search for. It should be a plural name
and I'd be inclined to use something like "ctes" not "subqueries".
The term "subquery" is too overloaded already, so any place you can
refer to a WITH-list member as a CTE you should do so.

WithClause node may need a location field, and almost certainly has to
be handled somehow in exprLocation().

The error reports in parse_cte.c *desperately* need error locations.

Why does transformWithClause do parse_sub_analyze twice?
I'm not sure that's even safe, and it's surely unnecessary.
Also, what happens if a subquery isn't a SelectStmt? Silently
doing nothing doesn't seem like a good plan there.

Why are we putting essentially the same information into both
p_recursive_namespace and p_ctenamespace? Is there really a need
for both lists? The code added to transformFromClauseItem
seems quite wrong since it searches both lists even if it found a
match in the first one. This whole area looks like it needs
refactoring.

Costing is all bogus, but we knew that...

Why does set_recursion_pathlist think that the subquery might have
useful pathkeys? We know it must always be a UNION ALL, no?

PlanState.has_recursivescan seems like a complete kluge. Can't it just be
removed? It looks to me like it is working around bugs that hopefully aren't
there anymore. There is certainly no reason why a recursive CTE should be
more in need of rescanning than any other kind of plan. If it is needed then
the current implementation is completely broken anyway, since it would only
detect a RecursiveScan node that is directly underneath an agg or hash node.

Please pay some attention to keeping things in logical, consistent orders.
For instance the withClause field was inserted into _copySelectStmt()
in a different place from where it was inserted in the actual struct
declaration, which is confusing.

parseTypeString() ought to check for null withClause.

expression_tree_walker/mutator support seems entirely broken for
RTE_RECURSIVE RTEs. Shouldn't it be recursing into the subquery?

Missed adding non_recursive_query to the "zap unneeded substructure" part
of set_plan_references (assuming it really is unneeded).

There seem to be quite a number of places where RTE_SUBQUERY RTEs
are handled but the patch fails to add RTE_RECURSIVE handling ...

It's a really bad idea to use RTE subquery field over again for
RTE_RECURSIVE, especially without any comment saying you did that.
I would suggest two pointers in the RTE_RECURSIVE field list instead.

Do we really have to make RECURSIVE a fully reserved keyword?
(Actually, the patch makes it worse than reserved, by failing to
add it to the reserved_keywords list.)

checkCteTargetList is completely broken: it will only notice illegal
sublinks that are at the very top level of a targetlist expression.
checkWhereClause is very far short of adequate as well. Need to recurse
here, or find some other way. Given that the subexpressions haven't been
analyzed yet, this seems a bit messy --- expression_tree_walker doesn't
know about pre-analysis node trees, so you can't use it. I'd suggest
replacing this whole set of routines with just one recursive routine that
doesn't make pre-assumptions about which node types can be found where.
Alternatively, is there any way of delaying the validity checks until
*after* parse analysis of the expressions, so that you could use
expression_tree_walker et al?

BTW, it seems like a lot of the logic there could be simplified by depending
on the enum ordering RECURSIVE_OTHER > RECURSIVE_SELF > NON_RECURSIVE.
There are a number of places that are taking the larger of two values
in baroque, hard-to-follow ways.

I wonder if checkCteSelectStmt is detecting nonlinearity correctly.
Since RECURSIVE_OTHER dominates RECURSIVE_SELF, couldn't it fail to
miss the problem in something like (self union (self union other)) ?
Maybe what you really need is a bitmask:
NON_RECURSIVE = 0,
RECURSIVE_SELF = 1,
RECURSIVE_OTHER = 2,
RECURSIVE_BOTH = 3 /* the OR of RECURSIVE_SELF and RECURSIVE_OTHER */
and then you can merge two values via OR instead of MAX.

regards, tom lane

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

Re: [GENERAL] Question about indexes

On Tue, Sep 9, 2008 at 10:52 AM, regme please <regmeplease@gmail.com> wrote:
> Hi all.
> I usually create indexes accordingly to the queries used in my software.
> This means the more often than not I have composited indexes over more than
> one column.
> What'd be in PGSQL (v8.3+) the pros and cons of having instead only
> one-column indexes?
> Thanks in advance.

Pro:
Fewer number of smaller well traveled indexes (more efficient from
cache perspective).

Con:
Operations that look up multiple fields simultaneously run slower
(sometimes much slower).

Note that when reviewing sql written by other people in the
performance list, probably the most common optimization suggestion is
to use composite indexes.

merlin

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

Re: [BUGS] BUG #4418: Memory leak in query planner

On Tue, 2008-09-16 at 00:37 +0000, michael McMaster wrote:
> I intend on creating a view over a large number of tables (possibly > 1000).
> Each table in the view has a CHECK constraint that partitions the data by a
> time range.

You may try using the inheritance mechanism rather than a UNION ALL
view.

Regards,
Jeff Davis


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

[lapug] Fwd: [Attendees] Registration for West is now open

FYI,

I wanted to pass this email along to anyone that might like to attend
a PG conference. I found that total cost of attendance can be
reduced by getting a roommate. In addition to the
postgresqlconference.org, there is a pg conference mailing list that
is a good source of information.


---------- Forwarded message ----------
From: Joshua Drake <jd@commandprompt.com>
Date: Mon, Sep 15, 2008 at 9:30 AM
Subject: [Attendees] Registration for West is now open
To: attendees@lists.postgresqlconference.org


Hello,

The time is upon us again. PostgreSQL Conference: West registration is
now open! You can see a list of talks and tutorials here:

http://www.pgcon.us/west08/talks/

Talks are still being submitted but you may now sign up to attend here:

http://www.postgresqlconference.org/west08/register

There is information on location and hotel here:

http://www.postgresqlconference.org/west08/where/

Look forward to seeing you there!

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


_______________________________________________
Attendees mailing list
Attendees@lists.postgresqlconference.org
http://lists.postgresqlconference.org/mailman/listinfo/attendees

--
Regards,
Richard Broersma Jr.

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

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

Re: [GENERAL] Question about indexes

Any hint?

> Hi all.
> I usually create indexes accordingly to the queries used in my software.
> This means the more often than not I have composited indexes over more than
> one column.
> What'd be in PGSQL (v8.3+) the pros and cons of having instead only
> one-column indexes?
> Thanks in advance.
>
> RMP.

--
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] Subtransaction commits and Hot Standby

On Tue, 2008-09-16 at 11:08 -0400, Alvaro Herrera wrote:
> Simon Riggs wrote:
>
> > Perhaps it is sufficient to throw an error if the subxid cache
> > overflows? But I suspect that may not be acceptable...
>
> Certainly not.

Yeh :-) ... it was just a rhetorical question. I'll try to avoid those.

--
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: [GENERAL] about partitioning

Hello all,


still with partitioning...

wheter I use rules or triggers is there a way for me _not_ to specify
field-by-field all the fields I wish to be redirected to the
child-table...


as example:

instead of this:
---------------------------------------------------------
create rule insert_t_1 AS ON INSERT TO teste WHERE (t>=1000 and t<2000)
DO INSTEAD INSERT INTO t_1 VALUES (NEW.t, NEW.s1, NEW.s2 NEW.s3, NEW.s4
NEW.s5, NEW.s6, NEW.s7, NEW.s8);
---------------------------------------------------------

something like this:
---------------------------------------------------------
create rule insert_t_1 AS ON INSERT TO teste WHERE (t>=1000 and t<2000)
DO INSTEAD INSERT INTO t_1 VALUES (__ALL__);
---------------------------------------------------------

of course this assumes that the child table inherits all fields from the
parent table _and_ has no extra fields which is exactly my case.

any hints.

thx
j


On Sat, 2008-09-13 at 16:48 -0400, Robert Treat wrote:
> On Thursday 11 September 2008 07:47:00 Joao Ferreira gmail wrote:
> > Hello all,
> >
> > my application is coming to a point on which 'partitioning' seems to be
> > the solution for many problems:
> >
> > - query speed up
> > - data elimination speed up
> >
> > I'dd like to get the feeling of it by talking to people who use
> > partitioning, in general..
> >
> > - good, bad,
>
> good :-)
>
> > - hard to manage, easy to manage,
>
> I think the upfront costs for managing a partitioning setup are higher with
> postgres than other systems, but there is nothing that you shouldn't be able
> to automate in a cron script (at which point management becomes easy), plus
> postgres gives you some interesting flexibility that is harder to find in
> other setups.
>
> > - processing over-head during INSERT/UPDATE,
>
> you can setup inserts to have relativly little overhead, but it requires more
> management/maintence work up front. Updates within a partition also have
> relativly little extra overhead, especially if you put in a little
> application logic to figure out how to work on a partition directly. Updates
> where you are changing the partition key value are always more problematic
> though.
>
> > - stability/compatibility of pg_dump and restore operations,
>
> no real issues here as long as your on recent enough versions to do wildcard
> table matching for individual tables.
>
> > - how many partitions would be reasonable for read _and_ write access
> > optimal speed;
> >
>
> again, this depends on how exactly your working on the data. For example, we
> have tables with over a thousand partitions on them; in those scenarios all
> data is written into a single partition (with a new partition created daily),
> and the qeury patterns are really straightforward... last month gets a lot of
> queries, lasat three months not so much, last year barely any, and beyond
> that is pretty much just archive info. That said, we have other systems where
> that wouldnt work at all (for example, a static number of partitions, all of
> which are queried activly).
>
> For some more info, I've given at least one presentation on the topic, which
> seems to be missing from the omniti site, but I've uploaded it to
> slideshare...
> http://www.slideshare.net/xzilla/postgresql-partitioning-pgcon-2007-presentation
>
> HTH.
>


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

On Tue, Sep 16, 2008 at 8:37 AM, Guido Barosio <gbarosio@gmail.com> wrote:
> On Tue, Sep 16, 2008 at 1:41 AM, Vivek_Sharan <Vivek_Sharan@infosys.com> wrote:
>> Thanks for the information so far

OK, I'm not BSD expert (Tom Lane might help out here) but I'm guessing
that what we see in the following lines of top:

>> 87340 postgres 2 0 7200K 1224K select 0 1:41 0.00% 0.00% postgres
>> 90961 postgres 2 0 83580K 76008K sbwait 0 0:30 0.00% 0.00% postgres
>> 90920 postgres 2 0 83636K 76068K sbwait 0 0:29 0.00% 0.00% postgres

Is that the number on the left, like 83636K is the total memory used,
and the number to the right 76068K is how much is shared buffers
etc... which would mean that each of those processes above are using
about 7 megs a piece, and the rest is repeated.

--
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] Subtransaction commits and Hot Standby

On Tue, 2008-09-16 at 15:38 +0100, Simon Riggs wrote:
> On Tue, 2008-09-16 at 17:01 +0300, Heikki Linnakangas wrote:
> > Simon Riggs wrote:
> > > Subtransactions cause a couple of problems for Hot Standby:
> >
> > Do we need to treat subtransactions any differently from normal
> > transactions? Just treat all subtransactions as top-level transactions
> > until commit, and mark them all as committed when you see the commit
> > record for the top-level transaction.
>
> If we do that, snapshots become infinitely sized objects though, which
> then requires us to invent some way of scrolling it to disk. So having
> removed the need for subtrans, I then need to reinvent something similar
> (or at least something like a multitrans entry).

Currently we keep track of whether the whole subxid cache has
overflowed, or not. It seems possible to track for overflows of
individual parts of the cache. That makes the code path for subxid
overflow in GetSnapshotData() slightly slower, but it's not the common
case. We save time elsewhere in more common cases.

We would be able to avoid making an entry in subtrans for new subxids
unless our local backend has overflowed its cache. That will reduce
subtrans access frequency considerably and greatly reduce the number of
requests that might need to perform I/O, possibly to zero. It would also
avoid the need for generating WAL records for new subxids for standby.

The path thru XidInMVCCSnapshot() would then require us to *always*
check the subxid cache, even if it has overflowed. If we find the xid
then we don't need to check subtrans at all. That's quite useful because
searching the subxid cache is cheaper than looking in subtrans and the
probability it would be there rather than in subtrans is still good,
even for overflows of up to 3-5 times the subxid cache. It would
increase the cost of subxid checking slightly when running with very
high numbers of subxids.

For Hot Standby, this would mean we could avoid generating WAL records
for new subxids in most cases - only generate them when our backend's
subxid cache has overflowed. On the standby it then means we can store
xids into a fixed size snapshot without worrying about whether it
overflows because the xids all fitted in the snapshot on the master
(whose xids we are emulating), *or* we have a WAL record that tells us
the cache overflowed and we make the insert into subtrans instead. When
we use the standby snapshot we look in subxid cache first and if we
don't find it then we check in subtrans.

Sounds possible?

--
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: [GENERAL] [LIKELY_SPAM]Re: Oracle and Postgresql

Jon.Roberts@asurion.com ("Roberts, Jon") writes:
> 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.

That's not the point.

The question isn't whether they buy *Oracle* or not, as the sales
figures obviously indicate that they do.

The question is whether or not the actually get the 10 things that you
named.

I don't expect that they actually get all 10 of them, nor that they
get particularly close to getting all 10 of them.

>> There certainly are a lot of false perceptions out in the world about
>> Oracle, and about proprietary software in general.
>>
>> > 1. 24x7 Support
>>
>> At several different places over the years, I've seen their top-tier
>> support simply not respond.
>>
> That is highly unusual. I've always had excellent experience with
> Oracle's support especially their top tier support.

I can't comment on that usefully.

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

Fortunately for sales, perception is much more important than reality.
The customers may not be *getting* better or more-quickly-available
security patches, but if they feel more comfortable, they may be
happier.

>> > Row Level Security,
>>
>> I think you mean access control. Access control has so little overlap
>> with security that they really need to be discussed as separate
>> subjects.
>>
>> > Roles,
>>
>> We have 'em.
>>
>> > encryption,
>>
>> We have it.
>>
> PG can't encrypt code.

It's not evident that "encrypting code" actually provides security.
In order for the code to *run*, any encryption keys need to reside
some place accessible by the server, which therefore implies that the
keys are accessible to operations staff.

This is a common problem with the use of encryption.

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

Is this truly a security hole?

It is not at all evident to me that this indicates a security hole,
and simply asserting this to be so does not make it so.

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

SCO *lost* their case, and got slapped down plenty hard enough by
people intent on doing so that SCO no longer represents any sort of
example, aside from being an example that "in the Land of the
Litigious, anyone with deep pockets can potentially sue anyone over
anything," which isn't useful guidance.

You haven't pointed to any case law.

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

And you can't prove it without breaking contracts that were signed
promising not to publish results, so you don't have any *useful*
proof.

>> > 5. Works extremely well from anything from hosting LDAP to OLTP
>> > applications to data warehouses with ROLAP and MOLAP
>>
>> Now we're vaguely getting somewhere within shouting range of reality.
>> While the first half of that is hotly debatable, they've got decent
>> *OLAP.
>>
> Oracle Internet Directory is LDAP compliant and stored in an Oracle
> database. They have rollback which provides similar MVCC functionality
> of PG. It has also been around longer than PG MVCC.

Stone tablets have been around longer than MVCC, but that's not an
example of anything.

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

You set a much higher bar than that. You claimed it was best, oldest,
and most proven in concurrency model.

>> > 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.
>
>> > 8. Recruiting a senior level Oracle professional with over 10 years
>> > of experience is not very difficult
>>
>> Finding somebody with 10 years' experience is no problem. Finding
>> somebody half-way competent is a different story.
>>
>> > 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?

It's *ALL* about perception, indeed. All 10 items you mention are, to
the extent that they are *perceived* to be true, a victory of
perception over reality.

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

There's the old tale of the "lady of the evening" who offered to "do
anything" for $100, and the gentleman in question said, "Great! My
house needs painting!"

Unfortunately, "do anything" has some questionable ethical
implications, and "hookers and blow" *do* lie down that road :-(.

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

100% agreed.

But we're not sales people, so we're not overly interested in that
reality.

We're much more interested in the technical realities.
--
output = ("cbbrowne" "@" "acm.org")
http://linuxfinances.info/info/linuxxian.html
Rules of the Evil Overlord #64. "I will see a competent psychiatrist
and get cured of all extremely unusual phobias and bizarre compulsive
habits which could prove to be a disadvantage."
<http://www.eviloverlord.com/>

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

Re: [GENERAL] Help with a foreign key with non-unique reference?

On Tue, 16 Sep 2008, Brent Wood wrote:

> I need a foreign key (or equivalent) where the referenced table cannot
> have a unique constraint.

Well, do you need a full foreign key or just the insert-time check on the
referencing table? Does the referenced table get updates or deletes that
you want to watch for, and do you want those to error or to do the
equivalent of one of the referential actions?

For the insert-time check only if you don't care about deletes or updates
to the referenced table, a trigger that checks for existance is probably
good enough.

--
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] Subtransaction commits and Hot Standby

Index: src/backend/access/transam/transam.c
===================================================================
RCS file: /home/sriggs/pg/REPOSITORY/pgsql/src/backend/access/transam/transam.c,v
retrieving revision 1.76
diff -c -r1.76 transam.c
*** src/backend/access/transam/transam.c 26 Mar 2008 18:48:59 -0000 1.76
--- src/backend/access/transam/transam.c 16 Sep 2008 16:55:30 -0000
***************
*** 287,317 ****
return false;
}

-
- /*
- * TransactionIdCommit
- * Commits the transaction associated with the identifier.
- *
- * Note:
- * Assumes transaction identifier is valid.
- */
- void
- TransactionIdCommit(TransactionId transactionId)
- {
- TransactionLogUpdate(transactionId, TRANSACTION_STATUS_COMMITTED,
- InvalidXLogRecPtr);
- }
-
- /*
- * TransactionIdAsyncCommit
- * Same as above, but for async commits. The commit record LSN is needed.
- */
- void
- TransactionIdAsyncCommit(TransactionId transactionId, XLogRecPtr lsn)
- {
- TransactionLogUpdate(transactionId, TRANSACTION_STATUS_COMMITTED, lsn);
- }
-
/*
* TransactionIdAbort
* Aborts the transaction associated with the identifier.
--- 287,292 ----
***************
*** 328,359 ****
}

/*
- * TransactionIdSubCommit
- * Marks the subtransaction associated with the identifier as
- * sub-committed.
- *
- * Note:
- * No async version of this is needed.
- */
- void
- TransactionIdSubCommit(TransactionId transactionId)
- {
- TransactionLogUpdate(transactionId, TRANSACTION_STATUS_SUB_COMMITTED,
- InvalidXLogRecPtr);
- }
-
- /*
* TransactionIdCommitTree
* Marks all the given transaction ids as committed.
*
* The caller has to be sure that this is used only to mark subcommitted
* subtransactions as committed, and only *after* marking the toplevel
* parent as committed. Otherwise there is a race condition against
! * TransactionIdDidCommit.
*/
void
! TransactionIdCommitTree(int nxids, TransactionId *xids)
{
if (nxids > 0)
TransactionLogMultiUpdate(nxids, xids, TRANSACTION_STATUS_COMMITTED,
InvalidXLogRecPtr);
--- 303,335 ----
}

/*
* TransactionIdCommitTree
* Marks all the given transaction ids as committed.
*
* The caller has to be sure that this is used only to mark subcommitted
* subtransactions as committed, and only *after* marking the toplevel
* parent as committed. Otherwise there is a race condition against
! * TransactionIdDidCommit since we do not apply changes atomically, yet.
*/
void
! TransactionIdCommitTree(TransactionId commitxid, int nxids, TransactionId *xids)
{
+ /*
+ * Mark top level transaction id as committed first, to avoid
+ * race conditions with TransactionIdDidCommit
+ */
+ TransactionLogUpdate(commitxid, TRANSACTION_STATUS_COMMITTED,
+ InvalidXLogRecPtr);
+
+ /*
+ * If there is more than one subcommit, then we need to mark them
+ * subcommitted first to ensure there is no race condition where
+ * we might see a subtransaction as still in progress when it is
+ * now committed.
+ */
+ if (nxids > 1)
+ TransactionLogMultiUpdate(nxids, xids, TRANSACTION_STATUS_SUB_COMMITTED,
+ InvalidXLogRecPtr);
if (nxids > 0)
TransactionLogMultiUpdate(nxids, xids, TRANSACTION_STATUS_COMMITTED,
InvalidXLogRecPtr);
***************
*** 364,371 ****
* Same as above, but for async commits. The commit record LSN is needed.
*/
void
! TransactionIdAsyncCommitTree(int nxids, TransactionId *xids, XLogRecPtr lsn)
{
if (nxids > 0)
TransactionLogMultiUpdate(nxids, xids, TRANSACTION_STATUS_COMMITTED,
lsn);
--- 340,363 ----
* Same as above, but for async commits. The commit record LSN is needed.
*/
void
! TransactionIdAsyncCommitTree(TransactionId commitxid, int nxids, TransactionId *xids, XLogRecPtr lsn)
{
+ /*
+ * Mark top level transaction id as committed first, to avoid
+ * race conditions with TransactionIdDidCommit
+ */
+ TransactionLogUpdate(commitxid, TRANSACTION_STATUS_COMMITTED,
+ lsn);
+
+ /*
+ * If there is more than one subcommit, then we need to mark them
+ * subcommitted first to ensure there is no race condition where
+ * we might see a subtransaction as still in progress when it is
+ * now committed.
+ */
+ if (nxids > 1)
+ TransactionLogMultiUpdate(nxids, xids, TRANSACTION_STATUS_SUB_COMMITTED,
+ lsn);
if (nxids > 0)
TransactionLogMultiUpdate(nxids, xids, TRANSACTION_STATUS_COMMITTED,
lsn);
Index: src/backend/access/transam/twophase.c
===================================================================
RCS file: /home/sriggs/pg/REPOSITORY/pgsql/src/backend/access/transam/twophase.c,v
retrieving revision 1.45
diff -c -r1.45 twophase.c
*** src/backend/access/transam/twophase.c 11 Aug 2008 11:05:10 -0000 1.45
--- src/backend/access/transam/twophase.c 16 Sep 2008 16:47:21 -0000
***************
*** 1745,1753 ****
XLogFlush(recptr);

/* Mark the transaction committed in pg_clog */
! TransactionIdCommit(xid);
! /* to avoid race conditions, the parent must commit first */
! TransactionIdCommitTree(nchildren, children);

/* Checkpoint can proceed now */
MyProc->inCommit = false;
--- 1745,1751 ----
XLogFlush(recptr);

/* Mark the transaction committed in pg_clog */
! TransactionIdCommitTree(xid, nchildren, children);

/* Checkpoint can proceed now */
MyProc->inCommit = false;
Index: src/backend/access/transam/xact.c
===================================================================
RCS file: /home/sriggs/pg/REPOSITORY/pgsql/src/backend/access/transam/xact.c,v
retrieving revision 1.265
diff -c -r1.265 xact.c
*** src/backend/access/transam/xact.c 11 Aug 2008 11:05:10 -0000 1.265
--- src/backend/access/transam/xact.c 16 Sep 2008 16:40:17 -0000
***************
*** 254,260 ****
static TransactionId RecordTransactionAbort(bool isSubXact);
static void StartTransaction(void);

- static void RecordSubTransactionCommit(void);
static void StartSubTransaction(void);
static void CommitSubTransaction(void);
static void AbortSubTransaction(void);
--- 254,259 ----
***************
*** 952,962 ****
* Now we may update the CLOG, if we wrote a COMMIT record above
*/
if (markXidCommitted)
! {
! TransactionIdCommit(xid);
! /* to avoid race conditions, the parent must commit first */
! TransactionIdCommitTree(nchildren, children);
! }
}
else
{
--- 951,957 ----
* Now we may update the CLOG, if we wrote a COMMIT record above
*/
if (markXidCommitted)
! TransactionIdCommitTree(xid, nchildren, children);
}
else
{
***************
*** 974,984 ****
* flushed before the CLOG may be updated.
*/
if (markXidCommitted)
! {
! TransactionIdAsyncCommit(xid, XactLastRecEnd);
! /* to avoid race conditions, the parent must commit first */
! TransactionIdAsyncCommitTree(nchildren, children, XactLastRecEnd);
! }
}

/*
--- 969,975 ----
* flushed before the CLOG may be updated.
*/
if (markXidCommitted)
! TransactionIdAsyncCommitTree(xid, nchildren, children, XactLastRecEnd);
}

/*
***************
*** 1156,1191 ****
s->maxChildXids = 0;
}

- /*
- * RecordSubTransactionCommit
- */
- static void
- RecordSubTransactionCommit(void)
- {
- TransactionId xid = GetCurrentTransactionIdIfAny();
-
- /*
- * We do not log the subcommit in XLOG; it doesn't matter until the
- * top-level transaction commits.
- *
- * We must mark the subtransaction subcommitted in the CLOG if it had a
- * valid XID assigned. If it did not, nobody else will ever know about
- * the existence of this subxact. We don't have to deal with deletions
- * scheduled for on-commit here, since they'll be reassigned to our parent
- * (who might still abort).
- */
- if (TransactionIdIsValid(xid))
- {
- /* XXX does this really need to be a critical section? */
- START_CRIT_SECTION();
-
- /* Record subtransaction subcommit */
- TransactionIdSubCommit(xid);
-
- END_CRIT_SECTION();
- }
- }
-
/* ----------------------------------------------------------------
* AbortTransaction stuff
* ----------------------------------------------------------------
--- 1147,1152 ----
***************
*** 3791,3799 ****
/* Must CCI to ensure commands of subtransaction are seen as done */
CommandCounterIncrement();

- /* Mark subtransaction as subcommitted */
- RecordSubTransactionCommit();
-
/* Post-commit cleanup */
if (TransactionIdIsValid(s->transactionId))
AtSubCommit_childXids();
--- 3752,3757 ----
***************
*** 4259,4269 ****
TransactionId max_xid;
int i;

- TransactionIdCommit(xid);
-
/* Mark committed subtransactions as committed */
sub_xids = (TransactionId *) &(xlrec->xnodes[xlrec->nrels]);
! TransactionIdCommitTree(xlrec->nsubxacts, sub_xids);

/* Make sure nextXid is beyond any XID mentioned in the record */
max_xid = xid;
--- 4217,4225 ----
TransactionId max_xid;
int i;

/* Mark committed subtransactions as committed */
sub_xids = (TransactionId *) &(xlrec->xnodes[xlrec->nrels]);
! TransactionIdCommitTree(xid, xlrec->nsubxacts, sub_xids);

/* Make sure nextXid is beyond any XID mentioned in the record */
max_xid = xid;
Index: src/include/access/transam.h
===================================================================
RCS file: /home/sriggs/pg/REPOSITORY/pgsql/src/include/access/transam.h,v
retrieving revision 1.65
diff -c -r1.65 transam.h
*** src/include/access/transam.h 11 Mar 2008 20:20:35 -0000 1.65
--- src/include/access/transam.h 16 Sep 2008 17:05:12 -0000
***************
*** 139,150 ****
extern bool TransactionIdDidCommit(TransactionId transactionId);
extern bool TransactionIdDidAbort(TransactionId transactionId);
extern bool TransactionIdIsKnownCompleted(TransactionId transactionId);
- extern void TransactionIdCommit(TransactionId transactionId);
- extern void TransactionIdAsyncCommit(TransactionId transactionId, XLogRecPtr lsn);
extern void TransactionIdAbort(TransactionId transactionId);
! extern void TransactionIdSubCommit(TransactionId transactionId);
! extern void TransactionIdCommitTree(int nxids, TransactionId *xids);
! extern void TransactionIdAsyncCommitTree(int nxids, TransactionId *xids, XLogRecPtr lsn);
extern void TransactionIdAbortTree(int nxids, TransactionId *xids);
extern bool TransactionIdPrecedes(TransactionId id1, TransactionId id2);
extern bool TransactionIdPrecedesOrEquals(TransactionId id1, TransactionId id2);
--- 139,147 ----
extern bool TransactionIdDidCommit(TransactionId transactionId);
extern bool TransactionIdDidAbort(TransactionId transactionId);
extern bool TransactionIdIsKnownCompleted(TransactionId transactionId);
extern void TransactionIdAbort(TransactionId transactionId);
! extern void TransactionIdCommitTree(TransactionId commitxid, int nxids, TransactionId *xids);
! extern void TransactionIdAsyncCommitTree(TransactionId commitxid, int nxids, TransactionId *xids, XLogRecPtr lsn);
extern void TransactionIdAbortTree(int nxids, TransactionId *xids);
extern bool TransactionIdPrecedes(TransactionId id1, TransactionId id2);
extern bool TransactionIdPrecedesOrEquals(TransactionId id1, TransactionId id2);
On Tue, 2008-09-16 at 10:11 -0400, Alvaro Herrera wrote:

> >> Right now we lock and unlock the clog for each committed subtransaction
> >> at commit time, which is wasteful. A better scheme:
> >> pre-scan the list of xids to derive list of pages
> >> if we have just a single page to update
> >> {
> >> update all entries on page in one action
> >> }
> >> else
> >> {
> >> loop thru xids marking them all as subcommitted
> >> mark top level transaction committed
> >> loop thus xids again marking them all as committed
> >> }
>
> > Hmm, I don't see anything immediately wrong with that.
>
> Neither do I.
>
> I wonder if the improved clog API required to mark multiple transactions
> as committed at once would be also useful to TransactionIdCommitTree
> which is used in regular transaction commit.

I enclose a patch to transform what we have now into what I think is
possible. If we agree this is possible, then I will do further work to
optimise transam.c (using clog.c changes also). So this is an
"intermediate" or precursor patch for discussion only.

backend/access/transam/transam.c | 78 ++++++++++++-----------------!
backend/access/transam/twophase.c | 4 !
backend/access/transam/xact.c | 50 -----------------!!!!!!!
include/access/transam.h | 7 !!!
4 files changed, 32 insertions(+), 78 deletions(-), 29 modifications(!)

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

Re: [GENERAL] PITR and base + full backups

On Tuesday 16 September 2008, "Joey K." <pguser@gmail.com> wrote:
> Hello,
>
> Just to be sure of our backups we plan to do a base + full backups (yes,
> we are overly paranoid)
>
> (1) (`date`)
>
> (2) perform hot rsync first (while the database is running)
> $ rsync -avr pgdata /backup/`date`/
>
> (3) stop pg
>
> (4) perform cold rsync
> $ rsync -avr --delete pgdata /backup/`date`/
>
> (5) start pg
>
> (6) pg_stop_backup()
>
> This didn't work and not sure if this is supposed to work ;-)
>
> Or should I stick to just plain PITR?

If you can live with the downtime to do that, you don't need steps 1 or 6,
and eliminating them will probably fix your problem. I imagine stopping the
database between pg_start_backup and pg_stop_backup caused whatever problem
you experienced.

Plain PITR is better, though, if you're actually archiving the WAL logs, as
your possibly recovery points will be as current as your last archived log.


--
Alan

--
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] Help request: how to tune performance?

On Tue, Sep 16, 2008 at 2:31 AM, Mauri Sahlberg
<Mauri.Sahlberg@claymountain.com> wrote:
> Hi,
>
> We just upgraded Best Practical's RT from 3.6 to 3.81 and gave the
> database completely own machine. And the users still complain that it is
> dog slow.

Moved up from below:

> Version : 8.1.11 Vendor: CentOS

So, you built it its own machine, but you didn't upgrade to at least 8.2?

Last place I worked we ran rt 3.6.1 and got a noticeable performance
boost from switching to 8.2 but the only thing that was ever really
slow was viewing the rather large approval queue.

> :-( I installed pg_top and it seems that at the beginning of
> the ticket display RT-issues a query that eats everything the database
> has. Query is as follows:
>
> SELECT DISTINCT main.* FROM Users main CROSS JOIN ACL ACL_2 JOIN
> Principals Principals_1 ON ( Principals_1.id = main.id ) JOIN
> CachedGroupMembers CachedGroupMembers_3 ON
> ( CachedGroupMembers_3.MemberId = Principals_1.id ) WHERE
> (Principals_1.Disabled = '0') AND (ACL_2.PrincipalId =
> CachedGroupMembers_3.GroupId) AND (Principals_1.id != '1') AND
> (ACL_2.PrincipalType = 'Group') AND (Principals_1.PrincipalType =
> 'User') AND (ACL_2.RightName = 'OwnTicket') AND ((ACL_2.ObjectType =
> 'RT::Queue' AND ACL_2.ObjectId = 18) OR (ACL_2.ObjectType =
> 'RT::System')) ORDER BY main.Name ASC

Please post the output of explain analyze as an attachment. explain
is only half the answer.

> Is there something I can do to improve performance with tuning something
> on postgresql.conf? Or adding/dropping indexes? What I read from that
> query plan is that the single most expensive thing is sequential scan on
> Principals. Principals already has indexes for both id and object.id!

Possibly. explain analyze will help you identify where stats are
wrong. sometimes just cranking the stats target on a few columns and
re-analyzing gets you a noticeable performance boost. It's cheap and
easy.

When the estimated and actual number of rows are fairly close, then
look for the slowest thing and see if an index can help.

What have to already done to tune the install? shared_buffers,
work_mem, random_page_cost, effective_cache_size. Is your db bloating
during the day?

Why no try 8.3 on this?

Are you running on a single SATA hard drive? How big's the database
directory? I'm guessing from your top output that the db is about 500
meg or so. it should all fit in memory.

--
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 Tue, 16 Sep 2008 11:54:18 -0500
"Roberts, Jon" <Jon.Roberts@asurion.com> wrote:

> > I wasn't kidding up there. Setting view permissions on plpgsql (or
> > any pl code really) would be understandable. If you're not a super
> > user or the owner, you need permission to see it.
> >
>
> How can I make that a feature request?

You need to send it to -hackers and get support for it. You might have
better luck if you or someone you agrees with you actually does the
work to get it implemented.

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-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, 2008 at 2:04 PM, Christophe <xof@thebuild.com> wrote:
> >
> > On Sep 15, 2008, at 12:56 PM, Scott Marlowe wrote:
> >>
> >> I could totally get behind needing permission to see the plpgsql
code.
> >
> > :)
>
> I wasn't kidding up there. Setting view permissions on plpgsql (or
> any pl code really) would be understandable. If you're not a super
> user or the owner, you need permission to see it.
>

How can I make that a feature request?


Jon

--
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] Asuntos en la lista [Was: Organizacion del PSDP-es]

Apoyo a Carolina, al q tenga ganas de JO... que lo haga en privado y no moleste a los demas
GRACIAS


On Tue, Sep 16, 2008 at 12:24 PM, Carolina Román Salgado <rossyr@abulafia.ciencias.uchile.cl> wrote:
On Tue, 2008-09-16 at 11:08 -0500, Ricardo Mendoza wrote:
> Espero que esta aclaracion sirva para que se de el respecto que
> merecemos  todos los miembros nuevos en la lista y en el uso de
> postgresql. y no se nos trate como tontos.

Hola

En realidad preferiría que todos los temas personales sean enviados a
los correos privados. ¿Por qué tengo que leer desde las sutiles bromas
que envían a los newbies guindowseros hasta las críticas personales que
se le hacen a otros listeros? Yo no tengo vela en ninguno de esos dos
entierros y me llegan los correos que no puedo mandar a spam sin haber
leído.

Carolina

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



--
Gonzalo E. Murillo Molina
cel. 72520908
http://gonzalo.murillo.googlepages.com/
Mis Fotos
http://picasaweb.google.com/gonzalo.murillo

Re: [GENERAL] could not open file "pg_subtrans/0014": Invalid argument

On 16/09/2008 01:54, Scott Marlowe wrote:
> On Mon, Sep 15, 2008 at 5:33 PM, Warren Bell <warren@clarksnutrition.com> wrote:
>> I have gotten this error before and it was attributed to my anti virus
>> program. I am running Postgres 8.1 on Windows XP. I am using Nod32 as my
>> anti virus program. I have tried adjusting Nod so it does not scan Postgres
>> and I am still getting the error.
>>
>> Long story short, Can someone recommend me an anti virus program for Windows
>> that does not interfere with Postgres?
>
> Can't you tell your anti-virus software to stop looking certain directories?
>
> More importantly, at least as far as servers are concerned, why would
> you need anti-virus software? Shouldn't the server be isolated in
> such a way that only the pgslq port 5432 is accessible by anything
> other than an admin?

In fairness, if he's running XP it's unlikely to be a server - maybe a
development laptop or such, at a guess.

Ray.


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

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

Re: [HACKERS] Common Table Expressions (WITH RECURSIVE) patch

On Mon, 2008-09-15 at 22:41 -0700, David Fetter wrote:
> On Mon, Sep 15, 2008 at 06:46:16PM +0900, Tatsuo Ishii wrote:
> > > > * Single Evaluation:
> > > >
> > > > with
> > > > foo(i) as (select random() as i)
> > > > select * from foo union all select * from foo;
> > > > i
> > > > -------------------
> > > > 0.233165248762816
> > > > 0.62126633618027
> > > > (2 rows)
> > > >
> > > > The standard specifies that non-recursive WITH should be
> > > > evaluated once.
> > >
> > > What shall we do? I don't think there's an easy way to fix this as
> > > Tom suggested. Maybe we should not allow WITH clause without
> > > RECURISVE for 8.4?
> >
> > This is a still remaing issue...
>
> I don't think that the spec explicitly forbids this.
>

This has been discussed before.

Regardless of the nuances of the spec (and whether it says so explicitly
or implicitly), there are people in the community that see single
evaluation as important, and important enough to be a showstopper.

Tom Lane has suggested that this is a reasonable amount of work to
complete, and minor in comparison to the rest of the patch.

I think the right approach is to try to complete it so that everyone is
happy. I will work on this, but unfortunately I don't have a lot of time
right now, so I can't make any promises.

The rest of the patch looks good so far (there are still a few things I
want to look at), so I think this is the biggest open issue.

Regards,
Jeff Davis


--
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] Organizacion del PSDP-es

2008/9/16 Ricardo Mendoza <pgsqlcol@gmail.com>:
> ¿Es esto una actitud franca y de acuerdo a el supuesto estatus que te
> increpas tacitamente como lider, como un miembro de la comunidad,
> por tu activa participacion en la lista?,

no se lo increpa, se lo ha ganado a eso se le llama meritocracia... es
la forma en que se manejan las comunidades.

la participacion de Alvaro en esta lista es la menor de sus
contribuciones a la comunidad postgres, es parte del equipo de
desarrollo (al menos esta entre los "major contributors") y es el
autor de cosas como los SAVEPOINT y la integracion del autovacuum
entre otras cosas, mantiene la traduccion al español de postgres (es
decir, los mensajes en español que te salen cuando ocurre un error y
cosas asi)... a parte de donar su tiempo para ayudar a otros en la
lista...

ademas se da el tiempo en sugerir ideas cuando empezamos proyectos
como este para que no se estanquen...

>
> He visto como tus ultimos post parecieran que tuvieran la intencion de
> no dejar prosperar al psdp-es porque antepones a él, el framework
> webtranslate, un proyecto muerto hace meses y que a pesar de tus
> quejas reiteradas sobre el, lo sacas a relucir como si todo el que
> llegara a la lista tuviera que someterse a el.

se trata de una idea simple, "no reinventar la rueda"

> Es decir a tu trabajo,

de hecho no fue el trabajo de el si no de Mario

> A lo que tu crees debe hacerse,

si crees que puede hacerse mejor de otro modo, deja de perder el
tiempo escribiendo correos como este y ponte a demostrar que tienes
razon... es decir, hazlo... si muestras tu punto y se ve algun
progreso Alvaro sera el primero en apoyar...

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157
--
TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda

Re: [HACKERS] 84 Wishlist update

Joey K. escribió:
> Hello,
>
> Just curious if this list is being updated ..
>
> http://wiki.postgresql.org/wiki/Todo:WishlistFor84

No.

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

[pgsql-jobs] Looking for co-founder(s)

Hello,

We are a start-up based in Bangalore(India) in early stage. We are
planning to provide a data management solution based on few innovative
ideas. We are planning to base our solution on Postgres.

We are looking for co-founder(s), ideally people who are innovative,
interested in databases, has developing experience in Postgres and has
customer exposure.

Please contact me personally(mailtoyahoo@gmail.com) if you are
interested so that we can take this discussion further.

Thanks,
Srinivas

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

[pgsql-es-ayuda] Asuntos en la lista [Was: Organizacion del PSDP-es]

On Tue, 2008-09-16 at 11:08 -0500, Ricardo Mendoza wrote:
> Espero que esta aclaracion sirva para que se de el respecto que
> merecemos todos los miembros nuevos en la lista y en el uso de
> postgresql. y no se nos trate como tontos.

Hola

En realidad preferiría que todos los temas personales sean enviados a
los correos privados. ¿Por qué tengo que leer desde las sutiles bromas
que envían a los newbies guindowseros hasta las críticas personales que
se le hacen a otros listeros? Yo no tengo vela en ninguno de esos dos
entierros y me llegan los correos que no puedo mandar a spam sin haber
leído.

Carolina

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

[HACKERS] 84 Wishlist update

Hello,

Just curious if this list is being updated ..

http://wiki.postgresql.org/wiki/Todo:WishlistFor84

Steve

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

No sé, si es politica tuya presumir de tus conocimientos y hacerte ver
como un ser superior, das por sentado que todos lo saben todo, y creo
que ese es un error, das por sentado que todos deben saber lo que tu,
quizas ya sepas, y te resulta algo tan ridiculo cualquier pregunta
obvia, a los ojos de una persona con experiencia en postgres, que
optas por ridiculizar cualquier post de algun miembro nuevo en la
lista.

¿Es esto una actitud franca y de acuerdo a el supuesto estatus que te
increpas tacitamente como lider, como un miembro de la comunidad,
por tu activa participacion en la lista?, No lo creo, más se parece a
la forma sutil de despreciar a otros que no saben lo que tu sabes, es
quizas la satisfaccion que sientes de saberte poseedor de algun
mediano conocimiento, un rango,o estatus,o autoridad, para el caso en
mencion de esta lista, por considerar que tienes la autoridad para
ridiculizar a cualquier persona, con respuestas laconicas derivadas de
tu suprema sabiduria en el manejo de postgresql.

El hecho que te profesen cierta admiracion en esta lista, y por sobre
todo que te consideren la autoridad de la misma y que tu creas tenerla
y ha lo sumo, creerte poseedor de una autoridad que te confiere el
conocimiento por el manejo de una base de datos y la historia de la
lista, riñe con cualquier instancia minima para poder construir en
comunidad. Es quizas tu actitud friki que te hace ser asi y eso de
verdad te aleja de avanzar en la contruccion de comunidad postgresql.

He visto como tus ultimos post parecieran que tuvieran la intencion de
no dejar prosperar al psdp-es porque antepones a él, el framework
webtranslate, un proyecto muerto hace meses y que a pesar de tus
quejas reiteradas sobre el, lo sacas a relucir como si todo el que
llegara a la lista tuviera que someterse a el. Es decir a tu trabajo,
a lo que ya existe. A lo que tu crees debe hacerse, No dudo de las
intenciones de mario al hacer ese programa. pero si, llegado el
momento, la aplicacion murio, pues murio. tendra que nacer otra
solucion, asi ello vaya en contra de todo lo que se ha hecho y todo el
trabajo que se ha invertido en ella.

Asi lamentablemente tenga que dejarse de lado una solucion que
realmente si intento convertirse en un universo en si misma, para
contestar lo que tu dices que yo estoy intentando crear, un universo
nuevo,paralelo y salido de la nada, con mi propuesta del PSDP-ES.

Simplemente señalas nimiedades, como si cualquier cosa que esté fuera
de tu control o supervision no mereciera tener la misma importancia
para la comunidad, como la que le abrogas al framework. ¿Acaso un
newbie no puede proponer y hacer cosas, asi sea que esto vaya en
contra de algo que existe pero que no funciona?, No se trata de volver
hacer las cosas desde cero, pero es una paradoja porque para traducir
la documentacion, crearon una aplicacion desde cero para traduccion, y
me señalan de querer inventar un universo nuevo, Ahora con el proyecto
del PSDP-es, trata de hacer lo mejor con lo que contamos, con el cvs o
con git. Sin sofistificaciones, sin pretensiones, como las que encarna
el framework Webtranslate.

¿¿¿Que es mas logico y practico??? , ¿crear una aplicacion para
traducciones,desde cero con algo de codigo reciclado?, o ¿¿utilizar
las herramientas de postgresql para la traduccion de la
documentacion?? obviamente es mucho mas complejo, crear y darle
mantenimiento a una aplicacion desde cero para la gestion de
traducciones y tener un programador que la desarrolle y le de
mantenimiento, que si por el contrario tenemos un equipo de personas
que saben leer y escribir, manejar y coordinan su trabajo en CVS o en
GIT, por el contrario es totalmente inoficioso estar buscando un
programador para que perfeccione una aplicacion sin terminar. y a su
vez depender de la existencia de un programador en la lista para que
haga ese trabajo, es mas logico y practico tener usuarios en la lista
que pueden realizar la tarea con las herramientas que da postgresql.

Espero que esta aclaracion sirva para que se de el respecto que
merecemos todos los miembros nuevos en la lista y en el uso de
postgresql. y no se nos trate como tontos.
--
TIP 2: puedes desuscribirte de todas las listas simultáneamente
(envía "unregister TuDirecciónDeCorreo" a majordomo@postgresql.org)

[HACKERS] How to get Agg attribute

Hi,
I am implementing a new feature of postgres. The problem is
how to get the attribute of Aggregation.  In /src/backend/commands/explain.c,
I want to add a function after  "case AGG_HASHED" to get the name
of this aggregation attribute in the table. How can I get it.

I tried to see (Agg *) plan)->grpColIdx, which just is a integer number.

 
Best Regards,
Zhe HE
TEL: (001) 646-789-3008
Address:965 Amsterdam Avenue,
New York, NY 10025

Master Student, CS Dept.
Columbia University
www.columbia.edu/~zh2132
-------------------------------------------
07 Alumni
Bachelor of Eng, BUPT
www.bupt.edu.cn

Re: [HACKERS] text search patch status update?

Patch #1. Teodor was fine with the previous version of the patch. After that I modified it slightly to allow a FragmentDelimiter option and Teodor may have to look at that.

Patch #2. I think this is a straigt forward bug fix.

-Sushant.

On Tue, Sep 16, 2008 at 11:27 AM, Alvaro Herrera <alvherre@commandprompt.com> wrote:
Sushant Sinha escribió:
> Any status updates on the following patches?
>
> 1. Fragments in tsearch2 headlines:
> http://archives.postgresql.org/pgsql-hackers/2008-08/msg00043.php
>
> 2. Bug in hlCover:
> http://archives.postgresql.org/pgsql-hackers/2008-08/msg00089.php

Are these ready for review?  If so, please add them to this commitfest,
http://wiki.postgresql.org/wiki/CommitFest:2008-09

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

[GENERAL] PITR and base + full backups

Hello,

Just to be sure of our backups we plan to do a base + full backups (yes, we are overly paranoid)

(1) pg_start_backup(`date`)

(2) perform hot rsync first (while the database is running)
$ rsync -avr pgdata /backup/`date`/

(3) stop pg
 
(4) perform cold rsync
$ rsync -avr --delete pgdata /backup/`date`/

(5) start pg

(6) pg_stop_backup()

This didn't work and not sure if this is supposed to work ;-)

Or should I stick to just plain PITR?

Thanks,
Steve

Re: [HACKERS] WIP patch: Collation support

Zdenek Kotala escribió:
> Gregory Stark napsal(a):

>> AFAIK we can't easily connect to the new database and do some fiddling with
>> it, can we? If we could we could check if there are any non-empty indexes
>> which depend on the collation and only print the warning if we find any (and
>> even mark them invalid).
>
> Autovacum uses InitPostgres function to swith to another database. I'm
> not sure how much safe it is in create database command and when we are
> already switched we can reindex affected indexes.

It's only supposed to work if you're not previously connected to any
database. (Autovacuum never "switches to another database"; any
particular worker only connects to a single database).

--
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: [SQL] a simple transform

On Tue, Sep 16, 2008 at 6:37 AM, Frank Bax <fbax@sympatico.ca> wrote:
>
> That pass the SQL into crosstab().

It might be interesting to look at this blog also:

http://okbob.blogspot.com/#7449458148004287481


--
Regards,
Richard Broersma Jr.

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

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

[ADMIN] Setting Effective Cache Size

Hi All;

Is there an easy way to determine the actual OS disk cache size or at
least a set of guidelines based on the OS and disk subsystem type ?


Thanks in advance...


/Kevin

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