Sunday, September 7, 2008

Re: [BUGS] BUG #4410: Indexes not seen right away

"Greg Sabino Mullane" <greg@endpoint.com> writes:
> I cannot reproduce, as this was on a production system and not seen again,
> but I created a simple index on a TEXT field, which was not chosen by the
> planner, even when seqscan was turned off. I analyzed the table, checked all
> the settings, etc. pg_index looked as it should. Eventually (~ 10 minutes
> later) the index as chosen - I don't know what might have triggered it to
> start appearing.

Does it have pg_index.indcheckxmin = true? If so, see README.HOT.

regards, tom lane

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

[BUGS] BUG #4410: Indexes not seen right away

The following bug has been logged online:

Bug reference: 4410
Logged by: Greg Sabino Mullane
Email address: greg@endpoint.com
PostgreSQL version: 8.3.3
Operating system: Linux
Description: Indexes not seen right away
Details:

I cannot reproduce, as this was on a production system and not seen again,
but I created a simple index on a TEXT field, which was not chosen by the
planner, even when seqscan was turned off. I analyzed the table, checked all
the settings, etc. pg_index looked as it should. Eventually (~ 10 minutes
later) the index as chosen - I don't know what might have triggered it to
start appearing. Creating a second table based on the first worked as it
should during the 'noindex' time period: CREATE TABLE foo AS SELECT * FROM
bar; CREATE INDEX foo_idx1 ON foo(textcol); EXPLAIN SELECT 1 FROM foo WHERE
textcol1 = 'baz';

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

[HACKERS] TRUNCATE privilege vs information_schema

Whilst going through the pending patch to add TRUNCATE as a separate
permission, I noticed that it neglected to add TRUNCATE to the various
columns in information_schema that display privileges. I wonder whether
we should do so, or whether we should restrict information_schema to
only show SQL-spec-compatible privileges.

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] Move src/tools/backend/ to wiki

So I just noticed that we have a description of the Pg innards in the
sourcecode, complete with a flowchart and all, at src/tools/backend.
I had already seen this graph years ago; what shocked me the most was
finding out that there's a pointer to it in the Developer's FAQ, in a
question that's absolutely unrelated to it.

So I went ahead and moved its mention to a separate question, where it
has a lot more visibility. (I also added an URL to anoncvs, where
people can see it more readily.)

What I'm wondering right now is what's the value of having this stuff
in the source code at all. Why don't we move it to the Wiki and remove
it from the repo? Would anybody object to that idea? Having it on CVS
means that nobody is able to improve the text, which is kind of sad
because it's been neglected for the last 3 years.

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

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

Re: [HACKERS] About that CommitFest redirect page ...

Tom Lane wrote:
> So according to
> http://wiki.postgresql.org/index.php?title=CommitFest&action=history
> there's been rather a lot of confusion about where the CommitFest
> redirect page should point when.
>
> I think the problem is that we need two redirect pages: one for "the
> place where you should submit a new patch" and one for "the commitfest in
> progress". The problem is to choose names that will make it reasonably
> obvious which is which.

Well, when it is commitfest right now, I would like to be able to go to a URL
that says "commitfest" and then monitor and work on the things there. Most
people should be doing that.

The use case for adding things to the next commitfest while a commitfest is
currently happening much less convincing. Why would you submit a patch now
when you still have two months to work on on it and you should be reviewing
other patches anyway?

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

[ADMIN] secure connections

Hello,

I have a question regarding secure connections between pg clients and pg server. As per manual for 8.3 we can use openssl for this purpose. does odbc driver supports it and how? Is there any other method for this?

Thanks

CPK

Re: [HACKERS] reducing statistics write overhead

Martin Pihlak <martin.pihlak@gmail.com> writes:
> I had also previously experimented with stat() based polling but ran into
> the same issues - no portable high resolution timestamp on files. I guess
> stat() is unusable unless we can live with 1 second update interval for the
> stats (eg. backend reads the file if it is within 1 second of the request).

> One alternative is to include a timestamp in the stats file header - the
> backend can then wait on that -- check the timestamp, sleep, resend the
> request, loop. Not particularly elegant, but easy to implement. Would this
> be acceptable?

Timestamp within the file is certainly better than trying to rely on
filesystem timestamps. I doubt 1 sec resolution is good enough, and
I'd also be worried about issues like clock skew between the
postmaster's time and the filesystem's time.

regards, tom lane

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

Re: [HACKERS] reducing statistics write overhead

Magnus Hagander wrote:
> I wrote a patch for this some time back, that was actually applied.
> Turns out it didn't work, and I ran out of time to fix it, so it was
> backed out again. And then I forgot about it :-) If you look through the
> cvs history of pgstat you should be able to find it - maybe it can give
> you some further ideas.

Got it - this was 1.126. Looks very familiar indeed :)

I had also previously experimented with stat() based polling but ran into
the same issues - no portable high resolution timestamp on files. I guess
stat() is unusable unless we can live with 1 second update interval for the
stats (eg. backend reads the file if it is within 1 second of the request).

One alternative is to include a timestamp in the stats file header - the
backend can then wait on that -- check the timestamp, sleep, resend the
request, loop. Not particularly elegant, but easy to implement. Would this
be acceptable?

regards,
Martin


--
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] A challenge for the SQL gurus out there...

On Sunday 07 September 2008, Gregory Stark wrote:
> "Uwe C. Schroeder" <uwe@oss4u.com> writes:
> > I want to get a list looking like
> >
> > forum id thread_id post_id
> > 1 6 443
> > 2 9 123
> > 3 3 557
>
> ...
>
> > It all boils down to me not being able to come up with a query that gives
> > me the latest post per forum_id.
>
> In a situation like this I would probably denormalize the tables slightly
> by adding a form_id key to the individual posts. That would make it hard to
> ever move a thread from one forum to another, though not impossible, but
> would help in this case as well as any other time you want to do an
> operation on all posts in a forum regardless of thread.
>
> If you add that column then you could index <form_id,date> and get the
> result you're looking for instantly with a DISTINCT ON query (which is a
> Postgres SQL extension).
>
> SELECT DISTINCT ON (form_id)
> forum_id, thread_id, post_id
> FROM thread
> ORDER BY forum_id, date DESC
>
> (actually you would have to make the index on <form_id, date DESC> or make
> both columns DESC in the query and then re-order them in an outer query)
>
> Alternatively you could have a trigger on posts which updates a
> last_updated field on every thread (and possibly a recent_post_id) then you
> could have a query on forums which pulls the most recently updated thread
> directly without having to join on form_post at all. That would slow down
> inserts but speed up views -- possibly a good trade-off for a forum system.

Thanks Gregory.
Just to put my final solution on the list: I ended up with a combined approach
of what you suggested:
I added the forum_id to the posts table and created 2 triggers: one that sets
the forum_id in the posts table to the forum_id in the threads table on
insert (therefor no change in the application was necessary).
The second trigger is to overcome the downside of adding the forum_id to the
posts table. On an update to forum_thread.forum_id the trigger updates all
posts in that thread to reflect the change in forum_id. That way one can just
move the whole thread by changing the forum_id and the posts are moved along
by the trigger.

Very nice! The query time is now 198ms instead of up to 48seconds !!!

Thanks for the idea

Uwe

--
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] Proposed patch: make pg_dump --data-only consider FK constraints

Alvaro Herrera <alvherre@commandprompt.com> writes:
> Heikki Linnakangas wrote:
>> How about printing that notice at the top of the dump file as well?

> I assume that this trick will only work at restore time only for custom
> or tar dumps. A text-only dump would produce the warning to stderr at
> dump time, no?

Yes, the warning (and the re-sorting) must happen at dump time. Given a
data-only dump, pg_restore wouldn't even have the information needed to
do anything about this.

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

[COMMITTERS] pgsql: Clarify description of pg_restore's handling of large objects.

Log Message:
-----------
Clarify description of pg_restore's handling of large objects.

Modified Files:
--------------
pgsql/doc/src/sgml/ref:
pg_restore.sgml (r1.75 -> r1.76)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/ref/pg_restore.sgml?r1=1.75&r2=1.76)

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

Re: [HACKERS] Proposed patch: make pg_dump --data-only consider FK constraints

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> Tom Lane wrote:
>> pg_dump: WARNING: circular foreign-key constraints among these table(s):
>> pg_dump: master
>> pg_dump: child
>> pg_dump: You may not be able to restore the dump without using --disable-triggers or temporarily dropping the constraints.

> WARNING feels a bit too strong. I realize that that message isn't going
> to the postmaster's log, bloating it, but if a user does that regularly,
> always disabling triggers as instructed, or there is in fact never
> circular references in the data with a particular schema, seeing that
> big fat warning every time is going to become a bit tiresome. Perhaps
> "NOTE: ..." ?

I doubt that very many people will ever see it at all, actually --- how
common are circular FK relationships? And it does seem appropriate to
me for pg_dump to be noisy about the possibility of trouble at restore
time. (Maybe the message should also suggest using a schema+data dump,
since that would be a solution at dump time?)

> How about printing that notice at the top of the dump file as well?

Hmm ... that might be feasible in plain text output, but I don't see
any easy way to get a similar effect in archive modes.

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-es-ayuda] Funcion IIf()

Hola Roberto,

Creo que no hay documentacion en espa//nol del lenguaje en cuestion
y sus implementaciones. Probablemente haya muchos "como hacer" dando
vueltas, pero no un manual per se.

Respecto a la documentacion en ingles, podes referirte a la siguiente URL:

http://www.postgresql.org/docs/

Hay una wiki sobre Postgres en ES pero desconozco su
*contemporaneidad* (si es que existe la palabra):

http://wiki.postgresql.org/wiki/Espa%C3%B1ol

Un documento del 2000 aproximadamente, sobre PL/PGSQL en ES:

http://www.sobl.org/traducciones/postgresql-develdoc/node7.html

Suerte!
On Sun, Sep 7, 2008 at 1:30 PM, ROBWARE RUIZ <robware.ruiz@gmail.com> wrote:
> Soy nuevo en el mundo PostgreSQL, este es mi primer post, vamos a ver como
> me va...
> Normalmente usaba Access, pero definitivamente para algunas situaciones de
> gran calado mejor usar PostgreSQL, bueno el cuento es que en Access existe
> una función IIf(Condición, ValorVerdadero, ValorFalso), ya estudie la
> documentacion de PostgreSQL y la implementé con el operador CASE WHEN ELSE
> END, pero estudiando esa documentacion observe que se puede añadir funciones
> nuevas, con el lenguaje pl/pgsql pero no he encontrado docmentacion de dicho
> lenguaje, seria posible que alguien me pudiera dar una mano con la
> implementacion de la funcion IIf y con un manual del lenguaje,
> preferiblemente en español.
>
> De antemano muchas gracias.
>
> Roberto M. Ruiz S.
>

--
Guido Barosio
-----------------------
http://www.globant.com
guido.barosio@globant.com
--
TIP 10: no uses HTML en tu pregunta, seguro que quien responda no podrá leerlo

Re: [HACKERS] Proposed patch: make pg_dump --data-only consider FK constraints

David Fetter <david@fetter.org> writes:
> On Sun, Sep 07, 2008 at 02:06:40PM -0400, Tom Lane wrote:
>> Okay, I got tired of seeing people complain about foreign-key
>> constraint violations in data-only dumps.

> Isn't this something solved in the more general case by having
> pre-data, data, and post-data dump options?

No, not unless you expect that that patch will somehow forbid people
from using data-only dumps.

regards, tom lane

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

Re: [HACKERS] Proposed patch: make pg_dump --data-only consider FK constraints

Heikki Linnakangas wrote:
> Tom Lane wrote:

>> pg_dump: WARNING: circular foreign-key constraints among these table(s):
>> pg_dump: master
>> pg_dump: child
>> pg_dump: You may not be able to restore the dump without using --disable-triggers or temporarily dropping the constraints.
>
> WARNING feels a bit too strong. I realize that that message isn't going
> to the postmaster's log, bloating it, but if a user does that regularly,
> always disabling triggers as instructed, or there is in fact never
> circular references in the data with a particular schema, seeing that
> big fat warning every time is going to become a bit tiresome. Perhaps
> "NOTE: ..." ?

But the warning is only going to be emitted if there are actual circular
FK constraints, so it seems OK.

> How about printing that notice at the top of the dump file as well? Most
> people probably don't look at the dump files, but if someone needs to
> deal with a data-only dumps that contain circular constraints, and also
> those that don't, it would be invaluable information.

I assume that this trick will only work at restore time only for custom
or tar dumps. A text-only dump would produce the warning to stderr at
dump time, no?

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

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

Re: [HACKERS] Proposed patch: make pg_dump --data-only consider FK constraints

On Sun, Sep 07, 2008 at 02:06:40PM -0400, Tom Lane wrote:
> Okay, I got tired of seeing people complain about foreign-key
> constraint violations in data-only dumps.

Isn't this something solved in the more general case by having
pre-data, data, and post-data dump options?

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

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

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

Re: [HACKERS] Some newbie questions

M2Y wrote:
> Hello,
>
> Could you plz answer the following questions of a newbie:
>
> What is a good way to start understanding backend(postgres) code? Is
> there any documentation available especially for developers?

Most of the developer info is within comments in the code itself.
Another place to start is http://www.postgresql.org/developer/coding

> What is commit log and why it is needed?

To achieve ACID (Atomic, Consistent, Isolatable, Durable)
The changes needed to complete a transaction are saved to the commit log
and flushed to disk, then the data files are changed. If the power goes
out during the data file modifications the commit log can be used to
complete the changes without losing any data.

> Why does a replication solution need log shipping and why cant we
> just ship the transaction statements to a standby node?

Depends on what you wish to achieve. They are two ways to a similar
solution.
Log shipping is part of the core code with plans to make the duplicate
server be able to satisfy select queries.
Statement based replication is offered by other options such as slony.

Each has advantages and disadvantages. Transaction logs are part of
normal operation and can be copied to another server in the background
without adding load or delays to the master server.

Statement based replication has added complexity of waiting for the
slaves to duplicate the transaction and handling errors from a slave
applying the transaction. They also tend to have restrictions when it
comes to replicating DDL changes - implemented as triggers run from
INSERT/UPDATE not from CREATE/ALTER TABLE.

--

Shane Ambler
pgSQL (at) Sheeky (dot) Biz

Get Sheeky @ http://Sheeky.Biz

--
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] Proposed patch: make pg_dump --data-only consider FK constraints

Tom Lane wrote:
> Okay, I got tired of seeing people complain about foreign-key constraint
> violations in data-only dumps. While it's true that the problem can't
> be solved in the general case (because of potentially circular
> references), we could certainly make pg_dump at least *try* to order the
> tables according to foreign key relationships. It turns out not to even
> require a whole lot of new code. Accordingly I propose the attached
> patch. It will order the tables safely if it can, and otherwise
> complain like this:

+1

> pg_dump: WARNING: circular foreign-key constraints among these table(s):
> pg_dump: master
> pg_dump: child
> pg_dump: You may not be able to restore the dump without using --disable-triggers or temporarily dropping the constraints.

WARNING feels a bit too strong. I realize that that message isn't going
to the postmaster's log, bloating it, but if a user does that regularly,
always disabling triggers as instructed, or there is in fact never
circular references in the data with a particular schema, seeing that
big fat warning every time is going to become a bit tiresome. Perhaps
"NOTE: ..." ?

How about printing that notice at the top of the dump file as well? Most
people probably don't look at the dump files, but if someone needs to
deal with a data-only dumps that contain circular constraints, and also
those that don't, it would be invaluable information.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

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

[HACKERS] Proposed patch: make pg_dump --data-only consider FK constraints

Okay, I got tired of seeing people complain about foreign-key constraint
violations in data-only dumps. While it's true that the problem can't
be solved in the general case (because of potentially circular
references), we could certainly make pg_dump at least *try* to order the
tables according to foreign key relationships. It turns out not to even
require a whole lot of new code. Accordingly I propose the attached
patch. It will order the tables safely if it can, and otherwise
complain like this:

pg_dump: WARNING: circular foreign-key constraints among these table(s):
pg_dump: master
pg_dump: child
pg_dump: You may not be able to restore the dump without using --disable-triggers or temporarily dropping the constraints.

Comments?

regards, tom lane

Re: [HACKERS] reducing statistics write overhead

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

Hi,

Le 7 sept. 08 à 00:45, Tom Lane a écrit :
> I dislike the alternative of communicating through shared memory,
> though. Right now the stats collector isn't even connected to shared
> memory.

Maybe Markus Wanner work for Postgres-R internal messaging, now it has
been reworked to follow your advices, could be of some use here?
http://archives.postgresql.org/pgsql-hackers/2008-07/msg01114.php
http://archives.postgresql.org/pgsql-hackers/2008-07/msg01420.php

Regards,
- --
dim

- --
Dimitri Fontaine
PostgreSQL DBA, Architecte

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkjEF0sACgkQlBXRlnbh1bl/FACeORN+NjEFC9wi22suNaSoWmi5
LBEAnj9Qo2E6GWqVjdtsSCG7JILBPmX6
=5jPo
-----END PGP SIGNATURE-----

--
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] Implementar IIf

Jaime Casanova escribió:

> la funcion iif en plsql es bastante simple:
>
> create function iif(boolean, int, int) returns int as$$
> select case $1 when true then $2 else $3 end;
> $$ language sql;

Esta definicion asume que los valores a retornar son enteros ... mejor
asi:

create function iif(boolean, anyelement, anyelement) returns int as$$
select case $1 when true then $2 else $3 end;
$$ language sql;

Eso debería funcionar para cualquier tipo escalar; no va a funcionar
para arrays. Quizás esto funcione:

create function iif(boolean, any, any) returns int as$$
select case $1 when true then $2 else $3 end;
$$ language sql;

pero no estoy seguro. En el peor de los casos podrías definir dos
funciones, una que sea (bool, anyelement, anyelement) y otra que sea
(bool, anyarray, anyarray). (Habría que ver que hacer con los enums)

--
Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC
"If it wasn't for my companion, I believe I'd be having
the time of my life" (John Dunbar)
--
TIP 2: puedes desuscribirte de todas las listas simultáneamente
(envía "unregister TuDirecciónDeCorreo" a majordomo@postgresql.org)

Re: [pgsql-es-ayuda] Implementar IIf

On Sun, Sep 7, 2008 at 11:03 AM, ROBWARE RUIZ <robware.ruiz@gmail.com> wrote:
>
> pero estudiando esa documentacion observe que se puede añadir funciones
> nuevas, con el lenguaje pl/pgsql

no solo plpgsql, tambien plperl, plpython, pltcl, plr, pljava, entre otros
asi como en lenguaje c y plsql

la funcion iif en plsql es bastante simple:

create function iif(boolean, int, int) returns int as$$
select case $1 when true then $2 else $3 end;
$$ language sql;

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. (593) 87171157
--
TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?
http://archives.postgresql.org/pgsql-es-ayuda

Re: [HACKERS] Noisy CVS updates

D'Arcy J.M. Cain wrote:
> On Sun, 07 Sep 2008 03:39:39 -0400
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > "D'Arcy J.M. Cain" <darcy@druid.net> writes:
> > > ...etc. Would it be OK if I went in and added .cvsignore files to keep
> > > the noise level down?
> >
> > Uh, no, at least not before you've explained why you get those messages
> > and others don't.
>
> I didn't know that I am the only one. Am I?

Lots of other people do get them -- they are visible in the patches they
send. Since I use a VPATH build, which puts all those files in a
separate directory, I get (almost?) no noise even though I don't bother
with "make distclean" most of the time.

--
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: [HACKERS] Prototype: In-place upgrade v02

Gregory Stark wrote:
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>> Relation forks didn't change anything inside relation files, so no scanning of
>> relations is required because of that. Neither will the FSM rewrite. Not sure
>> about DSM yet.
>
> And just to confirm -- they don't change the name of the files the postmaster
> expects to find in its data directory, right?

Right. But it wouldn't be a big issue anyway. Renaming would be quick
regardless of the relation sizes, FSM and DSM will introduce new files,
though, that probably need to be created as part of the upgrade, but
again they're not very big.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

--
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] Prototype: In-place upgrade v02

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:

> Tom Lane wrote:
>> I didn't see anything that looked like an immediate change in user table
>> contents, unless they used the "name" type; but what of relation forks?
>
> Relation forks didn't change anything inside relation files, so no scanning of
> relations is required because of that. Neither will the FSM rewrite. Not sure
> about DSM yet.

And just to confirm -- they don't change the name of the files the postmaster
expects to find in its data directory, right?

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's PostGIS 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] [HACKERS] New shapshot RPMs (Sep 7 2008) are ready for testing

Joshua D. Drake wrote:
> Andrew Dunstan wrote:
>>
>
>> Hasn't integer-datetimes been the default for a while? Of course, a
>> catversion bump will force a dump/reload regardless of that.
>
> Unfortunately not. It is the default on some versions of linux such as
> Debian/Ubuntu.
>
>

The point I was making is that for 8.4, unless you specifically
configure with --disable-integer-datetimes, it is enabled by default on
any platform that can support it. We committed that change on 30 March
here: http://archives.postgresql.org/pgsql-committers/2008-03/msg00550.php

cheers

andrew

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

[pgsql-es-ayuda] Funcion IIf()

Soy nuevo en el mundo PostgreSQL, este es mi primer post, vamos a ver como me va...
Normalmente usaba Access, pero definitivamente para algunas situaciones de gran calado mejor usar PostgreSQL, bueno el cuento es que en Access existe una función IIf(Condición, ValorVerdadero, ValorFalso), ya estudie la documentacion de PostgreSQL y la implementé con el operador CASE WHEN ELSE END, pero estudiando esa documentacion observe que se puede añadir funciones nuevas, con el lenguaje pl/pgsql pero no he encontrado docmentacion de dicho lenguaje, seria posible que alguien me pudiera dar una mano con la implementacion de la funcion IIf y con un manual del lenguaje, preferiblemente en español.

De antemano muchas gracias.

Roberto M. Ruiz S.

[BUGS] BUG #4409: postmaster service is stopped

The following bug has been logged online:

Bug reference: 4409
Logged by: prasana venkatesh
Email address: prasyt@yahoo.com
PostgreSQL version: pg3
Operating system: linux
Description: postmaster service is stopped
Details:

how to start postgrey post master service manually

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

Re: [GENERAL] [HACKERS] New shapshot RPMs (Sep 7 2008) are ready for testing

Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= <devrim@gunduz.org> writes:
> On Sun, 2008-09-07 at 11:01 -0400, Andrew Dunstan wrote:
>> Hasn't integer-datetimes been the default for a while?

> No. I added it as a macro to 8.3, but did not enable it by default,
> because I am trying to be binary compatible with Red Hat / Fedora RPMs.
> I believe Tom will also add it to 8.4 packages for Fedora 11.

The RHEL/Fedora RPMs have never specified this one way or the other,
so they'd just get the default. I haven't really thought about whether
to change that when 8.4 comes out. I'd prefer to follow upstream's
lead on the point; but if for instance we could do update-in-place
so long as you hadn't switched datetime representation, that would be a
pretty powerful incentive to stick with the float format.

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] [HACKERS] New shapshot RPMs (Sep 7 2008) are ready for testing

Andrew Dunstan wrote:
>

> Hasn't integer-datetimes been the default for a while? Of course, a
> catversion bump will force a dump/reload regardless of that.

Unfortunately not. It is the default on some versions of linux such as
Debian/Ubuntu.

Sincerely,

Joshua D. Drake


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

Re: [PATCHES] [PgFoundry] Unsigned Data Types [1 of 2]

"Jaime Casanova" <jcasanov@systemguards.com.ec> writes:
> On Sun, Sep 7, 2008 at 2:41 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> That obviously isn't supposed to happen. Where's it coming from
>> exactly?

> convert_numeric_to_scalar() in src/backend/utils/adt/selfuncs.c

> the problem seems to be that we are asking for each type of numeric
> and of course that doesn't know nothing about unsigned integers so its
> treating it as a non-numeric.

Ah. The scalarltsel/scalargtsel stuff has always been a bit bogus for
cross-type comparisons; it assumes it will know both or neither of the
two datatypes. So you can get away with using those functions for
uint > uint (although they won't be very bright about it); but using
them for uint > int fails outright.

If you read the comments around that stuff it leaves quite a lot to be
desired, but I don't really have better ideas at the moment. The best
near-term solution for the uint module is probably not to rely on
scalarltsel/scalargtsel for uint comparisons, but to make its own
selectivity functions that know the uint types plus whatever standard
types you want to have comparisons with.

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

[pgsql-es-ayuda] Implementar IIf

Soy nuevo en el mundo PostgreSQL, este es mi primer post, vamos a ver como me va...
Normalmente usaba Access, pero definitivamente para algunas situaciones de gran calado mejor usar PostgreSQL, bueno el cuento es que en Access existe una función IIf(Condición, ValorVerdadero, ValorFalso), ya estudie la documentacion de PostgreSQL y la implementé con el operador CASE WHEN ELSE END, pero estudiando esa documentacion observe que se puede añadir funciones nuevas, con el lenguaje pl/pgsql pero no he encontrado docmentacion de dicho lenguaje, seria posible que alguien me pudiera dar una mano con la implementacion de la funcion IIf y con un manual del lenguaje, preferiblemente en español.

De antemano muchas gracias.

Roberto M. Ruiz S.

Re: [HACKERS] Prototype: In-place upgrade v02

Tom Lane wrote:
> I didn't see anything that looked like an immediate change in user table
> contents, unless they used the "name" type; but what of relation forks?

Relation forks didn't change anything inside relation files, so no
scanning of relations is required because of that. Neither will the FSM
rewrite. Not sure about DSM yet.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

--
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] Prototype: In-place upgrade v02

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> In fact, I don't think there's any low-level data format changes yet
> between 8.3 and 8.4, so this would be a comparatively easy release to
> implement upgrade-in-place. There's just the catalog changes, but AFAICS
> nothing that would require scanning through relations.

After a quick scan of the catversion.h changelog (which hopefully covers
any such changes): we changed sequences incompatibly, we changed hash
indexes incompatibly (even without the pending patch that would change
their contents beyond recognition), and Teodor did some stuff to GIN
indexes that might or might not represent an on-disk format change,
you'd have to ask him. We also whacked around the sort order of
bpchar_pattern_ops btree indexes.

I didn't see anything that looked like an immediate change in user table
contents, unless they used the "name" type; but what of relation forks?

regards, tom lane

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

Re: [HACKERS] Review Report: propose to include 3 new functions into intarray and intagg

Hi,

Dmitry Koterov wrote:
> I'll correct everything and send a patch in a couple of days.

Cool, thank you.

> Are you
> completely sure that this patch will be included?

Uh.. I'm not a committer, but I'm pretty sure your patch has good chances.

I can help with SGML documentation, if you want.

> But, what about intarray patch? Does somebody plan to review it? I'd
> prefer to include it too. If you approve, I'll correct the code style in
> intarray contrib patch too.

I've already volunteered for reviewing it as well. I just felt like
splitting things up...

Regards

Markus Wanner

--
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] [HACKERS] New shapshot RPMs (Sep 7 2008) are ready for testing

Hello,

On Sun, 2008-09-07 at 11:01 -0400, Andrew Dunstan wrote:

> Hasn't integer-datetimes been the default for a while?

No. I added it as a macro to 8.3, but did not enable it by default,
because I am trying to be binary compatible with Red Hat / Fedora RPMs.

I believe Tom will also add it to 8.4 packages for Fedora 11.

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

Re: [pgsql-www] About server sponsors

On Sun, Sep 7, 2008 at 4:06 PM, Devrim GÜNDÜZ <devrim@gunduz.org> wrote:
> On Sun, 2008-09-07 at 16:03 +0100, Dave Page wrote:
>> No, we have no policy for that at the moment - though there is one
>> under discussion.
>
> Ok, so I believe we need a policy there.

Like I said there is one under discussion. It's been taken off-list
because the amount of bike-shedding in past attempts has meant that
it's been in progress for at least a year and gotten nowhere.

> For example, should we write a person's name instead of company name?

That would seem reasonable.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.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-www] About server sponsors

On Sun, 2008-09-07 at 16:03 +0100, Dave Page wrote:
> No, we have no policy for that at the moment - though there is one
> under discussion.

Ok, so I believe we need a policy there.

For example, should we write a person's name instead of company name?
--
Devrim GÜNDÜZ, RHCE
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org

Re: [pgsql-www] About server sponsors

On Sun, Sep 7, 2008 at 3:57 PM, Devrim GÜNDÜZ <devrim@gunduz.org> wrote:
>
> Do we have a policy for the non-corporate sponsors?
>
> For example, if a person, who pays for the bw, etc and helps hosting a
> PostgreSQL.org service, how do we list them under
> http://www.postgresql.org/about/servers ?
>
> Currently each machine is donated by companies.

No, we have no policy for that at the moment - though there is one
under discussion.

Afaia though, we do have one personally donated box - eastside, which
is owned by a friend of Magnus I believe.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.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: [HACKERS] New shapshot RPMs (Sep 7 2008) are ready for testing

Devrim GÜNDÜZ wrote:
> Hi,
>
> I just released new RPM sets, which is based on today's CVS snapshot
> (Sep 7, 12:00AM PDT).
>
> These packages *do* require a dump/reload, even from previous 8.4
> packages, since I now enabled --enable-integer-datetimes in PGDG RPMs by
> default (and IIRC there is a catversion update in recent commits, too
> lazy to check it now :) ).
>
>
>

Hasn't integer-datetimes been the default for a while? Of course, a
catversion bump will force a dump/reload regardless of that.

cheers

andrew

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

[pgsql-www] About server sponsors

Do we have a policy for the non-corporate sponsors?

For example, if a person, who pays for the bw, etc and helps hosting a
PostgreSQL.org service, how do we list them under
http://www.postgresql.org/about/servers ?

Currently each machine is donated by companies.

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

Re: [BUGS] BUG #4407: Bug in PQexecPrepared when using an integer primary key that does not start at 1

"Kevin Jenkins" <gameprogrammer@rakkar.org> writes:
> Description: Bug in PQexecPrepared when using an integer primary key
> that does not start at 1

I'd say this is pilot error, most likely in the form of putting
parameter values into the wrong elements of the parameter arrays
passed to PQexecPrepared. (Remember the zero'th element of those
arrays corresponds to parameter symbol $1.)

Even if I thought it was a real bug, it's impossible to investigate
without a far more complete test case than you've provided. You
haven't shown us any client-side code.

regards, tom lane

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

[HACKERS] TODO item: Allow substring/replace() to get/set bit values

I was just searching though the TODO list to try and find a quick one that could be ticked off.

Under functions there is “Allow substring/replace() to get/set bit values”.

Does anyone have any more information about this?

Re: [BUGS] PG 8.3.3 - ERROR: lock AccessShareLock on object 16385/16467/0 is already held

Bruce Momjian <bruce@momjian.us> writes:
> Tom Lane wrote:
>> In any case, now that we know that nLocks overflow is actually possible
>> within real-world transaction lengths, it'd behoove us to do something
>> about that in 8.4 or beyond.

> Is this a TODO?

Yes, although I'm still waiting for more info from Michael.

regards, tom lane

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

Re: [HACKERS] Noisy CVS updates

On Sun, 2008-09-07 at 08:44 -0400, D'Arcy J.M. Cain wrote:
> > Uh, no, at least not before you've explained why you get those
> messages
> > and others don't.
>
> I didn't know that I am the only one. Am I?

You are not. I got more or less the same this morning while preparing my
new packages.

But as Tom stated, after running make distclean, everything worked fine.

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

Re: [HACKERS] Noisy CVS updates

"D'Arcy J.M. Cain" <darcy@druid.net> writes:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> (Personally, I never do "cvs update" without "make distclean" first;
>> there are too many other ways to get screwed by updating a live build
>> tree.)

> I assume that you are talking about conflicts. In fact, that's one of
> the main reasons for wanting a quiet update so that I can catch those
> right away when I am working on some files. I do an automatic update
> daily to keep current with the head. I don't do a "make distclean"
> first because I may be working on something and I want to keep the
> changes in the tree to try stuff and report patches against HEAD.

Huh? distclean does not remove any source-code changes, only derived
files.

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] Some newbie questions

Hello,

Could you plz answer the following questions of a newbie:

What is a good way to start understanding backend(postgres) code? Is
there any documentation available especially for developers?

What is commit log and why it is needed?

Why does a replication solution need log shipping and why cant we just
ship the transaction statements to a standby node?

to be continued ... ;)

Thanks,
Srinivas

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

Re: [PATCHES] [PgFoundry] Unsigned Data Types [1 of 2]

On Sun, Sep 7, 2008 at 2:41 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Jaime Casanova" <jcasanov@systemguards.com.ec> writes:
>> contrib_regression=# select * from t1 where f1 > 35;
>> ERROR: unsupported type: 16486
>
> That obviously isn't supposed to happen. Where's it coming from
> exactly?
>

convert_numeric_to_scalar() in src/backend/utils/adt/selfuncs.c

the problem seems to be that we are asking for each type of numeric
and of course that doesn't know nothing about unsigned integers so its
treating it as a non-numeric. don't know what to suggest here? a
column in pg_type that identifies it? a hook?

switch (typid)
{
case BOOLOID:
return (double) DatumGetBool(value);
case INT2OID:
return (double) DatumGetInt16(value);
case INT4OID:
return (double) DatumGetInt32(value);
case INT8OID:
return (double) DatumGetInt64(value);
case FLOAT4OID:
return (double) DatumGetFloat4(value);
case FLOAT8OID:
return (double) DatumGetFloat8(value);
case NUMERICOID:
/* Note: out-of-range values will be clamped to +-HUGE_VAL */
return (double)
DatumGetFloat8(DirectFunctionCall1(numeric_float8_no_overflow,
value));
case OIDOID:
case REGPROCOID:
case REGPROCEDUREOID:
case REGOPEROID:
case REGOPERATOROID:
case REGCLASSOID:
case REGTYPEOID:
case REGCONFIGOID:
case REGDICTIONARYOID:
/* we can treat OIDs as integers... */
return (double) DatumGetObjectId(value);
}

/*
* Can't get here unless someone tries to use scalarltsel/scalargtsel on
* an operator with one numeric and one non-numeric operand.
*/
elog(ERROR, "unsupported type: %u", typid);
return 0;

--
Atentamente,
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: [HACKERS] Prototype: In-place upgrade v02

Heikki Linnakangas wrote:
> Bruce Momjian wrote:
> > As far as the page not fitting after conversion, what about some user
> > command that will convert an entire table to the new format if page
> > expansion fails.
>
> VACUUM?
>
> Having to run a manual command defeats the purpose somewhat, though.
> Especially if you have no way of knowing on what tables it needs to be
> run on.

My assumption is that the page not fitting would be a rare case so
requiring something like vacuum to fix it would be OK.

What I don't want to do it to add lots of complexity to the code just to
handle the page expansion case, when such a case is rare and perhaps can
be fixed by a vacuum.

> > I am ready to focus on these issues for 8.4; all this needs to be
> > fleshed out, perhaps on a wiki. As a starting point, what would be
> > really nice is to start a wiki that lists all data format changes for
> > every major release.
>
> Have you looked at http://wiki.postgresql.org/wiki/In-place_upgrade
> already, that Greg Smith mentioned elsewhere in this thread? That's a
> good starting point.

Agreed.

> In fact, I don't think there's any low-level data format changes yet
> between 8.3 and 8.4, so this would be a comparatively easy release to
> implement upgrade-in-place. There's just the catalog changes, but AFAICS
> nothing that would require scanning through relations.

Yep.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

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

Re: [HACKERS] Prototype: In-place upgrade v02

Bruce Momjian wrote:
> As far as the page not fitting after conversion, what about some user
> command that will convert an entire table to the new format if page
> expansion fails.

VACUUM?

Having to run a manual command defeats the purpose somewhat, though.
Especially if you have no way of knowing on what tables it needs to be
run on.

> I am ready to focus on these issues for 8.4; all this needs to be
> fleshed out, perhaps on a wiki. As a starting point, what would be
> really nice is to start a wiki that lists all data format changes for
> every major release.

Have you looked at http://wiki.postgresql.org/wiki/In-place_upgrade
already, that Greg Smith mentioned elsewhere in this thread? That's a
good starting point.

In fact, I don't think there's any low-level data format changes yet
between 8.3 and 8.4, so this would be a comparatively easy release to
implement upgrade-in-place. There's just the catalog changes, but AFAICS
nothing that would require scanning through relations.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

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