Re: [GENERAL] pg_standby stuck on a wal file size <16MB

On Sun, May 18, 2008 at 12:17 AM, Vladimir Kosilov <vkosilov@gmail.com> wrote:

I've been having problem with pgsql-8.2.5 master/slave warm standby replication setup where occasionally master node generates a wal file smaller then expected 16MB. pg_standby on slave gets stuck on such short files, and replication halts from that moment on. we have to do pg_start_backup/ rsync of data to slave / pg_stop_backup and restart slave in order to recover. database I'm replicating is write mostly.

this is process on slave that is waiting on log file which is smaller in size:
postgres 14277 11857  0 03:34 ?        00:00:00 sh -c /usr/local/pgsql/bin/pg_standby -d -k 255 -r 7 -s 10 -w 0 -t /usr/local/recovery_control/quit_recovery /usr/local/wal_archive 000000010000034000000020 pg_xlog/RECOVERYXLOG 2>> /usr/local/pgsql/data/standby.log
postgres 14278 14277  0 03:34 ?        00:00:00 /usr/local/pgsql/bin/pg_standby -d -k 255 -r 7 -s 10 -w 0 -t /usr/local/recovery_control/quit_recovery /usr/local/wal_archive 000000010000034000000020 pg_xlog/RECOVERYXLOG

here is a sample list of wal_archive directory slave, note the size of 000000010000034000000020 expected wal file is less then 16MB:

...
-rw------- 1 postgres postgres 16777216 May 17 03:19 000000010000034000000017
-rw------- 1 postgres postgres 16777216 May 17 03:21 000000010000034000000018
-rw------- 1 postgres postgres 16777216 May 17 03:22 000000010000034000000019
-rw------- 1 postgres postgres 16777216 May 17 03:24 00000001000003400000001A
-rw------- 1 postgres postgres 16777216 May 17 03:26 00000001000003400000001B
-rw------- 1 postgres postgres 16777216 May 17 03:27 00000001000003400000001C
-rw------- 1 postgres postgres 16777216 May 17 03:29 00000001000003400000001D
-rw------- 1 postgres postgres 16777216 May 17 03:30 00000001000003400000001E
-rw------- 1 postgres postgres 16777216 May 17 03:32 00000001000003400000001F

-rw------- 1 postgres postgres 13746176 May 17 03:34 000000010000034000000020

-rw------- 1 postgres postgres 16777216 May 17 03:35 000000010000034000000021
-rw------- 1 postgres postgres 16777216 May 17 03:37 000000010000034000000022
-rw------- 1 postgres postgres 16777216 May 17 03:38 000000010000034000000023
-rw------- 1 postgres postgres 16777216 May 17 03:40 000000010000034000000024
-rw------- 1 postgres postgres 16777216 May 17 03:41 000000010000034000000025
-rw------- 1 postgres postgres 16777216 May 17 03:43 000000010000034000000026
-rw------- 1 postgres postgres 16777216 May 17 03:45 000000010000034000000027
...

skipping a bit further I see there is at least one other instance where wal file is shorter then normal 16MB:

-rw------- 1 postgres postgres 16777216 May 17 05:42 00000001000003400000006F
-rw------- 1 postgres postgres 16777216 May 17 05:44 000000010000034000000070
-rw------- 1 postgres postgres 16777216 May 17 05:46 000000010000034000000071
-rw------- 1 postgres postgres 16777216 May 17 05:47 000000010000034000000072

-rw------- 1 postgres postgres    16384 May 17 05:50 000000010000034000000073

-rw------- 1 postgres postgres 16777216 May 17 05:51 000000010000034000000074
-rw------- 1 postgres postgres 16777216 May 17 05:52 000000010000034000000075
-rw------- 1 postgres postgres 16777216 May 17 05:54 000000010000034000000076

why would a master node create a wal file smaller then normal checkpoint_segment size and how can this be avoided. I need a reliable replication mechanism even at a cost of longer recovery on standby.

master's postgresql.conf:
..
fsync = on
wal_sync_method = open_sync
wal_buffers = 128
checkpoint_segments = 64
archive_command = 'test ! -f /usr/local/wal_archive_local/%f && cp %p /usr/local/wal_archive_local/%f'

archive files are then moved  on master to standby every other minute:

rsync -aq --remove-sent-files /usr/local/wal_archive_local/ slave::wal_archive/

slave's recovery.conf:
restore_command = '/usr/local/pgsql/bin/pg_standby -d -k 255 -r 7 -s 10 -w 0 -t /usr/local/recovery_control/quit_recovery /usr/local/wal_archive %f %p 2>> /u
sr/local/pgsql/data/standby.log'

both servers are identical Dell PE1950 servers with 4 sas hd w/hardware RAID 1+0 running:
2.6.18-8.1.8.el5 #1 SMP Tue Jul 10 06:39:17 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux

Thanks much in advance
V.

Any reason why you are not using rsync command in the archive_command in the first place?
 

gurjeet[.singh]@EnterpriseDB.com
singh.gurjeet@{ gmail | hotmail | indiatimes | yahoo }.com

EnterpriseDB http://www.enterprisedb.com

Mail sent from my BlackLaptop device

Re: [BUGS] [DOCS] wal_sync_method

On Sat, May 17, 2008 at 1:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> [ redirecting to -bugs ]
>
> "Jaime Casanova" <systemguards@gmail.com> writes:
>> On Sat, May 17, 2008 at 11:55 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> "Jaime Casanova" <systemguards@gmail.com> writes:
>>>> But in my freshly 8.3.1 instalation on win xp, the default is
>>>> "fsync"... is a *bug* in the docs :)
>>>
>>> More like a bug in the code. Does it let you set the value to
>>> open_datasync?
>
>> yes it does...
>
> Well, that's just bizarre. I found a problem in CVS HEAD that would
> lead to a bogus selection of the default for wal_sync_method, but it
> doesn't apply to 8.3. I really don't see how 8.3 would fail to use
> open_datasync as the default if it's an available value. Did you
> build 8.3.1 yourself, and if so how?
>

nop, default installer downloaded from postgresql.org...

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Guayaquil - Ecuador
Cel. (593) 087171157

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

Re: [pgsql-es-ayuda] INSTALR EN OTRA PARTICION

2008/5/17 Oswaldo Hernández <listas@soft-com.es>:
> Luis Fernando Curiel Cabrera escribió:
>>
>> Ahora sí, tengoq eu instalar postgres en un servidor con windows XP
>> Profesional. Quiero instalarlo de tal forma que toda la carpeta dinde se
>> guardan fisicamente las bases de datos ponerlo en una particion diferente a
>> C:
>>
>
> Para mi lo mas sencillo es:
>
> * Instalar normalmente
> * detener el servicio
> * mover la carpeta data a la nueva ubicación
> * modificar en el registro el comando que se utiliza para iniciar el
> servicio cambiandole la ruta de 'data'
> * iniciar el servicio.
>

y que tal instalar, indicando que la ubicacion de la carpeta data esta
en otro lado? eso lo haces en la pantalla en la que escojes que
quieres instalar (server, odbc, hdbc, headers, etc)

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Guayaquil - Ecuador
Cel. (593) 087171157
--
TIP 2: puedes desuscribirte de todas las listas simultáneamente
(envía "unregister TuDirecciónDeCorreo" a majordomo@postgresql.org)

Re: [BUGS] BUG #4179: pg_standby reports "file size greater than expected"

"Reinhard Zitzmann" <rz2008@insode.de> writes:
> When copying a WAL file with "cp --sparse=always ..." to a remote NFS
> directory, the remote file becomes 16777217 bytes long for a short
> time.

Seems to me this is a bug in cp, not Postgres.

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

[GENERAL] pg_standby stuck on a wal file size <16MB

I've been having problem with pgsql-8.2.5 master/slave warm standby
replication setup where occasionally master node generates a wal file
smaller then expected 16MB. pg_standby on slave gets stuck on such short
files, and replication halts from that moment on. we have to do
pg_start_backup/ rsync of data to slave / pg_stop_backup and restart
slave in order to recover. database I'm replicating is write mostly.

this is process on slave that is waiting on log file which is smaller in
size:
postgres 14277 11857 0 03:34 ? 00:00:00 sh -c
/usr/local/pgsql/bin/pg_standby -d -k 255 -r 7 -s 10 -w 0 -t
/usr/local/recovery_control/quit_recovery /usr/local/wal_archive
000000010000034000000020 pg_xlog/RECOVERYXLOG 2>>
/usr/local/pgsql/data/standby.log
postgres 14278 14277 0 03:34 ? 00:00:00
/usr/local/pgsql/bin/pg_standby -d -k 255 -r 7 -s 10 -w 0 -t
/usr/local/recovery_control/quit_recovery /usr/local/wal_archive
000000010000034000000020 pg_xlog/RECOVERYXLOG

here is a sample list of wal_archive directory slave, note the size of
000000010000034000000020 expected wal file is less then 16MB:

...
-rw------- 1 postgres postgres 16777216 May 17 03:19
000000010000034000000017
-rw------- 1 postgres postgres 16777216 May 17 03:21
000000010000034000000018
-rw------- 1 postgres postgres 16777216 May 17 03:22
000000010000034000000019
-rw------- 1 postgres postgres 16777216 May 17 03:24
00000001000003400000001A
-rw------- 1 postgres postgres 16777216 May 17 03:26
00000001000003400000001B
-rw------- 1 postgres postgres 16777216 May 17 03:27
00000001000003400000001C
-rw------- 1 postgres postgres 16777216 May 17 03:29
00000001000003400000001D
-rw------- 1 postgres postgres 16777216 May 17 03:30
00000001000003400000001E
-rw------- 1 postgres postgres 16777216 May 17 03:32
00000001000003400000001F

-rw------- 1 postgres postgres 13746176 May 17 03:34
000000010000034000000020

-rw------- 1 postgres postgres 16777216 May 17 03:35
000000010000034000000021
-rw------- 1 postgres postgres 16777216 May 17 03:37
000000010000034000000022
-rw------- 1 postgres postgres 16777216 May 17 03:38
000000010000034000000023
-rw------- 1 postgres postgres 16777216 May 17 03:40
000000010000034000000024
-rw------- 1 postgres postgres 16777216 May 17 03:41
000000010000034000000025
-rw------- 1 postgres postgres 16777216 May 17 03:43
000000010000034000000026
-rw------- 1 postgres postgres 16777216 May 17 03:45
000000010000034000000027
...

skipping a bit further I see there is at least one other instance where
wal file is shorter then normal 16MB:

-rw------- 1 postgres postgres 16777216 May 17 05:42
00000001000003400000006F
-rw------- 1 postgres postgres 16777216 May 17 05:44
000000010000034000000070
-rw------- 1 postgres postgres 16777216 May 17 05:46
000000010000034000000071
-rw------- 1 postgres postgres 16777216 May 17 05:47
000000010000034000000072

-rw------- 1 postgres postgres 16384 May 17 05:50
000000010000034000000073

-rw------- 1 postgres postgres 16777216 May 17 05:51
000000010000034000000074
-rw------- 1 postgres postgres 16777216 May 17 05:52
000000010000034000000075
-rw------- 1 postgres postgres 16777216 May 17 05:54
000000010000034000000076

why would a master node create a wal file smaller then normal
checkpoint_segment size and how can this be avoided. I need a reliable
replication mechanism even at a cost of longer recovery on standby.

master's postgresql.conf:
..
fsync = on
wal_sync_method = open_sync
wal_buffers = 128
checkpoint_segments = 64
archive_command = 'test ! -f /usr/local/wal_archive_local/%f && cp %p
/usr/local/wal_archive_local/%f'

archive files are then moved on master to standby every other minute:

rsync -aq --remove-sent-files /usr/local/wal_archive_local/
slave::wal_archive/

slave's recovery.conf:
restore_command = '/usr/local/pgsql/bin/pg_standby -d -k 255 -r 7 -s 10
-w 0 -t /usr/local/recovery_control/quit_recovery /usr/local/wal_archive
%f %p 2>> /u
sr/local/pgsql/data/standby.log'

both servers are identical Dell PE1950 servers with 4 sas hd w/hardware
RAID 1+0 running:
2.6.18-8.1.8.el5 #1 SMP Tue Jul 10 06:39:17 EDT 2007 x86_64 x86_64
x86_64 GNU/Linux

Thanks much in advance
V.

--
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] [DOCS] wal_sync_method

[ redirecting to -bugs ]

"Jaime Casanova" <systemguards@gmail.com> writes:
> On Sat, May 17, 2008 at 11:55 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> "Jaime Casanova" <systemguards@gmail.com> writes:
>>> But in my freshly 8.3.1 instalation on win xp, the default is
>>> "fsync"... is a *bug* in the docs :)
>>
>> More like a bug in the code. Does it let you set the value to
>> open_datasync?

> yes it does...

Well, that's just bizarre. I found a problem in CVS HEAD that would
lead to a bogus selection of the default for wal_sync_method, but it
doesn't apply to 8.3. I really don't see how 8.3 would fail to use
open_datasync as the default if it's an available value. Did you
build 8.3.1 yourself, and if so how?

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: [pgsql-es-ayuda] Problemas con tipo Serial

Eso puede pasar al hacer una inserción proporcionando el valor para el campo con tipo serial, y por lo mismo no se ejecuta nextval (no se usa el valor por default). Entonces la secuencia queda en un valor ya usado, y al momento de insertar usando otra vez el mecanismo regular, se obtiene el error de llaves duplicadas.

Si fue esto lo que pasó, actualizando la secuencia con setval se podría corregir, y por ejemplo, en caso de cargar datos mediante copy, realizar la misma acción (así es como funciona en los dumps, se hace un copy from stdin y mas adelante se restaura el valor correcto de la secuencia).

2008/5/17 Juan Manuel Fernandez <jmfernandez@unlu.edu.ar>:

Tengo en una tabla un ID de tipo SERIAL que al dia de hoy no me habia
dado problemas (tengo unas 93 inserciones ya realizadas).
Resulta que fui a hacer una inserción y me empezo a dar el error:

ERROR:  duplicate key value violates unique constraint
"t_asignaturas_dictadas_pkey"

A alguien le ha pasado?

Saludos,

               Juan
--
TIP 4: No hagas 'kill -9' a postmaster

Re: [pgsql-es-ayuda] Problemas con tipo Serial

Lo solucione borrando el atrbuto y volviendolo a crear, pero... puede
llegar a ser un bug?
Podria ser al menos peligroso...

Saludos,

Juan

2008/5/17 Juan Manuel Fernandez <jmfernandez@unlu.edu.ar>:
> Tengo en una tabla un ID de tipo SERIAL que al dia de hoy no me habia
> dado problemas (tengo unas 93 inserciones ya realizadas).
> Resulta que fui a hacer una inserción y me empezo a dar el error:
>
> ERROR: duplicate key value violates unique constraint
> "t_asignaturas_dictadas_pkey"
>
> A alguien le ha pasado?
>
> Saludos,
>
> Juan
>
--
TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda

Re: [DOCS] wal_sync_method

On Sat, May 17, 2008 at 11:55 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Jaime Casanova" <systemguards@gmail.com> writes:
>> But in my freshly 8.3.1 instalation on win xp, the default is
>> "fsync"... is a *bug* in the docs :)
>
> More like a bug in the code. Does it let you set the value to
> open_datasync?
>

yes it does...

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Guayaquil - Ecuador
Cel. (593) 087171157

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

Re: [GENERAL] writing a function without installing a language

Craig Ringer wrote:
> ${spencer} wrote:
>> is there a way to write a function without installing a specific
>> language? all i need to do is write a function that can take 3 text's
>> and put them into a list format (eg. "text1, text2 and text3" )

> Failing that, you might be able to use an SQL function (though I don't
> really see how you'd handle the special case for "and" without a
> subquery to obtain a total result count)

... if the input was a set of `text', not 3 individual `text' arguments.
Whoops. It's trivially done with plain SQL.

--
Craig Ringer

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

[pgsql-es-ayuda] Problemas con tipo Serial

Tengo en una tabla un ID de tipo SERIAL que al dia de hoy no me habia
dado problemas (tengo unas 93 inserciones ya realizadas).
Resulta que fui a hacer una inserción y me empezo a dar el error:

ERROR: duplicate key value violates unique constraint
"t_asignaturas_dictadas_pkey"

A alguien le ha pasado?

Saludos,

Juan
--
TIP 4: No hagas 'kill -9' a postmaster

Re: [pgsql-es-ayuda] backup con pg_dump

Si, funciona, por que lo hago con otros bases de datos, mas pequeños, que se guardan sin problemas..!!! , alguien me comento que podria ser el formato tar, que tiene una limitante, ahora voy a investigar sobre el uso del mismo..
gracias x responder..!!!

El día 16 de mayo de 2008 20:30, Juan Jose Lopez <juanjl.geo@yahoo.com> escribió:

Diego Ayala <netdiego81@gmail.com> wrote:

buenos tardes listeros, necesito de su ayuda para salir de una duda que tengo, tengo mi base datos PostgreSQL 8.2.3, corriendo sobre un linux RH 4 ES. XEON de 8GB de RAM. lo concreto es lo siguiente, tengo 5 bases de datos separados, de los cuales, son 2 los que contienen muchos datos.
el 1ra base tiene el tamaño de 3916MB y el 2do tiene 3620 MB, estos datos los saco utilizando la siguiente sentencia
select pg_size_pretty(pg_database_size('base_2'))
el tema es el siguiente mis particiones la tengo de la siguiente manera

S.ficheros          Tamaño Usado  Disp Uso% Montado en
/dev/mapper/VolGroup00-LogVol00
                      4,0G  1,7G  2,1G  45% /
/dev/sda3             190M   12M  169M   7% /boot
none                  4,0G     0  4,0G   0% /dev/shm
/dev/mapper/VolGroup00-LogVol05
                      4,0G   41M  3,7G   2% /home
/dev/mapper/VolGroup00-LogVol03
                      4,0G   41M  3,7G   2% /tmp
/dev/mapper/VolGroup00-LogVol02
                      7,9G  2,8G  4,7G  38% /usr
/dev/mapper/VolGroup00-LogVol04
                       32G   12G   18G  40% /var


tengo disponible 18GB en el /var, los backups los genero en el directorio /var/lib/pgsql/backups.

el script que utilizo para el backup es
BKPPATH=/var/lib/pgsql/backups
BKPNAME=$(/bin/date +%Y%m%d)-sipepmedio.tar
DIRBZIP2=/usr/bin

echo "Init pg_dump "$(/bin/date)
$DIRPG/pg_dump -F t -U $DBUSER $DBNAME > $BKPPATH/$BKPNAME
echo "End pg_dump "$(/bin/date)
echo "Init bzip2 "$(/bin/date)
$DIRBZIP2/bzip2 -9 $BKPPATH/$BKPNAME
echo "End bzip2 "$(/bin/date)

en una de las tablas se almacenas documentos en tipos de datos bytea, el tamaño de esa tabla actualmente es 1396 MB.

En el log me aparece el siguiente error

Init pg_dump Fri May 16 13:30:01 PYT 2008
pg_dump: [tar archiver] could not write to output file: No space left on device
End pg_dump Fri May 16 13:35:08 PYT 2008
Init bzip2 Fri May 16 13:35:08 PYT 2008
End bzip2 Fri May 16 13:35:13 PYT 2008


Me indica que no tengo espacio, pero, sin embargo, tengo 18GB espacio libre en el directorio /var el sistema de archivos que utilizo es el ext3.

Por favor si pueden ayudarme.

gracias.


--
Diego Ayala

Hola Diego,

Sería interesante saber si este script ya lo usaste con éxito anteriormente. Por otra parte, los volcados generados queda claro que por su formato texto y representación SQL ocuparán mucho más espacio que los correspondientes archivos de la base de datos, a los que representan (que están en formatos binarios, más compactos).

Saludos,
Juan J Lopez
Buenos Aires, Argentina

--
Diego Ayala

Re: [HACKERS] What in the world is happening on spoonbill?

Tom Lane wrote:
> Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
>> Tom Lane wrote:
>>> Huh. I wonder why it's only happening on that one machine.
>
>> But if i had to guess this more likely caused by the special malloc
>> flags used on spoonbill (FGJPZ) - per your recommendations in:
>
> Hah, yeah, that's it. The code was definitely indexing off the end
> of the width_wrap[] array. It's surprising that we didn't get any
> more-obvious failures, like bogus output formatting.
>
> Can you modify the buildfarm's description of that machine to mention
> the special malloc debug flags? It'd probably stop me from asking
> you this question again ;-)

hmm - would take somebody with SQL-level access to do this - the script
to update OS/compiler related data is only partially(ie not updating all
information) working...
But maybe it would be nice to have some sort of "notes about this
buildfarm member" text field that contains this information (or other
stuff like "this is a VM running on bar" or "this is really the same
hardware as animal bar just with configuration baz" ?

Stefan

--
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] What in the world is happening on spoonbill?

Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
> psql is coredumping:

BTW, this exposes a pretty nasty omission in pg_regress: it fails to
say anything about a nonzero exit code from a psql child process
that's running a test. Seems like wait_for_tests() ought to complain
about that. Any objections? Does anyone know how to get the child
process exit status on Windows?

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] What in the world is happening on spoonbill?

Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
> Tom Lane wrote:
>> Huh. I wonder why it's only happening on that one machine.

> But if i had to guess this more likely caused by the special malloc
> flags used on spoonbill (FGJPZ) - per your recommendations in:

Hah, yeah, that's it. The code was definitely indexing off the end
of the width_wrap[] array. It's surprising that we didn't get any
more-obvious failures, like bogus output formatting.

Can you modify the buildfarm's description of that machine to mention
the special malloc debug flags? It'd probably stop me from asking
you this question again ;-)

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] What in the world is happening on spoonbill?

Tom Lane wrote:
> Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
>> psql is coredumping:
>
> Huh. I wonder why it's only happening on that one machine.
> Is there anything particularly unusual about datatype sizes
> or alignment rules on that platform?

hmm actually - the windows buildfarm failures/issues andrew reported
might be the same issue from looking at his report and the failure after
killing psql ...

Stefan

--
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: Fix utterly-bogus code for computing row heights.

Log Message:
-----------
Fix utterly-bogus code for computing row heights. Per crashes on
spoonbill, though one wonders why it didn't misbehave everywhere.
In passing remove some unnecessary modulo calculations.

Modified Files:
--------------
pgsql/src/bin/psql:
print.c (r1.103 -> r1.104)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/print.c?r1=1.103&r2=1.104)

--
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] What in the world is happening on spoonbill?

Tom Lane wrote:
> Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
>> psql is coredumping:
>
> Huh. I wonder why it's only happening on that one machine.
> Is there anything particularly unusual about datatype sizes
> or alignment rules on that platform?

hmm well it is a 64bit Sparc box running OpenBSD which is a tad
"unusual" in itself.
But if i had to guess this more likely caused by the special malloc
flags used on spoonbill (FGJPZ) - per your recommendations in:

http://archives.postgresql.org/pgsql-hackers/2005-06/msg00828.php

docs at:

http://www.openbsd.org/cgi-bin/man.cgi?query=malloc.conf&apropos=0&sektion=0&manpath=OpenBSD+4.2&arch=sparc64&format=html

Stefan

--
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] What in the world is happening on spoonbill?

Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
> psql is coredumping:

Huh. I wonder why it's only happening on that one machine.
Is there anything particularly unusual about datatype sizes
or alignment rules on that platform?

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: Fix a subtle bug exposed by recent wal_sync_method

Log Message:
-----------
Fix a subtle bug exposed by recent wal_sync_method rearrangements.
Formerly, the default value of wal_sync_method was determined inside xlog.c,
but now it is determined inside guc.c. guc.c was reading xlogdefs.h
without having read <fcntl.h>, leading to wrong determination of
DEFAULT_SYNC_METHOD. Obviously xlogdefs.h needs to include <fcntl.h>
for itself to ensure stable results.

Modified Files:
--------------
pgsql/src/backend/access/transam:
xlog.c (r1.310 -> r1.311)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/transam/xlog.c?r1=1.310&r2=1.311)
pgsql/src/include/access:
xlogdefs.h (r1.21 -> r1.22)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/access/xlogdefs.h?r1=1.21&r2=1.22)

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

[pgsql-es-ayuda] Deadlocks en PostgreSQL

Buenas gente...

Estoy con tiempo este fin de semana y con ganas de leer sobre causas
de deadlocks o abrazos mortales en PostgreSQL, estuve buscando en la
web pero no encontre mucho...

Si alguien tiene algo para aportar o algun link que pasarme, lo agradeceré....

Saludos,

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

Re: [HACKERS] What in the world is happening on spoonbill?

Tom Lane wrote:
> Buildfarm member spoonbill's last four HEAD builds have all failed in
> the same utterly bizarre way. It looks like about half of the test
> results files got truncated at random places --- no errors, no nothing,
> the file just ends early. What's up with that?

psql is coredumping:

#0 0x0000000000112ea0 in print_aligned_text (cont=0xffffffffffff8a90,
fout=0x74c0c8) at print.c:664
664 if (width > 0 && width_wrap[i] &&
(gdb) bt
#0 0x0000000000112ea0 in print_aligned_text (cont=0xffffffffffff8a90,
fout=0x74c0c8) at print.c:664
#1 0x0000000000116e40 in printTable (cont=0xffffffffffff8a90,
fout=0x74c0c8, flog=0x0) at print.c:2248
#2 0x00000000001170e0 in printQuery (result=0x41a44800, opt=0x4,
fout=0x74c0c8, flog=0x0) at print.c:2365
#3 0x0000000000107dc0 in PrintQueryTuples (results=0x41a44800) at
common.c:605
#4 0x00000000001080b0 in PrintQueryResults (results=0x41a44800) at
common.c:710
#5 0x0000000000108508 in SendQuery (query=0x4f4cd600 "select * from
def_test;") at common.c:870
#6 0x000000000010c5f4 in MainLoop (source=0x74c030) at mainloop.c:242
#7 0x000000000010eb40 in main (argc=6, argv=0xffffffffffff91f8) at
startup.c:347

which points the figner towards the psql changes ...

Stefan

--
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] Configurando un usuario.

Para retirar el permiso de conectarse a una base de datos, usa REVOKE CONNECT sobre las bases de datos y usuarios que sean necesarios, pero también tendrías que retirar el mismo privilegio del rol PUBLIC, pues de otra forma el usuario lo seguiría heredando.

Esto último podría afectar a tus otros usuarios en esa base de datos, pero creo que sería un buen motivo para comenzar a organizar mejor los permisos, por ejemplo, creando un rol por base de datos y asignándole a éste el privilegio de conectarse, luego a los nuevos usuarios les harás parte de este rol sólo si quieres que accedan, pues por default no podrían conectarse (si retiras el privilegio connect sobre dicha base de datos al rol public).

Sobre el problema con GRANT, podrías detallar un poco más, como el mensaje de error que te aparezca, y los permisos almacenados en la tabla pg_database.

El día 17 de mayo de 2008 11:15, Pablo Braulio <brulics@gmail.com> escribió:

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

Hola a todos.

Tengo una cuestión sobre el modo de configurar los permisos de acceso de
un usuario, que necesito su ayuda.

Tengo que darle acceso a un cliente a mi servidor postgres, en el que
hay varias bases de datos. La cuestión es que sólo pueda acceder a una
base de datos determinada y no al resto.

Lo que me encuentro es que si creo el usuario en la consola (linux) con
createuser, puede acceder a todas las bases de datos.

He probado creando el usuario con:
 CREATE USER user NOCREATEDB nosuperuser;

Pero si hago:

 psql db_no_permitida

Puede entrar.

Y por otro lado le doy permisos para la base de datos que me interesa:

GRANT ALL ON DATABASE db_permitida to user with grant option;

Pero no la puede ver, pues esa bd la he creado con mi usuario (superuser).

He visto en la documentación de postgres 8.2 la sintaxis de GRANT y que
se puede dar permisos sobre las tablas, pero esto sería una locura pues
la base de datos tiene mas de 100 tablas.

¿Existe alguna manera de hacer esto?.


- --

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

iD8DBQFILwS1K7lGsMchFswRAsG2AJ9QzOrla+1sFgGma1YqWvb+ITyZfACggiDW
8Ryu37+lvwF7PzW7Gt/hv+U=
=ZSgU
-----END PGP SIGNATURE-----
--
TIP 9: visita nuestro canal de IRC #postgresql-es en irc.freenode.net

Re: [DOCS] wal_sync_method

"Jaime Casanova" <systemguards@gmail.com> writes:
> But in my freshly 8.3.1 instalation on win xp, the default is
> "fsync"... is a *bug* in the docs :)

More like a bug in the code. Does it let you set the value to
open_datasync?

regards, tom lane

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

[COMMITTERS] pgsql: Remove DEFAULT_SYNC_FLAGBIT ...

Log Message:
-----------
Remove DEFAULT_SYNC_FLAGBIT ... not used anymore.

Modified Files:
--------------
pgsql/src/include/access:
xlogdefs.h (r1.20 -> r1.21)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/access/xlogdefs.h?r1=1.20&r2=1.21)

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

[HACKERS] What in the world is happening on spoonbill?

Buildfarm member spoonbill's last four HEAD builds have all failed in
the same utterly bizarre way. It looks like about half of the test
results files got truncated at random places --- no errors, no nothing,
the file just ends early. What's up with that?

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: [BUGS] BUG #4177: Dump and restore from Slonified 8.1.11 causes a segfault

"Githogori Nyangara-Murage" <githogori@SiliconBazaar.com> writes:
> Either a pg_dumpall or pg_dump of a Slonified database on PostgreSQL 8.1.11
> causes a segfault if I try to restore it on PostgreSQL 8.3.1.

Please provide a stack trace, or even better a dump file with which
someone else can reproduce the crash.

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

Craig Ringer <craig@postnewspapers.com.au> writes:
> That function hits the database repeatedly. If the problem is in fact
> with a database query that it's generating you need to determine which
> one. You could step through the function with a PHP debugger or just
> insert log/printing statements in the function so you can see its progress.

Even easier, turn on query logging (log_statement = all), run the
function, and then look in the postmaster log to see what happened.

7.3 is a long time back, and I wouldn't be surprised if you are hitting
some compatibility issues in trying to make the jump to 8.3 in one step.
It's hard to tell what though ... I don't find that PHP code very
readable.

regards, tom lane

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

Re: [PATCHES] [HACKERS] TRUNCATE TABLE with IDENTITY

On Sat, 2008-05-17 at 12:04 -0400, Tom Lane wrote:

> So what I think we should do is leave the patch there, revise the
> warning per Neil's complaint, and add a TODO item to reimplement
> RESTART IDENTITY transactionally.

Sounds good.

--
Simon Riggs

www.2ndQuadrant.com

PostgreSQL Training, Services and Support

--
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] Configurando un usuario.

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

Hola a todos.

Tengo una cuestión sobre el modo de configurar los permisos de acceso de
un usuario, que necesito su ayuda.

Tengo que darle acceso a un cliente a mi servidor postgres, en el que
hay varias bases de datos. La cuestión es que sólo pueda acceder a una
base de datos determinada y no al resto.

Lo que me encuentro es que si creo el usuario en la consola (linux) con
createuser, puede acceder a todas las bases de datos.

He probado creando el usuario con:
CREATE USER user NOCREATEDB nosuperuser;

Pero si hago:

psql db_no_permitida

Puede entrar.

Y por otro lado le doy permisos para la base de datos que me interesa:

GRANT ALL ON DATABASE db_permitida to user with grant option;

Pero no la puede ver, pues esa bd la he creado con mi usuario (superuser).

He visto en la documentación de postgres 8.2 la sintaxis de GRANT y que
se puede dar permisos sobre las tablas, pero esto sería una locura pues
la base de datos tiene mas de 100 tablas.

¿Existe alguna manera de hacer esto?.

- --

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

iD8DBQFILwS1K7lGsMchFswRAsG2AJ9QzOrla+1sFgGma1YqWvb+ITyZfACggiDW
8Ryu37+lvwF7PzW7Gt/hv+U=
=ZSgU
-----END PGP SIGNATURE-----
--
TIP 9: visita nuestro canal de IRC #postgresql-es en irc.freenode.net

Re: [PATCHES] [HACKERS] TRUNCATE TABLE with IDENTITY

Simon Riggs <simon@2ndquadrant.com> writes:
> On Fri, 2008-05-16 at 21:50 -0400, Tom Lane wrote:
>> Actually, I agree. Shall we just revert that feature?

> Perhaps, but we should also take into account that TRUNCATE is not and
> never will be MVCC compliant, so its not something you'd expect to run
> except as a maintenance action.

Good point. I had a couple of further thoughts this morning:

1. The case Neil is worried about is something like

BEGIN;
TRUNCATE TABLE foo RESTART IDENTITY;
COPY foo FROM ...;
COMMIT;

If the COPY fails partway through, the old table contents are restored,
but the sequences are not. However removing RESTART IDENTITY will not
remove the hazard, because there is no difference between this and

BEGIN;
TRUNCATE TABLE foo;
SELECT setval('foo_id', 1);
COPY foo FROM ...;
COMMIT;

other than the latter adding a little extra chance for pilot error in
resetting the wrong sequence. So if we revert the patch we haven't
accomplished much except to take away an opportunity to point out the
risk. I vote for leaving the patch in and rewriting the <warning>
to point out this risk.

2. I had first dismissed Neil's idea of transactional sequence updates
as impossible, but on second look it could be done. Suppose RESTART
IDENTITY does this for each sequence;

* obtain AccessExclusiveLock;
* assign a new relfilenode;
* insert a sequence row with all parameters copied except
last_value copies start_value;
* hold AccessExclusiveLock till commit.

IOW just like truncate-and-reload, but for a sequence. Within the
current backend, subsequent operations see the new sequence values.
If the transaction rolls back, the old sequence relfilenode is still
there and untouched.

It's slightly annoying to need to lock out other backends' nextval
operations, but for the use-case of TRUNCATE this doesn't seem
like it's really much of a problem.

I'm not sure if it'd be worth exposing this behavior as a separate
user-visible command (CREATE OR REPLACE SEQUENCE, maybe?), but it seems
worth doing to make TRUNCATE-and-reload less of a foot gun.

So what I think we should do is leave the patch there, revise the
warning per Neil's complaint, and add a TODO item to reimplement RESTART
IDENTITY transactionally.

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] INSTALR EN OTRA PARTICION

Luis Fernando Curiel Cabrera escribió:
> Antes de pedir ayuda, muchas gracias a todos por la yuda que me
> proporcionaron antes. EN verdad muchas gracias, gane y ahora usamos
> postgres en la empresa.
>
> Ahora sí, tengoq eu instalar postgres en un servidor con windows XP
> Profesional. Quiero instalarlo de tal forma que toda la carpeta dinde se
> guardan fisicamente las bases de datos ponerlo en una particion
> diferente a C:
>
> Me podrian ayudar con algun documento en linea o si alguien ya lo ha
> hecho en decirme como es.
>

Para mi lo mas sencillo es:

* Instalar normalmente
* detener el servicio
* mover la carpeta data a la nueva ubicación
* modificar en el registro el comando que se utiliza para iniciar el servicio cambiandole la ruta de
'data'
* iniciar el servicio.

Si vas a utilizar XP como servidor, me imagino que ya conoces la limitación de conexiones impuesta
por microsoft a partir del sp2.

Suerte.

--
*****************************************
Oswaldo Hernández
oswaldo (@) soft-com (.) es
*****************************************
PD:
Antes de imprimir este mensaje, asegúrese de que es necesario.
El medio ambiente está en nuestra mano.
--
TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda

Re: [HACKERS] Adding variables for segment_size, wal_segment_size and block sizes

Bernd Helmle wrote:

> segment_size: Reports heap segment size
> wal_segment_size: Reports wal segment size
> block_size: Available yet
> wal_block_size: wal block size
>
+1. We already have block_size in GUC.

--
Euler Taveira de Oliveira

http://www.timbira.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: [pgsql-es-ayuda] Problema con Funcion de insercion en multiples tablas

Lo resolvi con la siguiente funcion, sin cursores:

CREATE OR REPLACE FUNCTION AGREGAR_DISPOSICION( disposicion TEXT,
anio_menor INT,
anio_mayor INT,
name TEXT,
archivo BYTEA,
tipe TEXT,
size FLOAT,
asignatura INT,
carrera INT,
tipo TEXT) RETURNS VOID AS
$$
DECLARE
existe TEXT;
plan RECORD;
BEGIN
IF anio_menor > anio_mayor THEN
RAISE EXCEPTION 'ERROR: El año de inicio debe ser mayor que el de fin!';
ELSE
SELECT nro_disposicion INTO existe FROM T_PROGRAMAS;
IF existe IS NULL THEN
INSERT INTO T_PROGRAMAS VALUES(nro_disposicion, name, archivo,
tipe, size, current_date, tipo);
END IF;
FOR plan IN SELECT codigo_plan
FROM T_ASIGNATURAS_X_PLAN
WHERE codigo_asignatura = asignatura AND codigo_carrera = carrera
ORDER BY codigo_plan ASC
LOOP
INSERT INTO T_PROGRAMAS_X_ASIGNATURA VALUES (disposicion,
plan.codigo_plan, carrera, asignatura, anio_menor, anio_mayor);
END LOOP;

END IF;
END;
$$ language 'plpgsql';

Todavia no esta del todo probada pero parece funcar! :P
Cualquier cosa comento!

Saludos,

Juan

2008/5/16 Juan Manuel Fernandez <jmfernandez@unlu.edu.ar>:
> Buenas Noches Lista!!!
> Tengo el siguiente problema, tengo una funcion (en realidad deseo
> tenerla) que lo que debe hacer es:
>
> * Insertar parte de los datos que son pasados como parametro en una Tabla.
> * En base a parte de estos datos, seleccionar datos de otra tabla para
> insertarlos junto con otros pasados como parametro en una tercera
> tabla...
>
> La idea de la funcion es la siguiente:
>
> CREATE OR REPLACE FUNCTION AGREGAR_DISPOSICION( disposicion TEXT,
> anio_menor INT,
> anio_mayor INT,
> name TEXT,
> archivo BYTEA,
> tipe TEXT,
> size FLOAT,
> asignatura INT,
> carrera INT,
> tipo TEXT) RETURNS VOID AS
> $$
> DECLARE
> existe TEXT;
> planes CURSOR FOR SELECT codigo_plan WHERE codigo_asignatura =
> asignatura AND codigo_carrera = carrera ORDER BY codigo_plan ASC;
>
> BEGIN
> IF anio_menor > anio_mayor THEN
> RAISE EXCEPTION 'ERROR: El año de inicio debe ser mayor que el de fin!';
> ELSE
> SELECT nro_disposicion INTO existe FROM T_PROGRAMAS;
> IF existe IS NULL THEN
> INSERT INTO T_PROGRAMAS VALUES(nro_disposicion, name, archivo,
> tipe, size, current_date, tipo);
> END IF;
>
> SELECT codigo_plan INTO planes FROM
> T_ASIGNATURAS_X_PLAN WHERE codigo_carrera = carrera AND
> codigo_asignatura = asignatura;
>
> // Aca esta el dilema! Como hago para que el
> programa se inserte en todos los planes coincidentes???
>
> INSERT INTO T_PROGRAMAS_X_ASIGNATURA VALUES (disposicion, :planes,
> carrera, asignatura, anio_menor, anio_mayor);
>
> END IF;
> END;
> $$ language 'plpgsql';
>
> Yo entiendo que en la variable planes va a quedar solo el ultimo plan
> coincidente, el tema es que deseo insertarlo en todos los que lo
> sean...
>
> Como puedo hacerlo? Creo que una alternativa seria un cursor, pero
> jamas use uno....
>
> Si me ayudan me sacarían de un enorme bache, un problema con el que
> lidie todo el día...
>
>
>
> Muchas gracias,
>
>
> Juan
>
--
TIP 5: ¿Has leído nuestro extenso FAQ?

http://www.postgresql.org/docs/faqs.FAQ.html

[pgsql-es-ayuda] INSTALR EN OTRA PARTICION

Antes de pedir ayuda, muchas gracias a todos por la yuda que me proporcionaron antes. EN verdad muchas gracias, gane y ahora usamos postgres en la empresa.

Ahora sí, tengoq eu instalar postgres en un servidor con windows XP Profesional. Quiero instalarlo de tal forma que toda la carpeta dinde se guardan fisicamente las bases de datos ponerlo en una particion diferente a C:

Me podrian ayudar con algun documento en linea o si alguien ya lo ha hecho en decirme como es.

De antemano muchas

--
Luis Fernando Curiel Cabrera
- Professional ABACO DE BOLITAS Developer.
- Certified ABACO DE BOLITAS Programmer.

Re: [pgus-board] Fw: Bylaws

Looks good.

On Fri, May 16, 2008 at 11:09 AM, Joshua D. Drake <jd@commandprompt.com> wrote:
> This is what the attorney came back with for the Section 3.2 problem.
>
> Begin forwarded message:
>
> Date: Fri, 16 May 2008 09:30:19 -0700
> From: "Hitchcock, Greg" <greghitchcock@dwt.com>
> To: "Joshua D. Drake" <jd@commandprompt.com>
> Subject: Bylaws
>
>
> Hi Joshua:
>
> Here is the language to stagger the terms of directors within a year,
> i.e., having new terms start in October for 4 directors and in April for
> 3 directors (after the initial directors serve their three year terms).
>
> ARTICLE II. Section 4. Annual Meetings.
> Members shall hold two meetings during each calendar year for the
> purpose of electing the Board of Directors of the Corporation and
> transacting such other business as may be properly brought before the
> meeting. These meetings are referred to as the annual meeting and the
> semi-annual meeting. Additional meetings of the members may be held as
> necessary. The Board of Directors shall designate such date, time and
> place as it may choose for member meetings; provided, however, the
> annual meeting and the semi-annual meeting of the members shall be held
> approximately six months apart.
>
> ARTICLE III. Section 3. Term.
> 1. The term of each member of the Board shall be one year, except
> for the initial term of the initial Directors. Up to four new Directors
> will be elected at the first annual meeting, and the term of such
> positions will expire each year at the annual meeting of the members.
> 2. Notwithstanding the standard term in Section 3.1
> above, the initial term for each of the three initial appointed
> Directors is three years, ending at the semi-annual member meeting in
> 2011. The terms for such Director positions shall thereafter be one
> year and shall expire at the semi-annual meeting of the members.
>
> 3. If additional Director positions are added, such
> Directors will be allocated to those who terms expire at the annual
> meeting and those whose terms expire at the semi-annual meeting for the
> purpose of maintaining approximately equal groups of Directors whose
> terms expire at the annual meeting and the semi-annual meeting of the
> members. There shall be no limit on the number of terms which a
> Director may serve. A Director shall hold office for the time for which
> he or she is elected or until his or her successor is elected and
> qualified or until his or her resignation or removal.
>
> Section 4. Election Procedure.
> At each annual meeting of the Board, the successors to the Directors
> whose terms expire at the annual meeting shall be elected. At the
> semi-annual meeting of the Board, the successors to the Directors whose
> terms expire at the semi-annual meeting shall be elected.
>
> If you believe that having two meetings (and they can be held by proxy
> vote) will be too cumbersome. We could look at having members elect all
> directors at the annual meeting, but having the terms of 1/2 start six
> months later. Or the four elected board members could appoint the other
> three at the six month period. I don't either of those works as well as
> the above. Let me know what you think.
>
> Greg Hitchcock | Davis Wright Tremaine LLP
> 1300 SW Fifth Avenue, Suite 2300 | Portland, OR 97201
> Tel: (503) 778-5327 | Fax: (503) 276-5813
> Email: greghitchcock@dwt.com | Website: www.dwt.com
> <http://www.dwt.com/>
>
> Anchorage | Bellevue | Los Angeles | New York | Portland | San Francisco
> | Seattle | Shanghai | Washington, D.C.
>
>
> Circular 230 - To comply with IRS rules, we must inform you that this
> message (including any attachment) if it contains advice relating to
> federal taxes, was not intended or written to be used, and it cannot be
> used, for the purpose of avoiding penalties that may be imposed under
> federal tax law. Under these rules, a taxpayer may rely on professional
> advice to avoid federal tax penalties only if that advice is reflected
> in a comprehensive tax opinion that conforms to stringent requirements
> under federal law.
>
>
>
> --
> 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
>
>
>
> Hi Joshua:
>
> Here is the language to stagger the terms of directors within a year, i.e., having new terms start in October for 4 directors and in April for 3 directors (after the initial directors serve their three year terms).
>
> ARTICLE II. Section 4. Annual Meetings.
>
> Members shall hold two meetings during each calendar year for the purpose of electing the Board of Directors of the Corporation and transacting such other business as may be properly brought before the meeting. These meetings are referred to as the annual meeting and the semi-annual meeting. Additional meetings of the members may be held as necessary. The Board of Directors shall designate such date, time and place as it may choose for member meetings; provided, however, the annual meeting and the semi-annual meeting of the members shall be held approximately six months apart.
>
> ARTICLE III. Section 3. Term.
>
> 1. The term of each member of the Board shall be one year, except for the initial term of the initial Directors. Up to four new Directors will be elected at the first annual meeting, and the term of such positions will expire each year at the annual meeting of the members.
>
> 2. Notwithstanding the standard term in Section 3.1 above, the initial term for each of the three initial appointed Directors is three years, ending at the semi-annual member meeting in 2011. The terms for such Director positions shall thereafter be one year and shall expire at the semi-annual meeting of the members.
>
> 3. If additional Director positions are added, such Directors will be allocated to those who terms expire at the annual meeting and those whose terms expire at the semi-annual meeting for the purpose of maintaining approximately equal groups of Directors whose terms expire at the annual meeting and the semi-annual meeting of the members. There shall be no limit on the number of terms which a Director may serve. A Director shall hold office for the time for which he or she is elected or until his or her successor is elected and qualified or until his or her resignation or removal.
>
> Section 4. Election Procedure.
>
> At each annual meeting of the Board, the successors to the Directors whose terms expire at the annual meeting shall be elected. At the semi-annual meeting of the Board, the successors to the Directors whose terms expire at the semi-annual meeting shall be elected.
>
> If you believe that having two meetings (and they can be held by proxy vote) will be too cumbersome. We could look at having members elect all directors at the annual meeting, but having the terms of 1/2 start six months later. Or the four elected board members could appoint the other three at the six month period. I don't either of those works as well as the above. Let me know what you think.
>
> Greg Hitchcock | Davis Wright Tremaine LLP
> 1300 SW Fifth Avenue, Suite 2300 | Portland, OR 97201
> Tel: (503) 778-5327 | Fax: (503) 276-5813
> Email: greghitchcock@dwt.com | Website: www.dwt.com
>
> Anchorage | Bellevue | Los Angeles | New York | Portland | San Francisco | Seattle | Shanghai | Washington, D.C.
>
> Circular 230 - To comply with IRS rules, we must inform you that this message (including any attachment) if it contains advice relating to federal taxes, was not intended or written to be used, and it cannot be used, for the purpose of avoiding penalties that may be imposed under federal tax law. Under these rules, a taxpayer may rely on professional advice to avoid federal tax penalties only if that advice is reflected in a comprehensive tax opinion that conforms to stringent requirements under federal law.
>

--
Selena Deckelmann
United States PostgreSQL Association - http://www.postgresql.us
PDXPUG - http://pugs.postgresql.org/pdx
Me - http://www.chesnok.com/daily

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

Re: [pgus-board] Fw: Bylaws

Michael Alan Brewer wrote:
> I just quick-scanned it; it looks fine so far. I'm fine with this language.
>
> ---Michael Brewer
> mbrewer@gmail.com
>

Selena?

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

[HACKERS] windows builds hanging on regression checks

Something committed in about the last 24 hours or so has caused my
Windows buildfarm members to hang completely while running the
regression tests. It's happened for both MinGW and MSVC builds.

To get the buildfarm run to complete in some fashion, I had to kill 2
psql processes, and then 2 dwwin processes. The result was this:

http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=dawn_bat&dt=2008-05-17%2012:28:51

The most likely candidate looks to me like this one :"Implement error
checking for pthreads calls in thread-safe mode." but that's just a guess.

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

Re: [pgsql-www] please add Vidoop to /about/users

On Fri, May 16, 2008 at 11:56 AM, Robert Treat
<xzilla@users.sourceforge.net> wrote:

>> Hmm. I would like us to highlight web-focused companies a bit more,
>> so that when a web developer looks at that page they think, "People
>> like me are using PostgreSQL".
>>
>> What about "Web Service" as a category? Flightstats would then fall
>> into that category.
>>
>
> works for me

Wow, that was easy ;)

So -- I revise my request:

Please create a category called "Web Service" and put:

Vidoop
Flightstats

in there.

thanks!
-selena

--
Selena Deckelmann
United States PostgreSQL Association - http://www.postgresql.us
PDXPUG - http://pugs.postgresql.org/pdx
Me - http://www.chesnok.com/daily

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

Re: [pgadmin-support] Adding users and groups/roles without SQL?

On 17/05/2008 14:40, Jaroslav Záruba wrote:

> find the proper command for roles quickly... But I am quite confused by
> the fact that the "Groups" and "Users" items (in the server-subtree)
> don't provide "New group" or "New user" option in their context menus.

It does for me....right-click on "Login Roles" and you get a menu item
"New Login Role..." as expected. I'm using 1.8.2.

Ray.

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

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

[GENERAL] tsearch2 on-demand dictionary loading & using functions in tsearch2

Hello,

I'd like to ask about two separate things regarding tsearch2 in
PostgreSQL 8.3.

Firstly, I've noticed that dictionary is loaded on-demand specifically
for each session, and apparently this behavior cannot be changed in any way.

If that's the case, would it be reasonable to ask for an option to allow
loading during Postgres startup, rather than during the first usage of
the dictionary in each distinctive session?

I am currently working with ispell dictionaries for multiple languages,
each being approx. 3MB large. With a lookup within a single dictionary,
the first ts_lexize takes over one second, which from user's point of
view is quite a long time.

I see several benefits of the suggested approach:
* For those who do not use persistent connections of any sort, using
ispell dictionaries right now inflicts a severe blow in application
responsiveness. Loading the dictionaries during database startup instead
would speed things up significantly.
* Considering the database is loaded separately for each session, does
this also imply that each running backend has a separate dictionary
stored in memory? If that is the case, using eg. 2 dictionaries, each
3MB large, on a database server with 20 backends running would eat up as
much as 120MB of RAM, while if the server loaded the dictionaries
beforehand, the OS could (possibly) keep the dictionaries shared in memory.

As for downsides, I only really see two:
* Tracking updates of dictionaries - but it's reasonable to believe
that new connections get open more often than the dictionary gets
updated. Also, this might be easily solved by stat()-ing the dictionary
file before starting up session, and only have the server reload it if
there's a notified change.
* Possibly complicated to implement?

As for my second question, is it possible to use functions in tsearch2?
For example, writing my own stemmer in PL/pgSQL or in C as a postgres
function.

Thanks in advance for reply,
Steve

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

[pgadmin-support] Adding users and groups/roles without SQL?

Hello

Please how do you create users and groups/roles w/o SQL?

I know how to create a user with query-command, also I would probably find the proper command for roles quickly... But I am quite confused by the fact that the "Groups" and "Users" items (in the server-subtree) don't provide "New group" or "New user" option in their context menus. Is it possible to create these kind of objects without writing a query?

I have pgAdmin 1.8.2 and I am connected to the server as a superuser.
Could this be dependant on what version of Postgres is on the server?

Best regards
  Jaroslav Z.

(I guess this is rather silly question but I wasn't able to find the answer in the archive; mostly I find threads related to sql-commands like "CREATE ROLE" etc.)

[BUGS] BUG #4179: pg_standby reports "file size greater than expected"

The following bug has been logged online:

Bug reference: 4179
Logged by: Reinhard Zitzmann
Email address: rz2008@insode.de
PostgreSQL version: 8.3.1
Operating system: Centos 5
Description: pg_standby reports "file size greater than expected"
Details:

When copying a WAL file with "cp --sparse=always ..." to a remote NFS
directory, the remote file becomes 16777217 bytes long for a short time. Its
size is finally reduced to the expected size of 16777216 bytes. pg_standby
aborts with the error message: "file size greater than expected" when it
sees the file while it is being copied.

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

Re: [PERFORM] I/O on select count(*)

Tom Lane wrote:
> One additional point: this means that one transaction in every 32K
> writing transactions *does* have to do extra work when it assigns itself
> an XID, namely create and zero out the next page of pg_clog. And that
> doesn't just slow down the transaction in question, but the next few
> guys that would like an XID but arrive on the scene while the
> zeroing-out is still in progress.
>
> This probably contributes to the behavior that Simon and Josh regularly
> complain about, that our transaction execution time is subject to
> unpredictable spikes. I'm not sure how to get rid of it though.

A thread maintaining a pool of assigned and cleared pg_clog pages, ahead
of the immediate need? Possibly another job for an existing daemon
thread.

- Jeremy

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

Re: [pgsql-de-allgemein] WebApplication und Betriebssystem Performance Fragen.

--On Samstag, Mai 17, 2008 13:20:26 +0200 rudi@je-more.de wrote:

> Slony ist gefährlich, weil man mit dem Master doch wieder einen Single
> point of Failure hat.

Slony-I war nie als integrierte Hochverfügbarkeitslösung gedacht.

Slony-I kann als Bestandteil einer HA-Lösung dienen, allerdings benötigt
man einen Überwachungsdienst ala Heartbeat (siehe FAILOVER-Kommando). Aber
es besteht bei Slony-I die Gefahr bereits erfolgreiche Transaktionen zu
verlieren (aufgrund der asynchronen Technik), weshalb man eher dazu
übergeht den Master anderweitig abzusichern. Kommt halt auch ein bisschen
auf die Logik der Daten an, die da reinwandern. Wie gesagt, Slony-I ist ein
Bauteil, aber keine hochintegrierte Lösung.

--
Thanks

Bernd

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

Re: [PATCHES] libpq object hooks (libpq events)

Here is an updated patch for what was called object hooks. This is now
called libpq events. If someone has a better name or hates ours, let us
know.

I am continuing to use the object hooks thread to avoid confusing anyone.

Terminology:
I got rid of calling it object events because it is possible to add
other non-object-related events in the future; maybe a query event.
This system can be used for any type of event, I think it is pretty generic.

event proc - the callback procedure/function implemented outside of
libpq ... PGEventProc. The address of the event proc is used as a
lookup key for getting a conn/result's event data.

event data - the state data managed by the event proc but tracked by
libpq. This allows the event proc implementor to basically add a
dynamic struct member to a conn or result. This is an instance based
value, unlike the "arg pointer".

arg pointer - this is the passthrough/user pointer. I called it 'arg'
as other libpq callbacks used this term for this type of value. This
value can be retrieved via PQeventData, PQresultEventData ... its an
optional double pointer argument.

event state - an internal structure, PGEventState, which contains the
event data, event proc and the 'arg' pointer. Internally, PGconn and
PGresult contain arrays of event states.

event id - PGEventId enum values, PGEVT_xxx. This tells the event proc
which event has occurred.

event info - These are the structures for event ids, like
PGEVT_RESULTDESTROY has a corresponding PGEventResultDestroy structure.
The PGEventProc function's 2nd argument is "void *info". The first
argument is an event id which tells the proc implementor how to cast the
void *. This replaced the initial va_arg idea.

--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/

Re: [pgsql-es-ayuda] cache

Neil Peter Braggio escribió:
> Dependerá de que OS estes utilizando.
>
> En _UNIX like systems_ como Linux por ejemplo, puedes utilizar la
> utilidad hdparam

No si los discos son SCSI. ;-)

En ese caso tenes que usar el sdparm.
--
TIP 3: Si encontraste la respuesta a tu problema, publícala, otros te lo agradecerán

Re: [pgsql-es-ayuda] Se cayo mi servidor de BD

Rodriguez Fernando escribió:
> En caso de que no funcione, podes installar postgres, levantar el
> unltimo pgdump y aplicarles los logs de la base anterior.

Yo tenia entendido que esto no era posible (aplicar xlog sobre un
rescate de pg_dump).
--
TIP 8: explain analyze es tu amigo

Re: [pgsql-es-ayuda] Se cayo mi servidor de BD

MIGUEL CANCHAS escribió:
> Maestros estoy metido en un problemon, el servidor donde esta alojado mi BD
> se cayó.

Al piso? ;-)

> Cuando levantas el servidor sale :Error Failure disk, podriamos intentar
> recuperar los archivos, pero no creo que levante el Servidor solo el SO,
> se podria levantar la BD solo copiando los archivos de donde estaba a otro
> Disco ?

Si no se dañaron los archivos dentro de $PGDATA, y si lo copias a un PG
identico (misma version, exacta, sobre misma arquetectura, etc.),
deberia salir andando de una.

--
TIP 7: no olvides aumentar la configuraci�n del "free space map"

Re: [COMMITTERS] pgsql: Implement error checking for pthreads calls in thread-safe mode.

"Magnus Hagander" <mha@postgresql.org> writes:

> Log Message:
> -----------
> Implement error checking for pthreads calls in thread-safe mode. They really
> should always succeed, but in the likely event of a failure we would
> previously fall through *without locking* - the new code will exit(1).
>
> Printing the error message on stderr will not work for all applications, but
> it's better than nothing at all - and our API doesn't provide a way to return
> the error to the caller.

If you want to print an error I think you have to use write(2) here instead of
fprintf. if pthread is cocked up then fprintf is going to have trouble locking
the buffer.

--
Gregory Stark
EnterpriseDB

http://www.enterprisedb.com

Ask me about EnterpriseDB's On-Demand Production Tuning

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