Thursday, July 3, 2008

[COMMITTERS] pllolcode - pllolcode: Improve string handling in lex scanner by

Log Message:
-----------
Improve string handling in lex scanner by liberally following plpgsql's example
Also fix bug in returning boolean values

Modified Files:
--------------
pllolcode:
pllolcode.c (r1.22 -> r1.23)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pllolcode/pllolcode/pllolcode.c.diff?r1=1.22&r2=1.23)
scan.l (r1.25 -> r1.26)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pllolcode/pllolcode/scan.l.diff?r1=1.25&r2=1.26)
testFuncs.sql (r1.4 -> r1.5)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pllolcode/pllolcode/testFuncs.sql.diff?r1=1.4&r2=1.5)

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

Posted by at No comments:

Re: [HACKERS] Git Repository for WITH RECURSIVE and others

I just had this same problem.

Perhaps the wiki and http://git.postgresql.org/static/serviceinfo.html
should also be updated with the working (i.e. http) URL?

...Robert

On Thu, Jul 3, 2008 at 12:56 AM, Yoshiyuki Asaba <y-asaba@sraoss.co.jp> wrote:
> Hi,
>
> From: Abhijit Menon-Sen <ams@oryx.com>
> Subject: Re: [HACKERS] Git Repository for WITH RECURSIVE and others
> Date: Thu, 3 Jul 2008 09:18:17 +0530
>
>> At 2008-07-03 11:16:49 +0900, y-asaba@sraoss.co.jp wrote:
>> >
>> > # WITH RECURSIVE repository
>> > % git-clone git://git.postgresql.org/git/~davidfetter/postgresql/.git
>> > Initialized empty Git repository in /home/y-asaba/x/postgresql/.git/
>> > fatal: The remote end hung up unexpectedly
>>
>> Run git-clone http://git.postgresql.org/git/~davidfetter/postgresql/.git
>> instead. "git://..." apparently doesn't work on that repository (I don't
>> know why not).
>
> Thanks for the advice. I could get the repository via HTTP.
>
> Regards,
> --
> Yoshiyuki Asaba
> y-asaba@sraoss.co.jp
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

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

[ADMIN] slow delete...

I have a table with 29K rows total and I need to delete about 80K out of it.

I have a b-tree index on column cola (varchar(255) ) for my where clause to use.

my "select count(*) from test where cola = 'abc' runs very fast,
 
but my actual "delete from test where cola = 'abc';" takes forever, never can finish and I haven't figured why....

In my explain output, what is that "Bitmap Heap Scan on table"? is it a table scan? is my index being used?

How does delete work? to delete 80K rows that meet my condition, does Postgres find them all and delete them all together or one at a time?


by the way, there is a foreign key on another table that references the primary key col0 on table test.

Could some one help me out here?

Thanks a lot,
Jessica


testdb=# select count(*) from test;
 count 
--------
 295793  --total 295,793 rows
(1 row)

Time: 155.079 ms

testdb=# select count(*) from test where cola = 'abc';
 count
-------
 80998  - need to delete 80,988 rows
(1 row)



testdb=# explain delete from test where cola = 'abc';
                                             QUERY PLAN                                            
----------------------------------------------------------------------------------------------------
 Bitmap Heap Scan on test  (cost=2110.49..10491.57 rows=79766 width=6)
   Recheck Cond: ((cola)::text = 'abc'::text)
   ->  Bitmap Index Scan on test_cola_idx  (cost=0.00..2090.55 rows=79766 width=0)
         Index Cond: ((cola)::text = 'abc'::text)
(4 rows)


Posted by at No comments:

[PERFORM] slow delete

I have a table with 29K rows total and I need to delete about 80K out of it.

I have a b-tree index on column cola (varchar(255) ) for my where clause to use.

my "select count(*) from test where cola = 'abc' runs very fast,
 
but my actual "delete from test where cola = 'abc';" takes forever, never can finish and I haven't figured why....

In my explain output, what is that "Bitmap Heap Scan on table"? is it a table scan? is my index being used?

How does delete work? to delete 80K rows that meet my condition, does Postgres find them all and delete them all together or one at a time?


by the way, there is a foreign key on another table that references the primary key col0 on table test.

Could some one help me out here?

Thanks a lot,
Jessica


testdb=# select count(*) from test;
 count 
--------
 295793  --total 295,793 rows
(1 row)

Time: 155.079 ms

testdb=# select count(*) from test where cola = 'abc';
 count
-------
 80998  - need to delete 80,988 rows
(1 row)



testdb=# explain delete from test where cola = 'abc';
                                             QUERY PLAN                                            
----------------------------------------------------------------------------------------------------
 Bitmap Heap Scan on test  (cost=2110.49..10491.57 rows=79766 width=6)
   Recheck Cond: ((cola)::text = 'abc'::text)
   ->  Bitmap Index Scan on test_cola_idx  (cost=0.00..2090.55 rows=79766 width=0)
         Index Cond: ((cola)::text = 'abc'::text)
(4 rows)

Posted by at No comments:

Re: [ADMIN] Recourse Usage

On Thu, Jul 3, 2008 at 5:28 PM, Steve Kecskes <steve@outtalimits.com.au> wrote:
>
> G'day,
>
> I have been tasked to tune our company's Postgres database. From the
> research I have done I feel the recourse consumption parameters are set far
> to low. I have come up with the following modifications to the
> configuration and wanted to run this by the mailing list for any
> suggestions. The database is on a semi dedicated box, shared only with
> memcached which has been allocated 512MB.
>
> -Dual Xeon 2.33GHz
> -4GB RAM
> -Twin SAS drives in RAID 1
>
> Shared Buffers
> Currently: 8192 pages @ 8 KB each // 64MB
> To be set to: (256MB - 32768 pages @ 8 KB each)

That's still pretty small. I'd look at setting it to 1G on a machine
with that much memory.

> Work Mem
> Currently: 1024kb
> To be set to: 1536kb

This setting is very dependent on how man connections you'll support.
If only a few users will ever connect, then you can easily set it to
16 to 64 Megs and be ok. If you'll have dozens to hundreds of users
keep in mind that work_mem limits the amount of memory each sort type
function can use in each query for each user so it can add up fast.
Generally most systems can handle 8M or so for work_mem fine.

>
> Effective Cache Size
> Currently: 50000 pages // 390MB
> To be set to: 128000 pages // 1000MB

Probably also too low. That machine is quite likely to have 2+g of
kernel cache and buffer. But this is a course tuning knob so it's not
a huge deal.

> Random Page Cost
> Currently: 4.0
> To be set to: 3.0
>
> Wal Buffers
> Currently: 8 @ 8kb each
> To be set to: 32 @ 8kb each

Both of these are fine.

I assume you're running at least 8.0 or above here. I would highly
recommend upgrading to 8.3 if you're on 8.1 or older due to the fact
that 8.3 is so much faster than the older versions.

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

Posted by at No comments:

Re: [GENERAL] pg_dump - lost synchronization with server: got message type "d", length 6036499

Tom Lane wrote:
> Klint Gore <kgore4@une.edu.au> writes:
> > Tom Lane wrote:
> >> Would you be willing to send me a "pg_dump -s" (ie, just schema no
> >> data) dump of this DB? Off-list of course.
> >>
> > attached. created with pg_dump 8.3.3 win32 to the 8.3.1 win32 server.
>
> Thanks. When I reload this here and try to pg_dump it, I see no evidence
> of any problem --- pg_dump completes pretty quickly and seems to eat
> no more than a megabyte or so. I'm not sure what to make of that.
> Could there be a Windows-specific memory problem in pg_dump?
>
Any more thoughts on this?

The file being produced when dumping the table in question is about 1
gig when it crashes. In the last check-in for fe-protocol3.c, there's
notes about 1 gig strings so I'm wondering if my data when received by
pg_dump (or output by the 8.3.1 server) goes over? 270m of bytea
converted to \xxx octal strings would make something > 1 gig. But the
270m is spread over 400 rows with nothing bigger than 3m.

If there's no interest in researching this any further, then I'll stop
the server and take a file system copy of the data directory and upgrade
it to 8.3.3 and pray the problem goes away.

klint.

--
Klint Gore
Database Manager
Sheep CRC
A.G.B.U.
University of New England
Armidale NSW 2350

Ph: 02 6773 3789
Fax: 02 6773 3266
EMail: kgore4@une.edu.au


--
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: [pgsql-es-ayuda] Ayuda con postgresql.conf y ODBC

Mauricio

preguntonta, chequeando dudas, el netstat lo hiciste en el postgres?
intuyo que la maquina con crystal es la de windows .
El port 22 es normalmente el port del ssh usas el putty?
tendras un tunel en el ssh? si ese fuera el caso en el windows tendrias que habrir el localhost. no se en que port.
espero no haberte confundido , pero yo lo hago..:P
en todo caso te podes fijar en el linux a ver en que port esta
te copio como me salio a mi en mi linux

netstat -ant | grep 5432
tcp 0 0 0.0.0.0:5432 0.0.0.0:* LISTEN

el grep lo uso porque el netstat en un linux medianamente cargado tiene varias pantallas.

el driver odbc tiene en algunas versiones un boton de test.
bueno se me ocurre mas con tu correo.
una ultima cosa
que version de postgres?
que version de linux?
que windows?
salu2
mdc


--- El jue 3-jul-08, Mauricio Lopez <mauricio.lopez.b@gmail.com> escribió:

> De: Mauricio Lopez <mauricio.lopez.b@gmail.com>
> Asunto: [pgsql-es-ayuda] Ayuda con postgresql.conf y ODBC
> Para: pgsql-es-ayuda@postgresql.org
> Fecha: jueves, 3 de julio de 2008, 6:14 pm
> Hola,
>
> Este es mi caso, espero me puedan ayudar:
>
> 1. El Problema:
> Tengo postgres instalado en un servidor Linux, y necesito
> generar reportes
> con crystal pero cuando trato de generarlos me sale un
> error de conexion:
> "08001: Could not connect to the server; Could not
> connect to the remote
> socket".
>
> 2. Lo primero que hice:
> Reisé el ODBC y está direccionado al puerto 5432, pero al
> usar netstat -nat
> veo q se está lavantando con el puerto 22.
>
> 3. Después:
> Lo que hice fue entrar al archivo postgresql.conf y vi que
> la instrucción
> port = 5432 estaba "comentada" (y le quité ese
> comentario), hice restart al
> postgres pero sigue levantando en el puerto 22
> tcp 0 0 :::22 :::*
> LIST
> EN
> tcp 0 0 ::ffff:192.168.6.80:22
> ::ffff:192.168.6.35:1472
> ESTA
> BLISHED
> tcp 0 132 ::ffff:192.168.6.80:22
> ::ffff:192.168.6.40:2326
> ESTA
> BLISHED
> tcp 0 0 ::ffff:192.168.6.80:22
> ::ffff:192.168.6.40:1754
> ESTA
>
> 4. Entonces:
> Revisé que en los servicios estuviera especificado el
> puerto 5432 para
> postgres y en efecto lo estaba....
>
> Y ya no se que más hacer para que postgres levante en ese
> puerto 5432, o al
> menos, para que me funcione el reporte de crystal por
> cualquier lado :((
>
> Recibo sugerencias, ayudas....
>
> gracias


____________________________________________________________________________________
¡Buscá desde tu celular!

Yahoo! oneSEARCH ahora está en Claro

http://ar.mobile.yahoo.com/onesearch
--
TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?

http://archives.postgresql.org/pgsql-es-ayuda

Posted by at No comments:

[pgsql-es-ayuda] RE: [pgsql-es-ayuda] RE: [pgsql-es-ayuda] No parar =?iso-8859-1?Q?_aplicaci=F3n_en vacuum_full?=

Alvaro,

Gracias por la respuesta.
La solución podría ser ejecutarlo por lo menos 3 o 4 veces al día?

-----Mensaje original-----
De: Alvaro Herrera [mailto:alvherre@commandprompt.com]
Enviado el: lunes, 16 de junio de 2008 17:48
Para: Marcelino Guerrero (GMail)
CC: pgsql-es-ayuda@postgresql.org
Asunto: Re: [pgsql-es-ayuda] RE: [pgsql-es-ayuda] No parar aplicación en
vacuum full

Marcelino Guerrero (GMail) escribió:
> Por que es malo colocar 1 dia en autovacuum_naptime?

Porque autovacuum se ejecutará con muy poca frecuencia, y probablemente
habrá mucha acumulación de tuplas muertas.

--
Alvaro Herrera

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


--
TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?

http://archives.postgresql.org/pgsql-es-ayuda

Posted by at No comments:

[ADMIN] Recourse Usage

G'day,

I have been tasked to tune our company's Postgres database. From the

research I have done I feel the recourse consumption parameters are set far

to low. I have come up with the following modifications to the

configuration and wanted to run this by the mailing list for any

suggestions. The database is on a semi dedicated box, shared only with

memcached which has been allocated 512MB.

-Dual Xeon 2.33GHz

-4GB RAM

-Twin SAS drives in RAID 1

Shared Buffers

Currently: 8192 pages @ 8 KB each // 64MB

To be set to: (256MB - 32768 pages @ 8 KB each)

Work Mem

Currently: 1024kb

To be set to: 1536kb

Effective Cache Size

Currently: 50000 pages // 390MB

To be set to: 128000 pages // 1000MB

Random Page Cost

Currently: 4.0

To be set to: 3.0

Wal Buffers

Currently: 8 @ 8kb each

To be set to: 32 @ 8kb each

Kind Regards,

--

-------------------------------------------------

Steve Kecskes

steve@outtalimits.com.au

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

Posted by at No comments:

Re: [BUGS] libpq does not manage SSL callbacks properly when other libraries are involved.

Russell Smith wrote:
> Hi,
>
> After experiencing a seg fault on RHEL5's command line php, I did the
> following investigation.
>
> As I dot not have a RHEL5 box available with debugging tools, I
> reproduced the bug on CentOS5.
Hi,

I've not received any feedback on this bug in a week, is anybody looking
at it. Is there anything I'm doing wrong with my report of this bug?

Thanks

Russell.

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

Posted by at No comments:

Re: [HACKERS] the un-vacuumable table

"Andrew Hammond" <andrew.george.hammond@gmail.com> writes:
> On Thu, Jul 3, 2008 at 2:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The whole thing is pretty mystifying, especially the ENOSPC write
>> failure on what seems like it couldn't have been a full disk.

> Yes, I've passed along the task of explaining why PG thought the disk
> was full to the sysadmin responsible for the box. I'll post the answer
> here, when and if we have one.

I just noticed something even more mystifying: you said that the ENOSPC
error occurred once a day during vacuuming. That doesn't make any
sense, because a write error would leave the shared buffer still marked
dirty, and so the next checkpoint would try to write it again. If
there's a persistent write error on a particular block, you should see
it being complained of at least once per checkpoint interval.

If you didn't see that, it suggests that the ENOSPC was transient,
which isn't unreasonable --- but why would it recur for the exact
same block each night?

Have you looked into the machine's kernel log to see if there is any
evidence of low-level distress (hardware or filesystem level)? I'm
wondering if ENOSPC is being reported because it is the closest
available errno code, but the real problem is something different than
the error message text suggests. Other than the errno the symptoms
all look quite a bit like a bad-sector problem ...

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

Posted by at No comments:

Re: [pgsql-es-ayuda] Ayuda con postgresql.conf y ODBC

revisar en el postgresql.conf que que no este marcada como comentario y con el valor * la linea del listen_addresses.

listen_addresses = '*'

ademas revise que el pg_hba.conf este permitido el acceso de su red o de su host al sevidor de postgres

# IPv4 local connections:
host    all         all         127.0.0.1/32          md5
host    all         all         192.168.1.0/24        md5


2008/7/3 Mauricio Lopez <mauricio.lopez.b@gmail.com>:
Hola,
 
Este es mi caso, espero me puedan ayudar:
 
1. El Problema:
Tengo postgres instalado en un servidor Linux, y necesito generar reportes con crystal pero cuando trato de generarlos me sale un error de conexion: "08001: Could not connect to the server; Could not connect to the remote socket". 
 
2. Lo primero que hice:
Reisé el ODBC y está direccionado al puerto 5432, pero al usar netstat -nat veo q se está lavantando con el puerto 22. 
 
3. Después:
Lo que hice fue entrar al archivo postgresql.conf y vi que la instrucción port = 5432 estaba "comentada" (y le quité ese comentario), hice restart al postgres pero sigue levantando en el puerto 22
tcp        0      0 :::22                       :::*                        LIST                                                                             EN
tcp        0      0 ::ffff:192.168.6.80:22      ::ffff:192.168.6.35:1472    ESTA                                                                             BLISHED
tcp        0    132 ::ffff:192.168.6.80:22      ::ffff:192.168.6.40:2326    ESTA                                                                             BLISHED
tcp        0      0 ::ffff:192.168.6.80:22      ::ffff:192.168.6.40:1754    ESTA
 
4. Entonces:
Revisé que en los servicios estuviera especificado el puerto 5432 para postgres y en efecto lo estaba....
 
Y ya no se que más hacer para que postgres levante en ese puerto 5432, o al menos, para que me funcione el reporte de crystal por cualquier lado :((
 
Recibo sugerencias, ayudas....
 
gracias



--

-----------------------
MVJR
Posted by at No comments:

Re: [pgsql-es-ayuda] como lenvantar pgsql 8.3 en linux ?

De verdas gracias a todos por su ayuda,

por fin levante el pgsql,
gracias de nuevo
saludos
Posted by at No comments:

Re: [HACKERS] CommitFest rules

On Thu, Jul 3, 2008 at 10:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Merlin Moncure" <mmoncure@gmail.com> writes:
>> Are you suggesting that omission of a patch on the 'fest' page means
>> that you are bumped from the fest?
>
> No, if you had submitted the patch on time then the correct next step
> is to get it added to the fest page; I don't think that should be
> controversial. But the reviewers aren't gonna review it if it's not
> listed on that page...

Right, but the author should take some responsibility for ensuring the
patch is listed on time. What we don't want is forgotten patches
getting added at the last minute, right as the CommitFest manager is
wrapping things up having got 95% of the patches reviewed and the
other 5% in progress.

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

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

Posted by at No comments:

Re: [HACKERS] the un-vacuumable table

On Thu, Jul 3, 2008 at 2:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Andrew Hammond" <andrew.george.hammond@gmail.com> writes:
>> Does anyone else have any suggestions about what I can do to diagnose this?
>
> The whole thing is pretty mystifying, especially the ENOSPC write
> failure on what seems like it couldn't have been a full disk.

Yes, I've passed along the task of explaining why PG thought the disk
was full to the sysadmin responsible for the box. I'll post the answer
here, when and if we have one.

>> Jun 27 15:54:31 qadb2 postgres[92519]: [44-1] PANIC: could not open
>> relation 1663/16386/679439393: No such file or directory
>
> I don't think anyone asked before --- after the restore fails with the
> above, does the directory $PGDATA/base/16386/ exist? Although WAL
> recovery should attempt to create missing files, I think it won't
> try to create missing directories.

The directory exists (and the 679439393 file does not).

Andrew

--
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: [ADMIN] Who's attached to the database?

>>> Bricklen Anderson <banderson@presinet.com> wrote:

>> Is there a command to disconnect this user?
>
> select pg_cancel_backend(<procpid of connection>);

I thought that just canceled the currently active statement (if any).
Don't you need to use pg_ctl kill (or the OS kill command) to actually
close the connection?

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


http://www.postgresql.org/docs/8.3/interactive/app-pg-ctl.html


-Kevin

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

Posted by at No comments:

Re: [HACKERS] CommitFest rules

"Merlin Moncure" <mmoncure@gmail.com> writes:
> Are you suggesting that omission of a patch on the 'fest' page means
> that you are bumped from the fest?

No, if you had submitted the patch on time then the correct next step
is to get it added to the fest page; I don't think that should be
controversial. But the reviewers aren't gonna review it if it's not
listed on that page...

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

Posted by at No comments:

Re: [HACKERS] the un-vacuumable table

"Andrew Hammond" <andrew.george.hammond@gmail.com> writes:
> Does anyone else have any suggestions about what I can do to diagnose this?

The whole thing is pretty mystifying, especially the ENOSPC write
failure on what seems like it couldn't have been a full disk.

> Jun 27 15:54:31 qadb2 postgres[92519]: [44-1] PANIC: could not open
> relation 1663/16386/679439393: No such file or directory

I don't think anyone asked before --- after the restore fails with the
above, does the directory $PGDATA/base/16386/ exist? Although WAL
recovery should attempt to create missing files, I think it won't
try to create missing directories.

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

Posted by at No comments:

RE: [pgsql-es-ayuda] [OT] Cubanos en la lista

JAJAJAAJA!
No es mio es una fundacion de la cual soy miembro de ayuda a hermanos cubanos. Iban a regalar eso alla y obvio que quise que mis companeros de lista fueran tambien beneficiados

*-------------------------------------------------------*
*-Edwin Quijada
*-Developer DataBase
*-JQ Microsistemas
*-809-849-8087

* " Si deseas lograr cosas excepcionales debes de hacer cosas fuera de lo comun"
*-------------------------------------------------------*


> Date: Thu, 3 Jul 2008 13:14:39 -0700
> From: jmdc_marcelo@yahoo.com.ar
> Subject: RE: [pgsql-es-ayuda] [OT] Cubanos en la lista
> To: hermeszambra@yahoo.com; pgsql-es-ayuda@postgresql.org; dmarante@estudiantes.uci.cu; listas_quijada@hotmail.com
>
> Edwin
>
> Espectacular!!! lo tuyo, me deja atonito tu generosidad.
> salud2
> mdc
>
>
> --- El jue 3-jul-08, Edwin Quijada escribió:
>
>> De: Edwin Quijada
>> Asunto: RE: [pgsql-es-ayuda] [OT] Cubanos en la lista
>> Para: hermeszambra@yahoo.com, pgsql-es-ayuda@postgresql.org, "Danner Marante Jacas" , jmdc_marcelo@yahoo.com.ar
>> Fecha: jueves, 3 de julio de 2008, 5:08 pm
>> El regalo era solo para los cubanos de alla ya que iba un
>> companero mio desde aca Republica DOminicana a Cuba e iba
>> llevar memorias, celulares y u par de laptops para los
>> jovenes de Cuba .
>>
>> *-------------------------------------------------------*
>> *-Edwin Quijada
>> *-Developer DataBase
>> *-JQ Microsistemas
>> *-809-849-8087
>>
>> * " Si deseas lograr cosas excepcionales debes de
>> hacer cosas fuera de lo comun"
>> *-------------------------------------------------------*
>>
>>
>>> Date: Wed, 2 Jul 2008 19:26:22 -0700
>>> From: hermeszambra@yahoo.com
>>> Subject: RE: [pgsql-es-ayuda] [OT] Cubanos en la lista
>>> To: pgsql-es-ayuda@postgresql.org;
>> dmarante@estudiantes.uci.cu; jmdc_marcelo@yahoo.com.ar
>>>
>>>
>>>
>>>
>>> --- El mar 1-jul-08, marcelo Cortez escribió:
>>>
>>>> De: marcelo Cortez
>>>> Asunto: RE: [pgsql-es-ayuda] [OT] Cubanos en la
>> lista
>>>> A: pgsql-es-ayuda@postgresql.org, "Danner
>> Marante Jacas"
>>>> Fecha: martes, 1 julio, 2008, 1:28 pm
>>>> Hola Gente
>>>>
>>>> Me quedo una duda, tal vez me falto un correo en
>> mi bandeja
>>>> de entrada ,
>>>> del email de Edwin cual era la sorpresa/regalo?
>>>> No vivo en cuba , pero tambien soy desarrollador
>> de
>>>> postgres linux , php , etc etc . y me gustaria
>> colaborar,
>>>> :P
>>>>
>>>> saludos
>>>> mdc
>>>>
>>>>
>>>> --- El lun 30-jun-08, Danner Marante Jacas
>>>> escribió:
>>>>
>>>>> De: Danner Marante Jacas
>>>>
>>>>> Asunto: RE: [pgsql-es-ayuda] [OT] Cubanos en
>> la lista
>>>>> Para: pgsql-es-ayuda@postgresql.org
>>>>> Fecha: lunes, 30 de junio de 2008, 3:59 pm
>>>>> Hola a todos creo que es un poco tarde para el
>> pos
>>>> pero soy
>>>>> estudiante cubano 5 años en la carrera de
>>>> informática en
>>>>> la uci, tengo 2 años de experiencia en el
>> desarrollo
>>>> con
>>>>> bases de datos y me gustaría formar parte del
>>>> proyecto,
>>>>> sobre todo desarrollar sobre postgres
>>>>>
>>>>> -----Original Message-----
>>>>> From: pgsql-es-ayuda-owner@postgresql.org
>>>>> [mailto:pgsql-es-ayuda-owner@postgresql.org]
>> On Behalf
>>>> Of
>>>>> Danier Marante Jacas
>>>>> Sent: lunes, 30 de junio de 2008 13:25
>>>>> To: pgsql-es-ayuda@postgresql.org
>>>>> Subject: RE: [pgsql-es-ayuda] [OT] Cubanos en
>> la lista
>>>>>
>>>>> también soy cubano, soy estudiante de 5 año
>> de
>>>>> ingeniería informática en la UCI, tengo 2
>> años de
>>>>> experiencia como desarrollador de una db
>> bastante
>>>> grande,
>>>>> me encanta postgres aunque nunca he
>> desarrollado
>>>> fuerte
>>>>> sobre el,
>>>>> me encantaría colaborar.
>>>>> mi gtalk es dmjacas@gmail.com
>>>>> ________________________________
>>>>>
>>>>> From: pgsql-es-ayuda-owner@postgresql.org on
>> behalf of
>>>> Luis
>>>>> Esteban de Dios Núñez
>>>>> Sent: Sun 29.06.2008 09:54 am
>>>>> To: pgsql-es-ayuda@postgresql.org
>>>>> Subject: Re: [pgsql-es-ayuda] [OT] Cubanos en
>> la lista
>>>>>
>>>>>
>>>>>
>>>>> Hola Juan Carlos, Gabriely Reynier,
>>>>>
>>>>> También yo estoy dispuesto a colaborar. He
>> aprendido
>>>>> alguito sobre
>>>>> PostgreSQL y PHP aunque me gusta más Python.
>> Soy de
>>>> Ciego
>>>>> de Avila pero
>>>>> vivo hace ya algo en Pinar del Río. Trabajo
>> en una
>>>> SUM de
>>>>> Ciencias Médicas
>>>>> en el municipio La Palma como Metodólogo de
>>>>> Investigaciones. Uso SuSE
>>>>> Linux desda hace algún tiempo. El software
>> libre es
>>>> mi
>>>>> delirio.
>>>>>
>>>>> Hoy lunes, cuando vi el primer mensaje de
>> Edwin
>>>> respondí
>>>>> anticipadamente,
>>>>> imagínense tenía 181 email en mi bandeja.
>> Esoty
>>>> subscrito
>>>>> a varias listas:
>>>>> opensuse-es, pgsql-es-ayuda, python-es, pyar,
>> prog,
>>>>> mono-hispano, etc...
>>>>>
>>>>> Que desastre, je je je.
>>>>>
>>>>>
>>>>> --
>>>>> Saludos
>>>>>
>>>>> Luis Esteban de Dios Núñez
>>>>> --
>>>>> TIP 3: Si encontraste la respuesta a tu
>> problema,
>>>>> publícala, otros te lo agradecerán
>>>>>
>>>>>
>>>>> --
>>>>> TIP 7: no olvides aumentar la configuración
>> del
>>>> "free
>>>>> space map"
>>>>> --
>>>>> TIP 5: ¿Has leído nuestro extenso FAQ?
>>>>> http://www.postgresql.org/docs/faqs.FAQ.html
>>>>
>>>>
>>>>
>>>>
>> ____________________________________________________________________________________
>>>> ¡Buscá desde tu celular!
>>>>
>>>> Yahoo! oneSEARCH ahora está en Claro
>>>>
>>>> http://ar.mobile.yahoo.com/onesearch
>>>> --
>>>> TIP 8: explain analyze es tu amigo
>>>
>>> Aclaro que la duda del regalo me queda a mi tambien,
>> pero festejo la intencion de Edwin de colaborar con quienes
>> por conviccion adoptan el SL
>>>
>>> __________________________________________________
>>> Correo Yahoo!
>>> Espacio para todos tus mensajes, antivirus y antispam
>> ¡gratis!
>>> Regístrate ya - http://correo.espanol.yahoo.com/
>>> --
>>> TIP 6: ¿Has buscado en los archivos de nuestra lista
>> de correo?
>>> http://archives.postgresql.org/pgsql-es-ayuda
>>
>> _________________________________________________________________
>> Stop squinting -- view your photos on your TV. Learn more.
>> http://www.microsoft.com/windows/digitallife/default.mspx?deepLink=photos--
>> TIP 7: no olvides aumentar la configuración del "free
>> space map"
>
>
> ____________________________________________________________________________________
> ¡Buscá desde tu celular!
>
> Yahoo! oneSEARCH ahora está en Claro
>
> http://ar.mobile.yahoo.com/onesearch

_________________________________________________________________
Get your fix of news, sports, entertainment and more on MSN Mobile
http://www.msnmobilefix.com/Default.aspx--
TIP 7: no olvides aumentar la configuración del "free space map"

Posted by at No comments:

Re: [ADMIN] Who's attached to the database?

Oh, thanks so much. This is something I really needed.

Carol

On Jul 3, 2008, at 5:17 PM, Bricklen Anderson wrote:

> Carol Walter wrote:
>> Thanks, guys,
>> This told me that the user that has it open is the interface user
>> called db_user. Is there a command to disconnect this user?
>> Carol
>
> select pg_cancel_backend(<procpid of connection>);


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

Posted by at No comments:

Re: [ADMIN] Who's attached to the database?

Carol Walter wrote:
> Thanks, guys,
>
> This told me that the user that has it open is the interface user called
> db_user. Is there a command to disconnect this user?
>
> Carol

select pg_cancel_backend(<procpid of connection>);

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

Posted by at No comments:

[pgsql-es-ayuda] Ayuda con postgresql.conf y ODBC

Hola,
 
Este es mi caso, espero me puedan ayudar:
 
1. El Problema:
Tengo postgres instalado en un servidor Linux, y necesito generar reportes con crystal pero cuando trato de generarlos me sale un error de conexion: "08001: Could not connect to the server; Could not connect to the remote socket". 
 
2. Lo primero que hice:
Reisé el ODBC y está direccionado al puerto 5432, pero al usar netstat -nat veo q se está lavantando con el puerto 22. 
 
3. Después:
Lo que hice fue entrar al archivo postgresql.conf y vi que la instrucción port = 5432 estaba "comentada" (y le quité ese comentario), hice restart al postgres pero sigue levantando en el puerto 22
tcp        0      0 :::22                       :::*                        LIST                                                                             EN
tcp        0      0 ::ffff:192.168.6.80:22      ::ffff:192.168.6.35:1472    ESTA                                                                             BLISHED
tcp        0    132 ::ffff:192.168.6.80:22      ::ffff:192.168.6.40:2326    ESTA                                                                             BLISHED
tcp        0      0 ::ffff:192.168.6.80:22      ::ffff:192.168.6.40:1754    ESTA
 
4. Entonces:
Revisé que en los servicios estuviera especificado el puerto 5432 para postgres y en efecto lo estaba....
 
Y ya no se que más hacer para que postgres levante en ese puerto 5432, o al menos, para que me funcione el reporte de crystal por cualquier lado :((
 
Recibo sugerencias, ayudas....
 
gracias
Posted by at No comments:

Re: [PATCHES] Exposing keywords to clients

Nikhils <nikkhils@gmail.com> writes:
>>> Attached is an updated patch, giving the following output.

Applied with minor revisions.

> Here are some comments from me:

> a) Changed "localised" to "localized" to be consistent with the references
> elsewhere in the same file.

What I didn't like about the docs was the classification of the function
as a "session information function". There's certainly nothing
session-dependent about it. I ended up putting it under "System Catalog
Information Functions", which isn't really quite right either but it's
closer than the other one.

> b) I wonder if we need the default case in the switch statement at all,
> since we are scanning the statically populated ScanKeywords array with
> proper category values for each entry.

I left it in for safety, but made it just return nulls --- there's no
point in wasting more code space on it than necessary, and certainly
no point in asking translators to translate a useless string.

> c) There was a warning during compilation since we were assigning a const
> pointer to a char pointer
> values[0] = ScanKeywords[funcctx->call_cntr].name;

Yeah, I couldn't see a good way around that either --- we could pstrdup
but that seems overkill, and adjusting the API of BuildTupleFromCStrings
to take const char ** doesn't look appetizing either.

> d) oid 2700 has been claimed by another function in the meanwhile. Modified
> it to 2701.
> DATA(insert OID = 2701 ( pg_get_keywords PGNSP PGUID 12 10 400 f f t t s
> 0 2249

2701 was claimed too. You need to use the unused_oids script to find
unique free OIDs.

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

Posted by at No comments:

[COMMITTERS] pgsql: Add a function pg_get_keywords() to let clients find out the set

Log Message:
-----------
Add a function pg_get_keywords() to let clients find out the set of keywords
known to the SQL parser. Dave Page

Modified Files:
--------------
pgsql/doc/src/sgml:
func.sgml (r1.437 -> r1.438)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/func.sgml?r1=1.437&r2=1.438)
pgsql/src/backend/parser:
keywords.c (r1.197 -> r1.198)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/parser/keywords.c?r1=1.197&r2=1.198)
pgsql/src/backend/utils/adt:
misc.c (r1.62 -> r1.63)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/misc.c?r1=1.62&r2=1.63)
pgsql/src/include/catalog:
catversion.h (r1.464 -> r1.465)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/catversion.h?r1=1.464&r2=1.465)
pg_proc.h (r1.503 -> r1.504)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/pg_proc.h?r1=1.503&r2=1.504)
pgsql/src/include/parser:
keywords.h (r1.24 -> r1.25)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/parser/keywords.h?r1=1.24&r2=1.25)
pgsql/src/include/utils:
builtins.h (r1.317 -> r1.318)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/utils/builtins.h?r1=1.317&r2=1.318)

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

Posted by at No comments:

Re: [HACKERS] CommitFest rules

On Thu, Jul 3, 2008 at 3:45 PM, Dave Page <dpage@pgadmin.org> wrote:
> On Thu, Jul 3, 2008 at 8:34 PM, Alex Hunsaker <badalex@gmail.com> wrote:
>
>> The one I advised be added (the Auto Explain patch) was posted on Mar
>> 29, 2008 (http://archives.postgresql.org/pgsql-hackers/2008-03/msg01214.php),
>> re-posted the Jun 30th and then an updated patch today... It only
>> being the 3rd i figured it still meet the criteria. If thats not the
>> case, I apologize.
>
> You'll note I didn't actually mention any specific patches.
>
> The CommitFests are designed to be short and quick to complete. We
> need *all* patches to be listed (not just posted to a list sometime in
> the past couple of months) before it starts, otherwise organisation of
> reviewers and completion of the Fest becomes chaotic for all and a
> nightmare task for the CommitFest manager.

Are you suggesting that omission of a patch on the 'fest' page means
that you are bumped from the fest? Note that Tom asked on July 1 if
there were any missing entries that hadn't been plucked out of the
lists (there were).

If that's the case, that would suggest that it is the patch author's
responsibility to to update the fest entry (or at least, make sure it
was updated). That may already be the case -- i'm not sure -- and I'm
not saying that's wrong, but if you are going to adopt a strict policy
(which btw I have no problem with) it's probably better to remind
stragglers to get with the program a week or so the fest begins,
especially on the last fest of the release cycle.

merlin

--
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] the un-vacuumable table

Does anyone else have any suggestions about what I can do to diagnose this?

Do I need to re-initdb or can I reasonably keep running with the existing db?

A

On Mon, Jun 30, 2008 at 7:20 PM, Andrew Hammond
<andrew.george.hammond@gmail.com> wrote:
> On Fri, Jun 27, 2008 at 8:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> "Andrew Hammond" <andrew.george.hammond@gmail.com> writes:
>>> (I thought this line was interesting)
>>> Jun 27 15:54:31 qadb2 postgres[92519]: [44-1] PANIC: could not open
>>> relation 1663/16386/679439393: No such file or directory
>>
>>> I googled to find out what the numbers 1663/16386/679439393 from the
>>> PANIC message mean, but no luck.
>>
>> tablespaceOID/databaseOID/relfilenode. Looks like just some random user
>> table. Not clear why this would be a crash, *especially* since WAL
>> recovery is generally willing to create nonexistent files. Is this
>> reproducible?
>
> Yes, both when I just tried to restart the recovery:
>
> Jun 30 16:04:43 qadb2 postgres[20797]: [27-1] DEBUG: invoking
> IpcMemoryCreate(size=92938240)
> Jun 30 16:04:43 qadb2 postgres[20797]: [28-1] DEBUG: max_safe_fds =
> 983, usable_fds = 1000, already_open = 7
> Jun 30 16:04:43 qadb2 postgres[20798]: [29-1] LOG: database system
> was interrupted while in recovery at 2008-06-27 15:54:31 PDT
> Jun 30 16:04:43 qadb2 postgres[20798]: [29-2] HINT: This probably
> means that some data is corrupted and you will have to use the last
> backup for recovery.
> Jun 30 16:04:43 qadb2 postgres[20798]: [30-1] LOG: starting archive recovery
> Jun 30 16:04:43 qadb2 postgres[20798]: [31-1] LOG: restore_command =
> "cp -p /usr/tmp/2008-06-25_wals/%f %p"
> Jun 30 16:04:43 qadb2 postgres[20798]: [32-1] DEBUG: executing
> restore command "cp -p /usr/tmp/2008-06-25_wals/00000001.history
> pg_xlog/RECOVERYHISTORY"
> Jun 30 16:04:43 qadb2 postgres[20798]: [33-1] DEBUG: could not
> restore file "00000001.history" from archive: return code 256
> Jun 30 16:04:43 qadb2 postgres[20798]: [34-1] DEBUG: executing
> restore command "cp -p
> /usr/tmp/2008-06-25_wals/00000001000001D600000078.0055F0B8.backup
> Jun 30 16:04:43 qadb2 postgres[20798]: [34-2] pg_xlog/RECOVERYHISTORY"
> Jun 30 16:04:43 qadb2 postgres[20798]: [35-1] LOG: restored log file
> "00000001000001D600000078.0055F0B8.backup" from archive
> Jun 30 16:04:43 qadb2 postgres[20798]: [36-1] DEBUG: executing
> restore command "cp -p
> /usr/tmp/2008-06-25_wals/00000001000001D600000078
> pg_xlog/RECOVERYXLOG"
> Jun 30 16:04:44 qadb2 postgres[20797]: [29-1] DEBUG: forked new
> backend, pid=20805 socket=8
> Jun 30 16:04:44 qadb2 postgres[20805]: [29-1] LOG: connection
> received: host=[local]
> Jun 30 16:04:44 qadb2 postgres[20805]: [30-1] FATAL: the database
> system is starting up
> Jun 30 16:04:44 qadb2 postgres[20805]: [31-1] DEBUG: proc_exit(0)
> Jun 30 16:04:44 qadb2 postgres[20805]: [32-1] DEBUG: shmem_exit(0)
> Jun 30 16:04:44 qadb2 postgres[20805]: [33-1] DEBUG: exit(0)
> Jun 30 16:04:44 qadb2 postgres[20797]: [30-1] DEBUG: reaping dead processes
> Jun 30 16:04:44 qadb2 postgres[20797]: [31-1] DEBUG: server process
> (PID 20805) exited with exit code 0
> Jun 30 16:04:44 qadb2 postgres[20798]: [37-1] LOG: restored log file
> "00000001000001D600000078" from archive
> Jun 30 16:04:44 qadb2 postgres[20798]: [38-1] LOG: checkpoint record
> is at 1D6/7855F0B8
> Jun 30 16:04:44 qadb2 postgres[20798]: [39-1] LOG: redo record is at
> 1D6/7855F0B8; undo record is at 0/0; shutdown FALSE
> Jun 30 16:04:44 qadb2 postgres[20798]: [40-1] LOG: next transaction
> ID: 397171279; next OID: 679516596
> Jun 30 16:04:44 qadb2 postgres[20798]: [41-1] LOG: next MultiXactId:
> 857318; next MultiXactOffset: 1718141
> Jun 30 16:04:44 qadb2 postgres[20798]: [42-1] LOG: automatic recovery
> in progress
> Jun 30 16:04:44 qadb2 postgres[20798]: [43-1] LOG: redo starts at 1D6/7855F108
>
> Jun 30 16:04:45 qadb2 postgres[20798]: [44-1] PANIC: could not open
> relation 1663/16386/679439393: No such file or directory
>
> Jun 30 16:04:45 qadb2 postgres[20797]: [32-1] DEBUG: reaping dead processes
> Jun 30 16:04:45 qadb2 postgres[20797]: [33-1] LOG: startup process
> (PID 20798) was terminated by signal 6
> Jun 30 16:04:45 qadb2 postgres[20797]: [34-1] LOG: aborting startup
> due to startup process failure
> Jun 30 16:04:45 qadb2 postgres[20797]: [35-1] DEBUG: proc_exit(1)
> Jun 30 16:04:45 qadb2 postgres[20797]: [36-1] DEBUG: shmem_exit(1)
> Jun 30 16:04:45 qadb2 postgres[20797]: [37-1] DEBUG: exit(1)
>
>
>
> And also when I tried to wipe the slate clean and recover it freshly.
>
> Jun 30 19:11:59 qadb2 postgres[23091]: [1-1] DEBUG: postmaster:
> PostmasterMain: initial environ dump:
> Jun 30 19:11:59 qadb2 postgres[23091]: [2-1] DEBUG:
> -----------------------------------------
> Jun 30 19:11:59 qadb2 postgres[23091]: [3-1] DEBUG: USER=pgsql
> Jun 30 19:11:59 qadb2 postgres[23091]: [4-1] DEBUG: MAIL=/var/mail/pgsql
> Jun 30 19:11:59 qadb2 postgres[23091]: [5-1] DEBUG:
> LD_LIBRARY_PATH=:/usr/local/adecn/lib
> Jun 30 19:11:59 qadb2 postgres[23091]: [6-1] DEBUG: HOME=/usr/local/pgsql
> Jun 30 19:11:59 qadb2 postgres[23091]: [7-1] DEBUG: PGLIB=/usr/local/lib
> Jun 30 19:11:59 qadb2 postgres[23091]: [8-1] DEBUG: PS1=[QA2] \u@\h:\w\$
> Jun 30 19:11:59 qadb2 postgres[23091]: [9-1] DEBUG: BLOCKSIZE=K
> Jun 30 19:11:59 qadb2 postgres[23091]: [10-1] DEBUG: TERM=xterm
> Jun 30 19:11:59 qadb2 postgres[23091]: [11-1] DEBUG:
> PGSYSCONFDIR=/usr/local/etc/postgresql
> Jun 30 19:11:59 qadb2 postgres[23091]: [12-1] DEBUG:
> PGLOCALEDIR=/usr/local/share/locale
> Jun 30 19:11:59 qadb2 postgres[23091]: [13-1] DEBUG:
> Jun 30 19:11:59 qadb2 postgres[23091]: [13-2]
> PATH=/usr/local/adecn/bin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin
> Jun 30 19:11:59 qadb2 postgres[23091]: [13-3] :/usr/local/pgsql/bin
>
> (snip junk about environment)
>
> Jun 30 19:11:59 qadb2 postgres[23091]: [19-1] DEBUG:
> PGDATA=/var/db/adecn/adecndb
> Jun 30 19:11:59 qadb2 postgres[23091]: [20-1] DEBUG: LC_COLLATE=C
> Jun 30 19:11:59 qadb2 postgres[23091]: [21-1] DEBUG: LC_CTYPE=C
> Jun 30 19:11:59 qadb2 postgres[23091]: [22-1] DEBUG: LC_MESSAGES=C
> Jun 30 19:11:59 qadb2 postgres[23091]: [23-1] DEBUG: LC_MONETARY=C
> Jun 30 19:11:59 qadb2 postgres[23091]: [24-1] DEBUG: LC_NUMERIC=C
> Jun 30 19:11:59 qadb2 postgres[23091]: [25-1] DEBUG: LC_TIME=C
> Jun 30 19:11:59 qadb2 postgres[23091]: [26-1] DEBUG:
> -----------------------------------------
> Jun 30 19:11:59 qadb2 postgres[23092]: [27-1] DEBUG: invoking
> IpcMemoryCreate(size=92938240)
> Jun 30 19:11:59 qadb2 postgres[23092]: [28-1] DEBUG: max_safe_fds =
> 983, usable_fds = 1000, already_open = 7
> Jun 30 19:11:59 qadb2 postgres[23093]: [29-1] LOG: database system
> was interrupted at 2008-06-25 03:01:02 PDT
> Jun 30 19:11:59 qadb2 postgres[23093]: [30-1] LOG: starting archive recovery
> Jun 30 19:11:59 qadb2 postgres[23093]: [31-1] LOG: restore_command =
> "cp -p /usr/tmp/2008-06-25_wals/%f %p"
> Jun 30 19:11:59 qadb2 postgres[23093]: [32-1] DEBUG: executing
> restore command "cp -p /usr/tmp/2008-06-25_wals/00000001.history
> pg_xlog/RECOVERYHISTORY"
> Jun 30 19:11:59 qadb2 postgres[23093]: [33-1] DEBUG: could not
> restore file "00000001.history" from archive: return code 256
> Jun 30 19:11:59 qadb2 postgres[23093]: [34-1] DEBUG: executing
> restore command "cp -p
> /usr/tmp/2008-06-25_wals/00000001000001D600000078.0055F0B8.backup
> Jun 30 19:11:59 qadb2 postgres[23093]: [34-2] pg_xlog/RECOVERYHISTORY"
> Jun 30 19:11:59 qadb2 postgres[23093]: [35-1] LOG: restored log file
> "00000001000001D600000078.0055F0B8.backup" from archive
> Jun 30 19:11:59 qadb2 postgres[23093]: [36-1] DEBUG: executing
> restore command "cp -p
> /usr/tmp/2008-06-25_wals/00000001000001D600000078
> pg_xlog/RECOVERYXLOG"
> Jun 30 19:12:00 qadb2 postgres[23093]: [37-1] LOG: restored log file
> "00000001000001D600000078" from archive
> Jun 30 19:12:00 qadb2 postgres[23093]: [38-1] LOG: checkpoint record
> is at 1D6/7855F0B8
> Jun 30 19:12:00 qadb2 postgres[23093]: [39-1] LOG: redo record is at
> 1D6/7855F0B8; undo record is at 0/0; shutdown FALSE
> Jun 30 19:12:00 qadb2 postgres[23093]: [40-1] LOG: next transaction
> ID: 397171279; next OID: 679516596
> Jun 30 19:12:00 qadb2 postgres[23093]: [41-1] LOG: next MultiXactId:
> 857318; next MultiXactOffset: 1718141
> Jun 30 19:12:00 qadb2 postgres[23093]: [42-1] LOG: automatic recovery
> in progress
> Jun 30 19:12:00 qadb2 postgres[23093]: [43-1] LOG: redo starts at 1D6/7855F108
>
> Jun 30 19:12:00 qadb2 postgres[23093]: [44-1] PANIC: could not open
> relation 1663/16386/679439393: No such file or directory
>
> Jun 30 19:12:00 qadb2 postgres[23092]: [29-1] DEBUG: reaping dead processes
> Jun 30 19:12:00 qadb2 postgres[23092]: [30-1] LOG: startup process
> (PID 23093) was terminated by signal 6
> Jun 30 19:12:00 qadb2 postgres[23092]: [31-1] LOG: aborting startup
> due to startup process failure
> Jun 30 19:12:00 qadb2 postgres[23092]: [32-1] DEBUG: proc_exit(1)
> Jun 30 19:12:00 qadb2 postgres[23092]: [33-1] DEBUG: shmem_exit(1)
> Jun 30 19:12:00 qadb2 postgres[23092]: [34-1] DEBUG: exit(1)
>
> So yes, I believe this is entirely repeatable.
>
>>> (On Thursday night)
>>> vacuumdb: vacuuming of database "adecndb" failed: ERROR: could not
>>> write block 209610 of relation 1663/16386/236356665: No space left on
>>> device
>>> CONTEXT: writing block 209610 of relation 1663/16386/236356665
>>
>> That's pretty frickin' odd as well, because as a rule we make sure that
>> backing store exists for each table page before we open it up for
>> normal writing. Do you have a way to find out what relation
>> 1663/16386/236356665 is?
>
> 1663 = pg_default tablespace
> 16386 = adecndb, the only database (aside from postgres, template1 & 0
> on this backend).
>
> SELECT relname FROM pg_class WHERE relfilenode = 236356665; -- got nothing
>
> But this is on the production database where a vacuum has already succeeded.
>
>> What filesystem is this database sitting on?
>
> FreeBSD 6.2 ufs. Here are the options from /etc/fstab.
>
> /dev/da1 /xraid ufs rw,noatime 2 2
>
>>> Now, the first message is very strange since we have monitoring on the
>>> file system used by the database and it's been hovering at about 18%
>>> space used for the last month. So I can't figure out why we'd get "No
>>> space left on device", assuming the device is actually the disk (which
>>> seems reasonable given the context) and not shared memory.
>>
>> Yeah, this is definitely a case of ENOSPC being returned by write(),
>> If you're sure the disk wasn't out of space, maybe some per-user quota
>> was getting in the way?
>
> Monitoring is using df to determine space available and runs every 5
> minutes. It will alarm at 70% usage and critical at 80% usage. We
> received no alarms or other notifications. We do not yet have tracking
> in place to story the history of this, so I can't say definitively
> that we didn't spike over that usage level. However we are only at 18%
> currently, so it seems unlikely. Nothing else uses this disk.
>
> I checked /etc/rc.conf and did not find quotas turned on. Neither are
> they enabled in the fstab. I confirmed using
> quota -v pgsql
> It says "none".
>
> Andrew
>

--
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-es-ayuda] mineria de datos

gracias por todo y nos avizas cuando subes los demas, para checarlos

On Thu, Jul 3, 2008 at 8:10 AM, Javier Chávez B. <jchavezb@gmail.com> wrote:
On Thu, Jul 3, 2008 at 11:39 AM, Calabaza <calalinux@gmail.com> wrote:
> 2008/7/3 Javier Chávez B. <jchavezb@gmail.com>:
>> Claro no hay problema con gusto!!.. voy a tratar de subirlos a algun
>> lugar y les mando el link para no saturarles sus casillas
>> e interesante es, tengo material de Database Marketing tb si a alguien
>> le interesa, que va de la mano con esto... y de SAD (sistemas de apoyo
>> a la decision)
>
> Excelente! me anoto!
> jejee =)
> Mil Gracias! ;)
> --
> §~^Calabaza^~§ from Villa Elisa, Paraguay
> --
> TIP 9: visita nuestro canal de IRC #postgresql-es en irc.freenode.net
>

Ok colegas aqui les dejo un link
https://www.yousendit.com/download/TTdIc0w3TERreERIRGc9PQ  cuentenme
como les va con la descarga y cuentenme como les va con la lectura del
material si tienen dudas de portugues ( por ejemplo conceptos
matematicos que son importantes y que no se entienden a la primera)
no duden en contactar
Slds a to2 ..
Despues subo si quieren los de SAD que tb son interesantes porque
tocan sistemas fuzzy y clasificacion bayesiana!!

J.

--
----------------------
Slds.
jchavez
linux User #397972 on http://counter.li.org/
--
TIP 9: visita nuestro canal de IRC #postgresql-es en irc.freenode.net



--
atte

juan antonio jaimes valle
toluca, mexico
juanjava@gmail.com
juanjava@yahoo.com
Posted by at No comments:

RE: [pgsql-es-ayuda] [OT] Cubanos en la lista

Edwin

Espectacular!!! lo tuyo, me deja atonito tu generosidad.
salud2
mdc


--- El jue 3-jul-08, Edwin Quijada <listas_quijada@hotmail.com> escribió:

> De: Edwin Quijada <listas_quijada@hotmail.com>
> Asunto: RE: [pgsql-es-ayuda] [OT] Cubanos en la lista
> Para: hermeszambra@yahoo.com, pgsql-es-ayuda@postgresql.org, "Danner Marante Jacas" <dmarante@estudiantes.uci.cu>, jmdc_marcelo@yahoo.com.ar
> Fecha: jueves, 3 de julio de 2008, 5:08 pm
> El regalo era solo para los cubanos de alla ya que iba un
> companero mio desde aca Republica DOminicana a Cuba e iba
> llevar memorias, celulares y u par de laptops para los
> jovenes de Cuba .
>
> *-------------------------------------------------------*
> *-Edwin Quijada
> *-Developer DataBase
> *-JQ Microsistemas
> *-809-849-8087
>
> * " Si deseas lograr cosas excepcionales debes de
> hacer cosas fuera de lo comun"
> *-------------------------------------------------------*
>
>
> > Date: Wed, 2 Jul 2008 19:26:22 -0700
> > From: hermeszambra@yahoo.com
> > Subject: RE: [pgsql-es-ayuda] [OT] Cubanos en la lista
> > To: pgsql-es-ayuda@postgresql.org;
> dmarante@estudiantes.uci.cu; jmdc_marcelo@yahoo.com.ar
> >
> >
> >
> >
> > --- El mar 1-jul-08, marcelo Cortez escribió:
> >
> >> De: marcelo Cortez
> >> Asunto: RE: [pgsql-es-ayuda] [OT] Cubanos en la
> lista
> >> A: pgsql-es-ayuda@postgresql.org, "Danner
> Marante Jacas"
> >> Fecha: martes, 1 julio, 2008, 1:28 pm
> >> Hola Gente
> >>
> >> Me quedo una duda, tal vez me falto un correo en
> mi bandeja
> >> de entrada ,
> >> del email de Edwin cual era la sorpresa/regalo?
> >> No vivo en cuba , pero tambien soy desarrollador
> de
> >> postgres linux , php , etc etc . y me gustaria
> colaborar,
> >> :P
> >>
> >> saludos
> >> mdc
> >>
> >>
> >> --- El lun 30-jun-08, Danner Marante Jacas
> >> escribió:
> >>
> >>> De: Danner Marante Jacas
> >>
> >>> Asunto: RE: [pgsql-es-ayuda] [OT] Cubanos en
> la lista
> >>> Para: pgsql-es-ayuda@postgresql.org
> >>> Fecha: lunes, 30 de junio de 2008, 3:59 pm
> >>> Hola a todos creo que es un poco tarde para el
> pos
> >> pero soy
> >>> estudiante cubano 5 años en la carrera de
> >> informática en
> >>> la uci, tengo 2 años de experiencia en el
> desarrollo
> >> con
> >>> bases de datos y me gustaría formar parte del
> >> proyecto,
> >>> sobre todo desarrollar sobre postgres
> >>>
> >>> -----Original Message-----
> >>> From: pgsql-es-ayuda-owner@postgresql.org
> >>> [mailto:pgsql-es-ayuda-owner@postgresql.org]
> On Behalf
> >> Of
> >>> Danier Marante Jacas
> >>> Sent: lunes, 30 de junio de 2008 13:25
> >>> To: pgsql-es-ayuda@postgresql.org
> >>> Subject: RE: [pgsql-es-ayuda] [OT] Cubanos en
> la lista
> >>>
> >>> también soy cubano, soy estudiante de 5 año
> de
> >>> ingeniería informática en la UCI, tengo 2
> años de
> >>> experiencia como desarrollador de una db
> bastante
> >> grande,
> >>> me encanta postgres aunque nunca he
> desarrollado
> >> fuerte
> >>> sobre el,
> >>> me encantaría colaborar.
> >>> mi gtalk es dmjacas@gmail.com
> >>> ________________________________
> >>>
> >>> From: pgsql-es-ayuda-owner@postgresql.org on
> behalf of
> >> Luis
> >>> Esteban de Dios Núñez
> >>> Sent: Sun 29.06.2008 09:54 am
> >>> To: pgsql-es-ayuda@postgresql.org
> >>> Subject: Re: [pgsql-es-ayuda] [OT] Cubanos en
> la lista
> >>>
> >>>
> >>>
> >>> Hola Juan Carlos, Gabriely Reynier,
> >>>
> >>> También yo estoy dispuesto a colaborar. He
> aprendido
> >>> alguito sobre
> >>> PostgreSQL y PHP aunque me gusta más Python.
> Soy de
> >> Ciego
> >>> de Avila pero
> >>> vivo hace ya algo en Pinar del Río. Trabajo
> en una
> >> SUM de
> >>> Ciencias Médicas
> >>> en el municipio La Palma como Metodólogo de
> >>> Investigaciones. Uso SuSE
> >>> Linux desda hace algún tiempo. El software
> libre es
> >> mi
> >>> delirio.
> >>>
> >>> Hoy lunes, cuando vi el primer mensaje de
> Edwin
> >> respondí
> >>> anticipadamente,
> >>> imagínense tenía 181 email en mi bandeja.
> Esoty
> >> subscrito
> >>> a varias listas:
> >>> opensuse-es, pgsql-es-ayuda, python-es, pyar,
> prog,
> >>> mono-hispano, etc...
> >>>
> >>> Que desastre, je je je.
> >>>
> >>>
> >>> --
> >>> Saludos
> >>>
> >>> Luis Esteban de Dios Núñez
> >>> --
> >>> TIP 3: Si encontraste la respuesta a tu
> problema,
> >>> publícala, otros te lo agradecerán
> >>>
> >>>
> >>> --
> >>> TIP 7: no olvides aumentar la configuración
> del
> >> "free
> >>> space map"
> >>> --
> >>> TIP 5: ¿Has leído nuestro extenso FAQ?
> >>> http://www.postgresql.org/docs/faqs.FAQ.html
> >>
> >>
> >>
> >>
> ____________________________________________________________________________________
> >> ¡Buscá desde tu celular!
> >>
> >> Yahoo! oneSEARCH ahora está en Claro
> >>
> >> http://ar.mobile.yahoo.com/onesearch
> >> --
> >> TIP 8: explain analyze es tu amigo
> >
> > Aclaro que la duda del regalo me queda a mi tambien,
> pero festejo la intencion de Edwin de colaborar con quienes
> por conviccion adoptan el SL
> >
> > __________________________________________________
> > Correo Yahoo!
> > Espacio para todos tus mensajes, antivirus y antispam
> ¡gratis!
> > Regístrate ya - http://correo.espanol.yahoo.com/
> > --
> > TIP 6: ¿Has buscado en los archivos de nuestra lista
> de correo?
> > http://archives.postgresql.org/pgsql-es-ayuda
>
> _________________________________________________________________
> Stop squinting -- view your photos on your TV. Learn more.
> http://www.microsoft.com/windows/digitallife/default.mspx?deepLink=photos--
> TIP 7: no olvides aumentar la configuración del "free
> space map"


____________________________________________________________________________________
¡Buscá desde tu celular!

Yahoo! oneSEARCH ahora está en Claro

http://ar.mobile.yahoo.com/onesearch
--
TIP 7: no olvides aumentar la configuración del "free space map"

Posted by at No comments:

RE: [pgsql-es-ayuda] [OT] Cubanos en la lista

El regalo era solo para los cubanos de alla ya que iba un companero mio desde aca Republica DOminicana a Cuba e iba llevar memorias, celulares y u par de laptops para los jovenes de Cuba .

*-------------------------------------------------------*
*-Edwin Quijada
*-Developer DataBase
*-JQ Microsistemas
*-809-849-8087

* " Si deseas lograr cosas excepcionales debes de hacer cosas fuera de lo comun"
*-------------------------------------------------------*


> Date: Wed, 2 Jul 2008 19:26:22 -0700
> From: hermeszambra@yahoo.com
> Subject: RE: [pgsql-es-ayuda] [OT] Cubanos en la lista
> To: pgsql-es-ayuda@postgresql.org; dmarante@estudiantes.uci.cu; jmdc_marcelo@yahoo.com.ar
>
>
>
>
> --- El mar 1-jul-08, marcelo Cortez escribió:
>
>> De: marcelo Cortez
>> Asunto: RE: [pgsql-es-ayuda] [OT] Cubanos en la lista
>> A: pgsql-es-ayuda@postgresql.org, "Danner Marante Jacas"
>> Fecha: martes, 1 julio, 2008, 1:28 pm
>> Hola Gente
>>
>> Me quedo una duda, tal vez me falto un correo en mi bandeja
>> de entrada ,
>> del email de Edwin cual era la sorpresa/regalo?
>> No vivo en cuba , pero tambien soy desarrollador de
>> postgres linux , php , etc etc . y me gustaria colaborar,
>> :P
>>
>> saludos
>> mdc
>>
>>
>> --- El lun 30-jun-08, Danner Marante Jacas
>> escribió:
>>
>>> De: Danner Marante Jacas
>>
>>> Asunto: RE: [pgsql-es-ayuda] [OT] Cubanos en la lista
>>> Para: pgsql-es-ayuda@postgresql.org
>>> Fecha: lunes, 30 de junio de 2008, 3:59 pm
>>> Hola a todos creo que es un poco tarde para el pos
>> pero soy
>>> estudiante cubano 5 años en la carrera de
>> informática en
>>> la uci, tengo 2 años de experiencia en el desarrollo
>> con
>>> bases de datos y me gustaría formar parte del
>> proyecto,
>>> sobre todo desarrollar sobre postgres
>>>
>>> -----Original Message-----
>>> From: pgsql-es-ayuda-owner@postgresql.org
>>> [mailto:pgsql-es-ayuda-owner@postgresql.org] On Behalf
>> Of
>>> Danier Marante Jacas
>>> Sent: lunes, 30 de junio de 2008 13:25
>>> To: pgsql-es-ayuda@postgresql.org
>>> Subject: RE: [pgsql-es-ayuda] [OT] Cubanos en la lista
>>>
>>> también soy cubano, soy estudiante de 5 año de
>>> ingeniería informática en la UCI, tengo 2 años de
>>> experiencia como desarrollador de una db bastante
>> grande,
>>> me encanta postgres aunque nunca he desarrollado
>> fuerte
>>> sobre el,
>>> me encantaría colaborar.
>>> mi gtalk es dmjacas@gmail.com
>>> ________________________________
>>>
>>> From: pgsql-es-ayuda-owner@postgresql.org on behalf of
>> Luis
>>> Esteban de Dios Núñez
>>> Sent: Sun 29.06.2008 09:54 am
>>> To: pgsql-es-ayuda@postgresql.org
>>> Subject: Re: [pgsql-es-ayuda] [OT] Cubanos en la lista
>>>
>>>
>>>
>>> Hola Juan Carlos, Gabriely Reynier,
>>>
>>> También yo estoy dispuesto a colaborar. He aprendido
>>> alguito sobre
>>> PostgreSQL y PHP aunque me gusta más Python. Soy de
>> Ciego
>>> de Avila pero
>>> vivo hace ya algo en Pinar del Río. Trabajo en una
>> SUM de
>>> Ciencias Médicas
>>> en el municipio La Palma como Metodólogo de
>>> Investigaciones. Uso SuSE
>>> Linux desda hace algún tiempo. El software libre es
>> mi
>>> delirio.
>>>
>>> Hoy lunes, cuando vi el primer mensaje de Edwin
>> respondí
>>> anticipadamente,
>>> imagínense tenía 181 email en mi bandeja. Esoty
>> subscrito
>>> a varias listas:
>>> opensuse-es, pgsql-es-ayuda, python-es, pyar, prog,
>>> mono-hispano, etc...
>>>
>>> Que desastre, je je je.
>>>
>>>
>>> --
>>> Saludos
>>>
>>> Luis Esteban de Dios Núñez
>>> --
>>> TIP 3: Si encontraste la respuesta a tu problema,
>>> publícala, otros te lo agradecerán
>>>
>>>
>>> --
>>> TIP 7: no olvides aumentar la configuración del
>> "free
>>> space map"
>>> --
>>> TIP 5: ¿Has leído nuestro extenso FAQ?
>>> http://www.postgresql.org/docs/faqs.FAQ.html
>>
>>
>>
>> ____________________________________________________________________________________
>> ¡Buscá desde tu celular!
>>
>> Yahoo! oneSEARCH ahora está en Claro
>>
>> http://ar.mobile.yahoo.com/onesearch
>> --
>> TIP 8: explain analyze es tu amigo
>
> Aclaro que la duda del regalo me queda a mi tambien, pero festejo la intencion de Edwin de colaborar con quienes por conviccion adoptan el SL
>
> __________________________________________________
> Correo Yahoo!
> Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
> Regístrate ya - http://correo.espanol.yahoo.com/
> --
> TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?
> http://archives.postgresql.org/pgsql-es-ayuda

_________________________________________________________________
Stop squinting -- view your photos on your TV. Learn more.
http://www.microsoft.com/windows/digitallife/default.mspx?deepLink=photos--
TIP 7: no olvides aumentar la configuración del "free space map"

Posted by at No comments:

Re: [pgsql-www] Proposal to remove some mailing lists

Tom Lane wrote:

> I think the general feeling (at least at the developer meeting where
> this was discussed) is that we've erred too far in the second direction
> and need to pull back a bit.

Let me remind that there was no one against this idea of removing
certain lists (and there was plenty of people there.)

--
Alvaro Herrera

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

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

Posted by at No comments:

Re: [ADMIN] Who's attached to the database?

Thanks, guys,

This told me that the user that has it open is the interface user
called db_user. Is there a command to disconnect this user?

Carol

On Jul 3, 2008, at 3:53 PM, Kevin Grittner wrote:

>>>> Carol Walter <walterc@indiana.edu> wrote:
>> I'm trying to drop a database and I'm getting an error that says that
>
>> the database is being accessed by other users. Is there a way I can
>
>> find out who these users are or if there really is a user accessing
> it?
>
> select * from pg_stat_activity where datname = 'yourdb';
>
> -Kevin


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

Posted by at No comments:

Re: [ADMIN] Who's attached to the database?

Carol Walter wrote:
> I'm trying to drop a database and I'm getting an error that says that
> the database is being accessed by other users. Is there a way I can
> find out who these users are or if there really is a user accessing it?
Carol, depending on version and options turned on in the
postgresql.conf, you probably can have a look in the pg_stat_activity
system view:

SELECT datname, client_addr FROM pg_stat_activity WHERE datname = '<db
you're trying to drop>';

Otherwise, you can also have a look at the command line on linux servers
like this:

ps -ef|grep postgres

or

ps aux | grep postgres

depending what ps variant your system includes.

--
Jeff Frost, Owner <jeff@frostconsultingllc.com>
Frost Consulting, LLC

http://www.frostconsultingllc.com/
Phone: 650-780-7908 FAX: 650-649-1954


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

Posted by at No comments:

Re: [ADMIN] Who's attached to the database?

On 2008-07-03, at 21:45, Carol Walter wrote:

> Hi, Guys,
>
> I'm trying to drop a database and I'm getting an error that says
> that the database is being accessed by other users. Is there a way
> I can find out who these users are or if there really is a user
> accessing it?
>
> Carol
>
> --
> Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-admin

select * from pg_stat_activity where datname='<database2drop>';


--

Pawel Socha
pawel.socha@gmail.com


perl -le 's**02).4^&-%2,).^9%4^!./4(%2^3,!#+7!2%^53%2&**y%& -;^[%"`-
{ a%%s%%$_%ee'


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

Posted by at No comments:

Re: [ADMIN] Who's attached to the database?

Carol Walter <walterc@indiana.edu> writes:
> I'm trying to drop a database and I'm getting an error that says that
> the database is being accessed by other users. Is there a way I can
> find out who these users are or if there really is a user accessing it?

pg_stat_activity ... or if you turned that off, "ps auxww | grep postgres"
(or local equivalent) might help.

regards, tom lane

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

Posted by at No comments:

Re: [ADMIN] Who's attached to the database?

>>> Carol Walter <walterc@indiana.edu> wrote:
> I'm trying to drop a database and I'm getting an error that says that

> the database is being accessed by other users. Is there a way I can

> find out who these users are or if there really is a user accessing
it?

select * from pg_stat_activity where datname = 'yourdb';

-Kevin

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

Posted by at No comments:

[COMMITTERS] npgsql - Npgsql2: [#1010421] Matching of parameter names should be

Log Message:
-----------


[#1010421] Matching of parameter names should be case insensitive.
Npgsql now searches for index of parameter names using case sensitivity and case insensitivity.
Thanks Waldemar Bergstreiser for patch.

Modified Files:
--------------
Npgsql2/src/Npgsql:
NpgsqlParameterCollection.cs (r1.7 -> r1.8)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/npgsql/Npgsql2/src/Npgsql/NpgsqlParameterCollection.cs.diff?r1=1.7&r2=1.8)

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

Posted by at No comments:

Re: [HACKERS] CommitFest rules

On Thu, Jul 3, 2008 at 8:34 PM, Alex Hunsaker <badalex@gmail.com> wrote:

> The one I advised be added (the Auto Explain patch) was posted on Mar
> 29, 2008 (http://archives.postgresql.org/pgsql-hackers/2008-03/msg01214.php),
> re-posted the Jun 30th and then an updated patch today... It only
> being the 3rd i figured it still meet the criteria. If thats not the
> case, I apologize.

You'll note I didn't actually mention any specific patches.

The CommitFests are designed to be short and quick to complete. We
need *all* patches to be listed (not just posted to a list sometime in
the past couple of months) before it starts, otherwise organisation of
reviewers and completion of the Fest becomes chaotic for all and a
nightmare task for the CommitFest manager.

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

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

Posted by at No comments:

[ADMIN] Who's attached to the database?

Hi, Guys,

I'm trying to drop a database and I'm getting an error that says that
the database is being accessed by other users. Is there a way I can
find out who these users are or if there really is a user accessing it?

Carol

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

Posted by at No comments:

Re: [pgsql-www] Proposal to remove some mailing lists

"Joshua D. Drake" <jd@commandprompt.com> writes:
> I do not believe it is wise to dump a bunch of people on general
> regardless of the low traffic of other lists. General is entirely too
> active.

Well, there's a tradeoff to be made between having a few busy lists
and having a lot of low-traffic ones. The latter is hardly nirvana,
since you have the problems of fragmented discussions (or else a
lot of cross-posting) as well as a greatly increased risk of misplaced
postings.

I think the general feeling (at least at the developer meeting where
this was discussed) is that we've erred too far in the second direction
and need to pull back a bit.

regards, tom lane

--
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: [HACKERS] CommitFest rules

On Thu, Jul 3, 2008 at 12:44 PM, Dave Page <dpage@pgadmin.org> wrote:
> it concerns me that despite it being day 3 of the July commit fest,
> people are still being advised to add new items to the wiki page.
>
> To make the idea work, we need to stick to the rules we defined when
> we came up with the concept - specifically, no new patches once the
> fest begins!
>
> So please - new patches to the September page!
>
> Regards, Dave

The one I advised be added (the Auto Explain patch) was posted on Mar
29, 2008 (http://archives.postgresql.org/pgsql-hackers/2008-03/msg01214.php),
re-posted the Jun 30th and then an updated patch today... It only
being the 3rd i figured it still meet the criteria. If thats not the
case, I apologize.

--
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] gsoc, text search selectivity and dllist enhancments

=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <j.urbanski@students.mimuw.edu.pl> writes:
> attached are two patches against HEAD. The smaller one is meant to be
> commited - it adds some functions that manipulate double-linked lists,
> namely inserting a new cell after or before another cell and swapping
> two adjacent cells.

> The gzipped one is WIP for my GSoC project. I've reworked the algorithm
> for determing most common lexemes.

I looked over this a bit. I'm not excited about adding functionality to
Dllist --- that data structure is barely used at all in the backend,
and I think a better case could be made for getting rid of it than
adding code to it. The analyze patch doesn't change my mind on the
point, because I don't think that Dllist is really helping you there
anyway. The data structure I'd suggest is a simple array of pointers
to the underlying hash table entries. Since you have a predetermined
maximum number of lexemes to track, you can just palloc the array once
--- you don't need the expansibility properties of a list. The only
operations you need are "add an entry at the end" (if you keep the
array sorted by descending count not ascending), "remove the end
entry", and "swap adjacent entries", all of which are actually cheaper
on an array than on a Dllist.

Another point is that you don't really need the array to be sorted all
the time. Instead of using what is basically an O(N^2) incremental
sort, you could consider applying qsort() when you do need it to be
sorted, which is at the end or when the table overflows and you need to
discard some entries. If you are willing to discard multiple entries
per overflow event, this could be quite cheap --- although I think in
the worst case where there are many overflows, it'd go back to being
O(N^2). Note BTW that adding a count=1 entry at the end cannot make the
array unsorted if it was sorted before. The only event that renders the
array unsorted is increasing an item's count to more than the count of
its predecessor --- so it might be worth keeping a predecessor pointer
in each hashtable entry that identifies its predecessor as of the time
of the last array sort, so you could check on-the-fly and avoid
unnecessary re-sorts. I'm not totally sure that this idea is a win,
but it seems worth investigating.

Other than that, the analyze patch looked generally sane to me,
and I think you're on the right track. Please rework and resubmit.

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

Posted by at No comments:

Re: [ADMIN] Best way to limit database sizes

On Thu, Jul 03, 2008 at 09:10:47PM +0200, Dimitri Fontaine wrote:

> >I've considered creating a tablespace in a directory owned by the
> >user , so I can use Linux quotas to prevent higher disk usage , but
> >this turned out be a bad thought, as all the files are anyway owned
> >by the postgres user and so disk quotas won't have any effect.
>
> What if you put each tablespace on a LVM partition of a control sized,
> extensible?

This is a desaster waiting to happen. I'd say never let a database get
out of disk space. Rather implement soft limits like regular cron jobs
and make them pay for overusage.

Also note that DB size on disk and amount of data stored in DB might be
a lot different because of bloating issues, indices etc.

Tino..oO(But LVM/tablespace should work.)

--
"What we nourish flourishes." - "Was wir nähren erblüht."

www.craniosacralzentrum.de
www.forteego.de

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

Posted by at No comments:

[GENERAL] xml and postgresql

Hi folks,

             I need to load xml data in to database can you tell me they way how do I import xml data into postgresql database.

lets dat this is the xml file

<bookstore>
<book category="CHILDREN">
  <title>Harry Potter</title> 
  <author>J K. Rowling</author> 
  <year>2005</year> 
  <price>29.99</price> 
</book>
<book category="WEB">
  <title>Learning XML</title> 
  <author>Erik T. Ray</author> 
  <year>2003</year> 
  <price>39.95</price> 
</book>
</bookstore>

so finally the table name should be bookstore and column names are category,title,
author,year,price and all the information in the xml file should be ported to the table 
can you please tell me how to do this its a bit confusing to me as i am just a beginner to 
this.

Thanks in advance,
Aravind.



Posted by at No comments:

Re: [HACKERS] CommitFest rules

On Thu, Jul 3, 2008 at 2:44 PM, Dave Page <dpage@pgadmin.org> wrote:
> it concerns me that despite it being day 3 of the July commit fest,
> people are still being advised to add new items to the wiki page.
>
> To make the idea work, we need to stick to the rules we defined when
> we came up with the concept - specifically, no new patches once the
> fest begins!
>
> So please - new patches to the September page!

One of the two patches added post jul-1 was libpq event hooks, which
was a holdover from the june fest -- it wasn't a 'late breaking
patch', just a procedural oversight. It was put there immediately
after reading the 'did we miss any patches' thread on -hackers. Can't
speak as to the other patch.

merlin

--
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:
Subscribe to: Posts (Atom)