Friday, June 13, 2008

[pgsql-www] Translated documentations

Hi,

JPUG(Japan PostgreSQL Users Group) has been translating the PostgreSQL
docs into Japanese and been distributing through their web site. The
translation work is surprisingly fast, usually Japanese translated
docs are uploaded no later than 1 week after PostgreSQL is
released. Thanks those who are volunteering the work.

I think it would be nice that PostgreSQL main web site has the
translated docs or has a link to them. Many open source projects do
this way. This is not only usefull but good to appeal how the world
wide PostgreSQL commnuities help each other.

What do you think?
--
Tatsuo Ishii
SRA OSS, Inc. Japan

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

Posted by at No comments:

Re: [pgsql-advocacy] PostgreSQL passes MySQL for Freshmeat Downloads

Joshua D. Drake wrote:
> Jonathan Fuerth wrote:
>> Hi again,
>
>> If the check itself fails for some reason (HTTP error, scrape fails to
>> find latest version, ...) then it will email a different configurable
>> list of people (especially me so I can fix it).
>>
>> So... who would like to be added to which list(s), and how frequently
>> should I run the check?
>
> pgsql-www, say --- once a month?

What would be cool is if it could track the version RSS feed from
www.postgresql.org to figure out when it needs to go out and check the
others...

//Magnus

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

Posted by at No comments:

Re: [pgsql-advocacy] PostgreSQL passes MySQL for Freshmeat Downloads

Jonathan Fuerth wrote:
> Hi again,

> If the check itself fails for some reason (HTTP error, scrape fails to
> find latest version, ...) then it will email a different configurable
> list of people (especially me so I can fix it).
>
> So... who would like to be added to which list(s), and how frequently
> should I run the check?

pgsql-www, say --- once a month?

Joshua D. Drake

P.S. Great work!

>
> -Jonathan
>


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

Posted by at No comments:

Re: [pgsql-advocacy] PostgreSQL passes MySQL for Freshmeat Downloads

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

- --On Saturday, June 14, 2008 00:04:05 -0400 Jonathan Fuerth
<fuerth@sqlpower.ca> wrote:

> Hi again,
>
> I've finished the version alerter. It finds the latest version number
> at http://www.postgresql.org/ftp/source/, then verifies that version
> number appears in a configurable list of web pages. It's easy to add
> new ones.
>
> Right now, I've got it up and running against the PostgreSQL entries
> on freshmeat, SourceForge, and Wikipedia.
>
> Here's what a notification looks like:
>
> ---
>
> From: daemon@(no spam please)
> To: fuerth@(no spam please)
> To: other@(no spam please)
> Subject: Version check alert!
> Date: Sat, 14 Jun 2008 00:34:39 -0400 (EDT)
>
> Latest version: 8.3.3
>
> freshmeat: needs update!
> SourceForge: up to date
> Wikipedia: up to date
>
> ---
>
> If all sites are up to date, no email is sent.
>
> If at least one site is out of date, an email like the above is sent
> to a configurable list of people.
>
> If the check itself fails for some reason (HTTP error, scrape fails to
> find latest version, ...) then it will email a different configurable
> list of people (especially me so I can fix it).
>
> So... who would like to be added to which list(s), and how frequently
> should I run the check?

Add me for freshmeat ...

Thx

- --
Marc G. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org)
Email . scrappy@hub.org MSN . scrappy@hub.org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)

iEYEARECAAYFAkhTRUEACgkQ4QvfyHIvDvO9awCgjcMBYby4ZItMz/grJeR/vGzu
wJIAoI8CPbIMwqhPuH37IVBaWLHCg2Je
=/uPm
-----END PGP SIGNATURE-----


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

Posted by at No comments:

Re: [pgsql-advocacy] PostgreSQL passes MySQL for Freshmeat Downloads

Hi again,

I've finished the version alerter. It finds the latest version number
at http://www.postgresql.org/ftp/source/, then verifies that version
number appears in a configurable list of web pages. It's easy to add
new ones.

Right now, I've got it up and running against the PostgreSQL entries
on freshmeat, SourceForge, and Wikipedia.

Here's what a notification looks like:

---

From: daemon@(no spam please)
To: fuerth@(no spam please)
To: other@(no spam please)
Subject: Version check alert!
Date: Sat, 14 Jun 2008 00:34:39 -0400 (EDT)

Latest version: 8.3.3

freshmeat: needs update!
SourceForge: up to date
Wikipedia: up to date

---

If all sites are up to date, no email is sent.

If at least one site is out of date, an email like the above is sent
to a configurable list of people.

If the check itself fails for some reason (HTTP error, scrape fails to
find latest version, ...) then it will email a different configurable
list of people (especially me so I can fix it).

So... who would like to be added to which list(s), and how frequently
should I run the check?

-Jonathan

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

Posted by at No comments:

Re: [pgsql-es-ayuda] Ayuda

2008/6/13 Esteban Carrascal Jimenez <esteban.carrascal@gmail.com>:
> Hola,
>
> Tengo un proceso que ejecuto para actualizar diariamente unas tablas, el
> problema es que ahora ultimo que intento ejecutar el proceso me envia este
> error:
>
> SQL Exception: Backend start-up failed: FATAL 1: cannot open pg_proc: No
> such file or directory
> .

podemos ver el error que bota postgres? el que muestras es el del JDBC...
no has borrado nada del servidor? ejecutas vacuum regularmente?
que version de postgres es esta?


--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Guayaquil - Ecuador
Cel. (593) 87171157
--
TIP 9: visita nuestro canal de IRC #postgresql-es en irc.freenode.net

Posted by at No comments:

Re: [GENERAL] Overloading

On Fri, Jun 13, 2008 at 06:11:43PM -0700, Ralph Smith wrote:

> I get:
> ERROR: cannot change return type of existing function
> HINT: Use DROP FUNCTION first.

Don't use CREATE OR REPLACE for the second one. The OR REPLACE is
trying to replace a function of the same name.

A

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

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

Posted by at No comments:

Re: [HACKERS] TODO Item: Allow pg_hba.conf to specify host names along with IP addresses

On Fri, Jun 13, 2008 at 08:51:19PM +0100, Simon Riggs wrote:

> The best of both ideas would be to have an option inside pg_hab.conf to
> indicate when lookup occurs. Some parts of a network are static, others
> are not, so a global option would not be useful.

We would point and laugh at people who thought that something was
"static" inside PostgreSQL, and depended on that for something
critical without some pretty heavy-duty locks. Are we really
proposing to offer an authentication mechanism that depends on
something as flimsy as hostname lookups in the DNS, and then not
insist that the bare minimum of integrity check ("I checked this DNS
lookup at connection time") is the rule?

DNS is a distributed database. Surely the least we can demand is that
the lookup happen when the naive think it will (i.e., at the time the
connection from that hostname happens).

> If the user knows a portion of their network is static,

If there were the slightest evidence that users historically believed
in such "knowledge" correctly, then I might have some sympathy for
this. The fact is that DNS (at least without DNSSEC) is one of the
areas in which sysadmins have the worst record of trust to this day.
I think we'd be fools to encourage such trust. If you don't look up
at _least_ at connection time, this feature should be rejected on the
grounds that it opens a new authentication hole a mile wide.

A

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

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

Posted by at No comments:

[GENERAL] Overloading

I never did get an answer to this.

I get:
ERROR:  cannot change return type of existing function
HINT:  Use DROP FUNCTION first.

********** Error **********

ERROR: cannot change return type of existing function
SQL state: 42P13
Hint: Use DROP FUNCTION first.


When I try to:

  CREATE OR REPLACE FUNCTION check_date_ymd(given_date varchar) RETURNS BOOLEAN  AS
and
  CREATE OR REPLACE FUNCTION check_date_ymd(given_date varchar, OUT isvalid boolean, OUT ryear int, OUT rmonth int, OUT rday int)  AS

I wanted to an 'is it valid' version, and another that would save runtime by also returning values that would speed up the
function date_to_utime().

in pg_proc there is no 'check_date_ymd', so there is no 'collision'.

Can someone elucidate me on this?

Thanks!
Ralph



Posted by at No comments:

Re: [HACKERS] Options for protocol level cursors

On Jun 13, 2008, at 4:40 PM, Kris Jurka wrote:
> The JDBC driver would also like this ability, but a GUC is a pretty
> ugly hack.

I completely agree that it is an ugly hack. :)

> Also, since you still have to go to the SQL level to issue the MOVE
> or FETCH BACKWARD, you're still not all the way there to a full
> protocol solution.

Completely true. However, this is, of course, only pertinent to SCROLL
cursors.

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

Posted by at No comments:

[pgsql-es-ayuda] Ayuda

Hola,

Tengo un proceso que ejecuto para actualizar diariamente unas tablas, el problema es que ahora ultimo que intento ejecutar el proceso me envia este error:

SQL Exception: Backend start-up failed: FATAL 1:  cannot open pg_proc: No such file or directory
.
org.postgresql.util.PSQLException: Backend start-up failed: FATAL 1:  cannot open pg_proc: No such file or directory

Por favor alguien me puede ayudar con esto

Gracias

Posted by at No comments:

Re: [HACKERS] Proposal: Multiversion page api (inplace upgrade)

Bruce Momjian napsal(a):
> Heikki Linnakangas wrote:
>> Zdenek Kotala wrote:
>>> 4) Implementation
>>>
>>> The main point of implementation is to have several version of
>>> PageHeader structure (e.g. PageHeader_04, PageHeader_03 ...) and correct
>>> structure will be handled in special branch (see examples).
>> (this won't come as a surprise as we talked about this in PGCon, but) I
>> think we should rather convert the page structure to new format in
>> ReadBuffer the first time a page is read in. That would keep the changes
>> a lot more isolated.
>>
>> Note that you need to handle not only page header changes, but changes
>> to internal representations of different data types, and changes like
>> varvarlen and combocid. Those are things that have happened in the past;
>> in the future, I'm foreseeing changes to the toast header, for example,
>> as there's been a lot of ideas related to toast options compression.
>
> I understand the goal of having good modularity (not having ReadBuffer
> modify the page), but I am worried that doing multi-version page
> processing in a modular way is going to spread version-specific
> information all over the backend code, making is harder to understand.

I don't think so. Page already contains page version information inside and
currently we have macros like PageSetLSN. Caller needn't know nothing about
PageHeader representation. It is responsibility of page API to correctly handle
multi version.

The same we can use for tuple access. It is more complicated but I think it is
possible. Currently we several macros (e.g. HeapTupleGetOid) which works on
TupleData structure. "Only" what we need is extend this API as well.

I think in final we will get more readable code.

Zdenek


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

Posted by at No comments:

[BUGS] Purge Oid

Hallo,

 

I’ve a problem with postgress 8.1,

 

Db_data FS is full because file oid are too large, how I can delete old OID file without to risk to damage oid relation database

 

 

 

 

Thks

 

 

Alessandro

 

Internet Email Confidentiality Footer

********************************************************************************************************************************************

La presente comunicazione, con le informazioni in essa contenute e ogni documento o file allegato, e' rivolta unicamente alla/e persona/e cui e' indirizzata ed alle altre da questa autorizzata/e a riceverla. Se non siete i destinatari/autorizzati siete avvisati che qualsiasi azione, copia, comunicazione, divulgazione o simili basate sul contenuto di tali informazioni e' vietata e potrebbe essere contro la legge (art. 616 C.P., D.Lgs n. 196/2003 Codice in materia di protezione dei dati personali). Se avete ricevuto questa comunicazione per errore, vi preghiamo di darne immediata notizia al mittente e di distruggere il messaggio originale e ogni file allegato senza farne copia alcuna o riprodurne in alcun modo il contenuto.

This e-mail and its attachments are intended for the addressee(s) only and are confidential and/or may contain legally privileged information. If you have received this message by mistake or are not one of the addressees above, you may take no action based on it, and you may not copy or show it to anyone; please reply to this e-mail and point out the error which has occurred.
********************************************************************************************************************************************

Posted by at No comments:

Fwd: [pgsql-es-ayuda] Copia y restauracion de base de datos de GForge

Para crear la copia de la bbdd lo he hecho con pg_dump:
pg_dump -c -v -f $ARCHIVEROOT/$INCREMENTDIR/$BACKUP_BBDD -U $USERNAME $DBNAME
Y para restaurarla, con:
psql -f $ARCHIVEROOT/$INCREMENTDIR/$BACKUP_BBDD -d $DBNAME -U $USERNAME

Pero nada, me sigue dando errores

Algunos errores al restaurarlo (me da muchos):
psql:/backup/diarias/GForge/backup_13-06-2008/bbdd_GForge_13-06-2008.sql:32134:
ERROR: error de sintaxis en o cerca de «1» en el carácter 1
psql:/backup/diarias/GForge/backup_13-06-2008/bbdd_GForge_13-06-2008.sql:32134:
LINEA 1: 1 project 1
psql:/backup/diarias/GForge/backup_13-06-2008/bbdd_GForge_13-06-2008.sql:32134:
^
psql:/backup/diarias/GForge/backup_13-06-2008/bbdd_GForge_13-06-2008.sql:32137:
comando \. no válido
psql:/backup/diarias/GForge/backup_13-06-2008/bbdd_GForge_13-06-2008.sql:32146:
ERROR: error de sintaxis en o cerca de «1» en el carácter 1
psql:/backup/diarias/GForge/backup_13-06-2008/bbdd_GForge_13-06-2008.sql:32146:
LINEA 1: 1 Bash /bin/bash
psql:/backup/diarias/GForge/backup_13-06-2008/bbdd_GForge_13-06-2008.sql:32146:
^
psql:/backup/diarias/GForge/backup_13-06-2008/bbdd_GForge_13-06-2008.sql:32147:
comando \N no válido
psql:/backup/diarias/GForge/backup_13-06-2008/bbdd_GForge_13-06-2008.sql:36138:
ERROR: error de sintaxis en o cerca de «100» en el carácter 1
psql:/backup/diarias/GForge/backup_13-06-2008/bbdd_GForge_13-06-2008.sql:36138:
LINEA 1: 100 none root@localhost.localdomain 2 2006-06-12
17:37:11....
psql:/backup/diarias/GForge/backup_13-06-2008/bbdd_GForge_13-06-2008.sql:36138:
^
psql:/backup/diarias/GForge/backup_13-06-2008/bbdd_GForge_13-06-2008.sql:30911:
comando \nEnviado no válido
El búfer de consulta ha sido reiniciado (limpiado).
psql:/backup/diarias/GForge/backup_13-06-2008/bbdd_GForge_13-06-2008.sql:30912:
comando \n no válido
El búfer de consulta ha sido reiniciado (limpiado).
psql:/backup/diarias/GForge/backup_13-06-2008/bbdd_GForge_13-06-2008.sql:30914:
comando \n no válido
El búfer de consulta ha sido reiniciado (limpiado).
psql:/backup/diarias/GForge/backup_13-06-2008/bbdd_GForge_13-06-2008.sql:30916:
comando \n no válido
psql:/backup/diarias/GForge/backup_13-06-2008/bbdd_GForge_13-06-2008.sql:30920:
ERROR: error de sintaxis en o cerca de «209» en el carácter 1
psql:/backup/diarias/GForge/backup_13-06-2008/bbdd_GForge_13-06-2008.sql:30920:
LINEA 1: 209 102 105 2008-06-02 17:19:27.750892+02 No está resuelta
h...
psql:/backup/diarias/GForge/backup_13-06-2008/bbdd_GForge_13-06-2008.sql:30920:
^
psql:/backup/diarias/GForge/backup_13-06-2008/bbdd_GForge_13-06-2008.sql:30920:
ERROR: error de sintaxis en o cerca de «collect» en el carácter 1
psql:/backup/diarias/GForge/backup_13-06-2008/bbdd_GForge_13-06-2008.sql:30920:
LINEA 1: collect digits&quot;
psql:/backup/diarias/GForge/backup_13-06-2008/bbdd_GForge_13-06-2008.sql:30920:
^
psql:/backup/diarias/GForge/backup_13-06-2008/bbdd_GForge_13-06-2008.sql:30920:
ERROR: error de sintaxis en o cerca de «.» en el carácter 1
psql:/backup/diarias/GForge/backup_13-06-2008/bbdd_GForge_13-06-2008.sql:30920:
LINEA 1: . Si AES detecta el collect digits antes de finalizar la
tra...
psql:/backup/diarias/GForge/backup_13-06-2008/bbdd_GForge_13-06-2008.sql:30920:
^
psql:/backup/diarias/GForge/backup_13-06-2008/bbdd_GForge_13-06-2008.sql:30920:
ERROR: error de sintaxis en o cerca de «no» en el carácter 1
psql:/backup/diarias/GForge/backup_13-06-2008/bbdd_GForge_13-06-2008.sql:30920:
LINEA 1: no es posible realizar transfer&quot;
psql:/backup/diarias/GForge/backup_13-06-2008/bbdd_GForge_13-06-2008.sql:30920:
^
psql:/backup/diarias/GForge/backup_13-06-2008/bbdd_GForge_13-06-2008.sql:30920:
ERROR: error de sintaxis en o cerca de «.» en el carácter 1
psql:/backup/diarias/GForge/backup_13-06-2008/bbdd_GForge_13-06-2008.sql:30920:
LINEA 1: . Se ha puesto un wait time de 5seg en este vector y le da
t...
psql:/backup/diarias/GForge/backup_13-06-2008/bbdd_GForge_13-06-2008.sql:30920:
^
psql:/backup/diarias/GForge/backup_13-06-2008/bbdd_GForge_13-06-2008.sql:30920:
ERROR: error de sintaxis en o cerca de «soltar» en el carácter 1
psql:/backup/diarias/GForge/backup_13-06-2008/bbdd_GForge_13-06-2008.sql:30920:
LINEA 1: soltar&quot;
psql:/backup/diarias/GForge/backup_13-06-2008/bbdd_GForge_13-06-2008.sql:30920:


Linea 32134:
CREATE OPERATOR >= (
PROCEDURE = tsvector_ge,
LEFTARG = tsvector,
RIGHTARG = tsvector,
COMMUTATOR = <=,
NEGATOR = <,
RESTRICT = contsel,
JOIN = contjoinsel
);


ALTER OPERATOR public.>= (tsvector, tsvector) OWNER TO postgres;

Linea 32146:
CREATE TABLE tracker_my_queue (
user_id integer NOT NULL,
tracker_item_id integer NOT NULL,
sort_order integer DEFAULT 0
);


ALTER TABLE public.tracker_my_queue OWNER TO gforge;

Linea 30920:
500 2008-06-04 13:28:39.184073+02 105 trackeritem 146
assignee Nombre Ejemplo None

Esto está dentro de:
COPY audit_trail (audit_trail_id, change_date, user_id, section,
ref_id, field_name, new_value, old_value) FROM stdin;


En teoría, al crear una copia de la bbdd, y al restaurarla, no tendría
que dar ningún error, y los dá...

No entiendo nada, si la bbdd está creada y con esos datos....

2008/6/11, Alvaro Herrera <alvherre@commandprompt.com>:
> Clemente López Giner escribió:
>
>> Me da errores de privilegios y relaciones, no puede dar privilegios y
>> algunas relaciones dice que no existen (o que ya existían), cuando
>> debería de volver a crear todo de nuevo, sin importar lo anterior.
>
> Si quieres que cree todo de nuevo, usa --clean.
>
> Para respaldar los roles existentes, usa pg_dumpall -g (supongo que
> deberias restaurar esto antes de intentar restaurar cualquier otra
> cosa).
>
> --
> Alvaro Herrera

http://www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.
>
--
TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda

Posted by at No comments:

Re: [HACKERS] a problem when poring from Oracle's PL/SQL to PLPGSQL

billy schrieb:
> pgsql-hackers:
>
> The following is Oracle's PL/SQL
>
> if resTypeTableName is null
> then
> queryStr := 'select IntIID, Path FROM aaResourceData' || ' where ResType=''' || srcType || ''' and ResID=''' || srcID || '''';
> else queryStr := 'select IntIID, Path FROM ' || resTypeTableName || ' where ResType=''' || srcType || ''' and ResID=''' ||
> srcID || '''';
> end if;
>
> open cursorSrc for queryStr;
>
>
> Here queryStr is a variable which type is TEXT OR VARCHAR or other string types.
>
> But in PLPGSQL, we can only open a cursor this way:
>
> open cursorSrc for select * from testtable;
>
> We cannot substitude "select * from testtable" with a variable.
>
> Is there another way to handle it?
>
> Thank you for your help. :-)
>
open cursorSrc for execute queryStr; should work fine

Regards
Mario Weilguni


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

Posted by at No comments:

[HACKERS] a problem when poring from Oracle's PL/SQL to PLPGSQL

pgsql-hackers:

The following is Oracle's PL/SQL

if resTypeTableName is null
then
queryStr := 'select IntIID, Path FROM aaResourceData' || ' where ResType=''' || srcType || ''' and ResID=''' || srcID || '''';
else queryStr := 'select IntIID, Path FROM ' || resTypeTableName || ' where ResType=''' || srcType || ''' and ResID=''' ||
srcID || '''';
end if;

open cursorSrc for queryStr;


Here queryStr is a variable which type is TEXT OR VARCHAR or other string types.

But in PLPGSQL, we can only open a cursor this way:

open cursorSrc for select * from testtable;

We cannot substitude "select * from testtable" with a variable.

Is there another way to handle it?

Thank you for your help. :-)


　　　　　　　　billy
　　　　　　　　billywq@163.com
　　　　　　　　　　2008-06-13


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

Posted by at No comments:

[HACKERS] pg_stat_statements

Hello,

Postgres 8.4 has pg_stat_user_functions view to track number of calls of
stored functions and time spent in them. Then, I'm thinking a "sql statement"
version of similar view -- pg_stat_statements.

Prepared statements and statements using extended protocol are grouped
by their sql strings without parameters, that is the just same as
pg_stat_user_functions. We could ignore simple queries with parameters
because they have different expression for each execution.

We can write sql statements in server logs and gather them using some tools
(pgfouine and pqa) even now, but statement logging has unignorable overhead.
Lightweight view is useful for typical users who are only interedted in
aggregated results.


One issue is how and where to store sql strings. We could use hash values
of statement strings as short identifiers, but we need to store sql strings
somewhere to compare the IDs and original statements.

1. Store SQLs in shared memory
We need to allocate fixed region on starting servers. Should we have
another memory setting into postgresql.conf?

2. Store SQLs in stats collector process's memory
We can use dynamically allocated memory, but sending sql statements to
stat collector process is probably slow and stat file will be large.

I'm not sure which is better. It might have relevance to discussion of
shared prepared statements.


Another issue is that we could implement the feature as an add-on,
not a core feature. We can use general hooks for this purpose; We store
sql statement and their hash values in planner_hook, and record number
of execution and time in new executor begin/end hooks or by adding
a "stop-watch" executor node. Should this feature be in the core or not?
For example, dynamic shared memory allocation might be need before we move
the feature in the core.

Comments and suggestions welcome.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center


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

Posted by at No comments:

Re: [HACKERS] Proposal: Multiversion page api (inplace upgrade)

Ron Mayer napsal(a):
> Tom Lane wrote:
>> Another issue is that it might not be possible to update a page for
>> lack of space. Are we prepared to assume that there will never be a
>> transformation we need to apply that makes the data bigger? In such a
>> situation an in-place update might be impossible, and that certainly
>> takes it outside the bounds of what ReadBuffer can be expected to manage.
>
> Would a possible solution to this be that you could
>

<snip>

>
> 2. Run some new maintenance command like "vacuum expand" or
> "vacuum prepare_for_upgrade" or something that would split
> any too-full pages, leaving only pages with enough space.

It does not solve problems for example with TOAST tables. If chunks does not fit
on a new page layout one of the chunk tuple have to be moved to free page. It
means you get a lot of pages with ~2kB of free unused space. And if max chunk
size is different between version you got another problem as well.

There is also idea to change compression algorithm for 8.4 (or offer more
varinats). It also mean that you need to understand old algorithm in a new
version or you need to repack everything on old version.


Zdenek

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

Posted by at No comments:

Re: [pgsql-www] [torontopug] New User Groups: Toronto, Oklahoma

On Thu, Jun 12, 2008 at 3:45 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Magnus Hagander escribió:
>
>> I think I saw a commit come through from Alvaro that should make the
>> archives work automatically as well. Everything on the website is driven
>> from the database since a couple of months back.
>
> Sorry, that was a first step, but more work is needed.

OK, so I've added both to index.php and includes/top_config.php, as
per the old days :-p

The individual index pages for each pug seem to have been created
automagically now.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

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

Posted by at No comments:

Re: [pgsql-advocacy] PostgreSQL derivatives

On Fri, Jun 13, 2008 at 8:21 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>
> On Thu, 2008-06-12 at 13:26 -0700, Joshua D. Drake wrote:
>> On Thu, 2008-06-12 at 21:21 +0100, Simon Riggs wrote:
>> > On Thu, 2008-06-12 at 10:42 +0200, Magnus Hagander wrote:
>> > > Dave Page wrote:
>>
>> > I do. Non-profit organisations must be run "without fear or favour"
>> and
>>
>> Well PostgreSQL.Org is not a non profit organization
>
> That is news to me. Who gets the financial profits then? Why are we
> registering in various countries as a non-profit?

postgresql.org isn't, and never has registered as a non-profit. We
have individual user groups that are registering themselves around the
world, but they are organised independently of postgresql.org, though
obviously there is overlap in the people involved and mission etc.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

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

Posted by at No comments:

Re: [pgsql-es-ayuda] Opcion TABLESPACE al crear una tabla.

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

>
> Has hecho el intento para ver que ocurre? o solo "prefieres evitar la fatiga"?
>

Es que no se como ver en que tablespace se crea la tabla. Por eso he
preguntado, de lo contrario me habría molestado en mirarlo yo mismo sin
molestar a la lista.

¿Sabrías como se puede ver en que tablespace se ha creado?.
- --


< ¡¡Nos vemos!! >
----------------------------
\
\
.::!!!!!!!:.
.!!!!!:. .:!!!!!!!!!!!!
~~~~!!!!!!. .:!!!!!!!!!UWWW$$$
:$$NWX!!: .:!!!!!!XUWW$$$$$$$$$P
$$$$$##WX!: .<!!!!UW$$$$" $$$$$$$$#
$$$$$ $$$UX :!!UW$$$$$$$$$ 4$$$$$*
^$$$B $$$$\ $$$$$$$$$$$$ d$$R"
"*$bd$$$$ '*$$$$$$$$$$$o+#"
"""" """""""
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIUiG5K7lGsMchFswRAg6jAJ42HxQoSWqAZxm4K4U3RUXei0VIJQCeJ8gd
xb0AuWI1k5XzjMglr9BquqA=
=RlD6
-----END PGP SIGNATURE-----
--
TIP 10: no uses HTML en tu pregunta, seguro que quien responda no podrá leerlo

Posted by at No comments:

Re: [pgsql-advocacy] PostgreSQL derivatives

On Thu, 2008-06-12 at 13:26 -0700, Joshua D. Drake wrote:
> On Thu, 2008-06-12 at 21:21 +0100, Simon Riggs wrote:
> > On Thu, 2008-06-12 at 10:42 +0200, Magnus Hagander wrote:
> > > Dave Page wrote:
>
> > I do. Non-profit organisations must be run "without fear or favour"
> and
>
> Well PostgreSQL.Org is not a non profit organization

That is news to me. Who gets the financial profits then? Why are we
registering in various countries as a non-profit?

--
Simon Riggs

www.2ndQuadrant.com

PostgreSQL Training, Services and Support


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

Posted by at No comments:

Re: [pgsql-advocacy] PostgreSQL derivatives

On Thu, 2008-06-12 at 22:31 -0400, Bruce Momjian wrote:
> Simon Riggs wrote:
> > > And in the end, I don't see any reason for us to *turn down* sponsorship
> >
> > I do. Non-profit organisations must be run "without fear or favour" and
> > that includes not accepting gifts of any kind, though anonymous
> > donations are always acceptable.
> >
> > If we don't do this, then people may get the impression that certain
> > companies dominate and that can easily lead to non-contribution. So
> > IMHO, being even handed is critically important to our future.
>
> I am not sure how anonymous-only contributions are supposed to work.
> EnterpriseDB employs me, but no one is supposed to know that?
> EnterpriseDB sponsors a dinner at PGCon but the sponsor is a secret?
>
> We can do anonymous-only contributions, but that is going to certainly
> limit contributions. I am not sure how a company contribution will be
> explained to the accounting staff if it has to be anonymous.
>
> I think the big question is what are anonymous-only contributions trying
> to solve? I have never heard of problems of favortism to contributors,
> so why take a hit on contributions to avoid something no one has
> reported to have happened?

I'm expressing a clear principle. I don't see this principle as being
hard to implement. "Peace talks, sponsored by Group X", will be unlikely
to bring the other party to the table.

I want to demonstrate a level playing field, so that all feel welcome to
contribute. I am worried that if things get out of balance then it will
go badly for us in the future. Unfortunately, those are principles, not
clear guidelines, so yes, what I have asked for raises many questions.

--
Simon Riggs

www.2ndQuadrant.com

PostgreSQL Training, Services and Support


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

Posted by at No comments:

Re: [pgsql-it-generale] to_tsvector: errori nella configurazione italiana

Ciao Federico,

rotellaro@gmail.com ha scritto:
> Il database su cui stai operando suppongo sia UTF8.
> Sarebbe interessante capire come sono caricati questi dati e
> l'encoding dell'eventuale database di origine.

Sì. Più informazioni hai e meglio è.

> Ad ogni modo prova la seguente procedura.
> Esporta il database di origine con pg_dump passandogli l'opzione
> --encoding=UTF8.
> Converti il dump in utf8 con iconv
> http://www.gnu.org/software/libiconv/documentation/libiconv/iconv.1.html
> e caricalo in un altro database creato esplicitamente in UTF8.

Può essere senz'altro una idea. Sempre che il problema non sia nelle
stop word. Sono interessato a sapere che PG usa sul suo Mac Giorgio. Non
vorrei fosse un problema limitato a questo OS e all'eventuale pacchetto
usato.

Ciao,
Gabriele

--
Gabriele Bartolini: Open source programmer and data architect
Current Location: Prato, Tuscany, Italy
Associazione Italian PostgreSQL Users Group: www.itpug.org
gabriele.bartolini@gmail.com | www.gabrielebartolini.it
"If I had been born ugly, you would never have heard of Pelé", George Best
http://www.linkedin.com/in/gbartolini

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

Posted by at No comments:

Re: [pgsql-it-generale] to_tsvector: errori nella configurazione italiana

Ciao Giorgio,

benvenuto. :)

Potresti inviare alcune informazioni quali:

1) encoding del database
2) encoding di default del server ('show server encoding')
3) encoding del client ('show client encoding')

Inoltre, che versione di PostgreSQL usi? L'hai ricompilata te con
macports oppure usi un pacchetto particolare?

>>> ERROR: invalid byte sequence for encoding "UTF8": 0xc3
>>> HINT: This error can also happen if the byte sequence does not match
>>> the encoding expected by the server, which is controlled by
>>> "client_encoding".

Il carattere di controllo 0xC3 indica infatti una sequenza multibyte
UTF8. Sembra davvero che testo non UTF8 sia letto in modalità UTF8.

Ciao,
Gabriele
--
Gabriele Bartolini: Open source programmer and data architect
Current Location: Prato, Tuscany, Italy
Associazione Italian PostgreSQL Users Group: www.itpug.org
gabriele.bartolini@gmail.com | www.gabrielebartolini.it
"If I had been born ugly, you would never have heard of Pelé", George Best
http://www.linkedin.com/in/gbartolini

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

Posted by at No comments:

Re: [pgsql-it-generale] to_tsvector: errori nella configurazione italiana

2008/6/13 Giorgio Valoti <giorgio_v@mac.com>:
> Ciao a tutti, riposto qui questa mia richiesta su pgsql-general che non ha
> avuto risposta. Avendo scoperto solo ora che esiste anche una mailing list
> italiana ho pensato che forse c'era qualcuno che poteva darmi qualche
> suggerimento. Ho una discreta esperienza con pgsql ma non ho mai usato la
> ricerca full-text per cui sono un po' perso.
> Mi scuso in anticipo per non aver ritradotto il messaggio ma penso sarà
> sufficientemente chiaro:
>
snip!
dimenticavo la cosa piu' banale.
Prima del test che ti ho indicato prova a lanciare la select dopo aver dato un:
set CLIENT_ENCODING='UTF8';

Riciao
Fede

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

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

Posted by at No comments:
Subscribe to: Posts (Atom)