PostgreSQL

EnterpriseDB

http://www.postgresql.org/mailpref/torontopug

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

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

Re: [torontopug] Rolling the ball

All right folks, the post is now up on our page:
http://pugs.postgresql.org/torontopug

Please start passing out this URL, and let's get this group started!
Let me know if you see anything I missed in the post.

Again, if either of you want to have posts on the TorontoPUG site,
send me your account id on the PUG site, and I can add your posts to
the page.

Just in case there's overlap, I'll be adding this event to Facebook,
TorCamp, and the Toronto Ruby Sites.

~Ian

On Wed, Jun 11, 2008 at 11:32 PM, Steve Singer <ssinger_pg@sympatico.ca> wrote:
> On Thu, 12 Jun 2008, [utf-8] Jonathan Fuerth wrote:
>
> Then the Rhino on the 23rd it is. I think 7:30pm is a good start time. It
> gives people time to come from most parts of the city and/or grab dinner. If
> we were meeting in a room and are planning on going to the pub after
> presentations an eariler time might make sense, but that isn't the case.
>
> Steve
>
>> Sounds good. The last thing to decide is start time. For me, 7:00 is about
>> the earliest I can manage. 7:30 would be ideal. If you guys want to start
>> earlier, I can simply show up late! :)
>>
>> Once that's decided, I'll start spreading the word to people I know!
>>
>> -Jonathan
>>
>>
>>
>> -----Original Message-----
>> From: "Ian Bailey" <ian@hardcircle.net>
>>
>> Date: Wed, 11 Jun 2008 23:09:29
>> To:torontopug@postgresql.org
>> Cc:"Jonathan Fuerth" <jonathan@fuerth.ca>,"Steve Singer"
>> <ssinger_pg@sympatico.ca>
>> Subject: Re: [torontopug] Rolling the ball
>>
>>
>> Sorry guys, I've been meaning to send out the e-mails, I've just been
>> caught up with a few things this week.
>>
>> I've called the Rhino already, and they are find with having us on the
>> 23rd. I told them we'd be about 10 people, but they said we can call
>> them the Friday before the weekend if we have crazy turnout, and they
>> can even ask extra servers to come in.
>>
>> I've given a bit of thought about the venue, and I think the Rhino may
>> be a better venue for socialization and light discussion, as it is
>> quite a large place, whereas the Linux Caffe is more conducive to more
>> in-depth discussion, as it's a bit quieter. To get a bit more turn-out
>> initially, I'm favouring the Rhino. Plus, it's on the Queen streetcar
>> line, which makes it a bit more accessible for downtown people. I'm
>> not feeling any strong opposition to the Rhino, but let me know if
>> either of you have strong objections.
>>
>> I have an account on pugs, but if either of you have an account as
>> well, I have the ability to include all of our posts on the TorontoPUG
>> page. I'm writing up a post as we speak, to publish as soon as we
>> agree on the location.
>>
>> ~Ian
>>
>> On Wed, Jun 11, 2008 at 10:46 PM, Steve Singer <ssinger_pg@sympatico.ca>
>> wrote:
>>>
>>> On Wed, 11 Jun 2008, Jonathan Fuerth wrote:
>>>
>>>> Hi everyone,
>>>>
>>>> It's been a bit quiet on the list lately, so I'm just trying to get the
>>>> ball rolling again.
>>>>
>>>> Since the decision to meet on the 4th Monday of each month has some
>>>> research behind it, and there haven't been any objections, I propose we
>>>> adopt that meeting date and resolve to have our first meeting this month
>>>> (June 23).
>>>
>>> +1 to having a meeting on the 23rd.
>>>
>>>>
>>>> As for where, I think all of the options we've heard so far are great.
>>>> If
>>>> I had to narrow down my vote to 2 choices, I would choose The Rhino
>>>> (because
>>>> it was Ian's first suggestion) and the Linux Cafe (because it's been
>>>> suggested several times). If I were forced to narrow it down further,
>>>> I'd
>>>> just call both places and see which can accommodate a group on June 23.
>>>> :)
>>>
>>> I'm of a similar view? If anyone (Ian?) has strong feelings for one or
>>> the
>>> other they should feel free to volunteer to call their preferred spot.
>>>
>>> Also, does someone have access to post events on the
>>> pubs.postgres.org/torontopug blog?
>>>
>>>
>>>
>>>>
>>>> Best regards,
>>>>
>>>> -Jonathan
>>
>> --
>> Sent via torontopug mailing list (torontopug@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/torontopug
>>
>>
>
>

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

Re: [pgsql-es-ayuda] INCREMENTAR EL VALOR DE UNA PARTE DE UNA COLUMNA DE UNA TABALA ESPECIFICA

On Wed, Jun 11, 2008 at 10:13 PM, Ricardo Granados Tiznado
<ricardo@solargi.net> wrote:
> Estoy utilizando un erp basado en postgresql en donde es necesario
> cambiar una grupo de datos pertenecientes a un columna especifica.
>
> En la red encontré estos datos:
>
>
> UPDATE parts
> SET sellprice = (sellprice * 1.10)
> WHERE partsgroup_id =091221
>
> Lo que no entiendo es si primero va la tercer sentencia ya que primero
> me actualizaria todos los datos en sellprice.

Lo que hace es primero filtrar la tabla, obteniendo aquellos registros
que satisfacen la condición de la cláusula WHERE.
http://www.postgresql.org/docs/8.3/static/sql-update.html
>
>
> ¿ esto se puede lograr mediante phppgadmin u otro programa ?.
>
Si, puedes ejecutar el UPDATE desde phppgadmin, tambien puedes usar el psql.
>
>
> saludos.
>
>
>
> --
> Ricardo Granados Tiznado
> --
> TIP 7: no olvides aumentar la configuración del "free space map"
>

--
:: God bless you, every day and every night ::
--
TIP 2: puedes desuscribirte de todas las listas simultáneamente
(envía "unregister TuDirecciónDeCorreo" a majordomo@postgresql.org)

Re: [pgsql-www] Proposal: pulling newsbytes from www.pgfoundry.org

On Wed, 2008-06-11 at 20:16 -0700, Josh Berkus wrote:
> > The other concern that I have is that this gives even less face time to core
> > project related news, which already has a hard time getting exposure. Things
> > like minor releases, project events (beta/gsoc), and large community
> > gatherings (oscon/pgcon) get at best limited exposure and that's if aren't
> > just lumped in with everything else.
> >
>
> What if we merge them with the blog stream, then?

That would be reasonable if we could get some kind of ATOM output. We
already give a lot of space to planet.

Joshua D. Drake

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

Re: [torontopug] Rolling the ball

On Thu, 12 Jun 2008, [utf-8] Jonathan Fuerth wrote:

Then the Rhino on the 23rd it is. I think 7:30pm is a good start time.
It gives people time to come from most parts of the city and/or grab dinner.
If we were meeting in a room and are planning on
going to the pub after presentations an eariler time might make sense, but
that isn't the case.

Steve

> Sounds good. The last thing to decide is start time. For me, 7:00 is about
> the earliest I can manage. 7:30 would be ideal. If you guys want to start
> earlier, I can simply show up late! :)
>
> Once that's decided, I'll start spreading the word to people I know!
>
> -Jonathan
>
>
>
> -----Original Message-----
> From: "Ian Bailey" <ian@hardcircle.net>
>
> Date: Wed, 11 Jun 2008 23:09:29
> To:torontopug@postgresql.org
> Cc:"Jonathan Fuerth" <jonathan@fuerth.ca>,"Steve Singer" <ssinger_pg@sympatico.ca>
> Subject: Re: [torontopug] Rolling the ball
>
>
> Sorry guys, I've been meaning to send out the e-mails, I've just been
> caught up with a few things this week.
>
> I've called the Rhino already, and they are find with having us on the
> 23rd. I told them we'd be about 10 people, but they said we can call
> them the Friday before the weekend if we have crazy turnout, and they
> can even ask extra servers to come in.
>
> I've given a bit of thought about the venue, and I think the Rhino may
> be a better venue for socialization and light discussion, as it is
> quite a large place, whereas the Linux Caffe is more conducive to more
> in-depth discussion, as it's a bit quieter. To get a bit more turn-out
> initially, I'm favouring the Rhino. Plus, it's on the Queen streetcar
> line, which makes it a bit more accessible for downtown people. I'm
> not feeling any strong opposition to the Rhino, but let me know if
> either of you have strong objections.
>
> I have an account on pugs, but if either of you have an account as
> well, I have the ability to include all of our posts on the TorontoPUG
> page. I'm writing up a post as we speak, to publish as soon as we
> agree on the location.
>
> ~Ian
>
> On Wed, Jun 11, 2008 at 10:46 PM, Steve Singer <ssinger_pg@sympatico.ca> wrote:
>> On Wed, 11 Jun 2008, Jonathan Fuerth wrote:
>>
>>> Hi everyone,
>>>
>>> It's been a bit quiet on the list lately, so I'm just trying to get the
>>> ball rolling again.
>>>
>>> Since the decision to meet on the 4th Monday of each month has some
>>> research behind it, and there haven't been any objections, I propose we
>>> adopt that meeting date and resolve to have our first meeting this month
>>> (June 23).
>>
>> +1 to having a meeting on the 23rd.
>>
>>>
>>> As for where, I think all of the options we've heard so far are great. If
>>> I had to narrow down my vote to 2 choices, I would choose The Rhino (because
>>> it was Ian's first suggestion) and the Linux Cafe (because it's been
>>> suggested several times). If I were forced to narrow it down further, I'd
>>> just call both places and see which can accommodate a group on June 23. :)
>>
>> I'm of a similar view? If anyone (Ian?) has strong feelings for one or the
>> other they should feel free to volunteer to call their preferred spot.
>>
>> Also, does someone have access to post events on the
>> pubs.postgres.org/torontopug blog?
>>
>>
>>
>>>
>>> Best regards,
>>>
>>> -Jonathan
>
> --
> Sent via torontopug mailing list (torontopug@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/torontopug
>
>

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

Re: [pgsql-es-ayuda] llamadas dinamicas

On Wed, Jun 11, 2008 at 10:14 PM, Gerardo Gonzalez
<gergonvel@hotmail.com> wrote:
>
> Te agradezco Julio;
>
> Me surge otra duda y como sería la formacion de l execute si la funcion a la que
> se llama devuelve un valor.

execute 'select cadena_funcion( )' into valor;

>
> Atte.,
> Gerardo
>
> ----------------------------------------
>> Date: Wed, 11 Jun 2008 20:38:24 -0500
>> From: jurasec@gmail.com
>> To: gergonvel@hotmail.com
>> Subject: Re: [pgsql-es-ayuda] llamadas dinamicas
>> CC: pgsql-es-ayuda@postgresql.org
>>
>> 2008/6/11 Gerardo Gonzalez :
>>> hola lista.. me pueden ayudar. como se puede hacer una funcion que llame a
>>> otra funcion pero de forma dinamica., es decir, tengo una tabla q tiene la
>>> sigte estructura: create table funciones ( orden int , funcion varchar(25) )
>>> con los siguientes datos orden | Funcion --------------------- 1 | funcion1
>>> 2 | funcion2 y lo que necesito es crear una funcion q pueda ejecutar las
>>> funciones que se indican en la tabla en el ordenque se indican. Les
>>> agredezco su ayuda. gracias. atte., Gerardo.
>>
>> Puedes usar execute dentro de un pl/pgSql, con esta puedes ir armando
>> tu llamada con la cadena que consultes de la tabla de funciones.
>>
>> Por ejemplo:
>>
>> select into cadena_funcion funcion from funciones where .... ;
>>
>> execute cadena_funcion||'('||parametro||')';
>>
>>> ________________________________
>>> Ingresa ya a MSN en Concierto y disfruta los recitales en vivo de tus
>>> artistas favoritos. MSN en Concierto
>>
>>
>>
>> --
>> :: God bless you, every day and every night ::
>> --
>> TIP 5: ¿Has leído nuestro extenso FAQ?
>>

http://www.postgresql.org/docs/faqs.FAQ.html
>
> _________________________________________________________________
> ¿Aburrido? Ingresa ya y diviertete como nunca en MSN Juegos.
> http://juegos.cl.msn.com/

--
:: God bless you, every day and every night ::
--
TIP 8: explain analyze es tu amigo

Re: [pgsql-es-ayuda] AYUDA CONECTIVIDAD LAN

2008/6/11 Noel Martínez Juárez <noelius79@hotmail.com>:
> Muchas gracias, por tu información, ya he configurado los archivos *.CONF
> para la conexion pero no logro establecer comunicación, tambien he checado
> mi conexion LAN y esta en orden, por ODBC si puedo acceder
> localmente,gracias.
>
> NOEL
>
En que S.O. esta el servidor?.
Podrias poner la configuración que utilizaste del pg_hba.confpg_?

> ________________________________
>> Date: Wed, 11 Jun 2008 21:24:42 -0500
>> From: jurasec@gmail.com
>> To: noelius79@hotmail.com
>> Subject: Re: [pgsql-es-ayuda] AYUDA CONECTIVIDAD LAN
>> CC: pgsql-es-ayuda@postgresql.org
>>
>> On Wed, Jun 11, 2008 at 8:18 PM, Noel Martínez Juárez
>> <noelius79@hotmail.com> wrote:
>> > Q tal?, me interesa colocar un servidor(192.168.1.100) con POSTGRESQL en
>> > una
>> > red LAN, que archivos son los que tengo que configurar para enlazarme
>> > por
>> > ODBC desde otra pc en la misma red(ya tengo el driver instalado) a mi
>> > base
>> > de datos considerando que tengo la versión 8.3, GRACIAS
>> >
>> > NOEL
>> > _____________
>>
>> Deberias revisar los archivos de la lista, ya se ha tocado este tema,
>> pero aca te dejo, unos links:
>> http://www.postgresql.org/docs/8.3/static/client-authentication.html
>> http://www.postgresql.org/docs/8.3/static/runtime-config-connection.html
>>
>>
>> ___________________
>> > ¿Tus fotos son un desorden? La solución a tus males se llama Galería
>> > fotográfica de Windows Live
>>
>>
>>
>> --
>> :: God bless you, every day and every night ::
>> --
>> TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?
>> http://archives.postgresql.org/pgsql-es-ayuda
>
> ________________________________
> ¿Tienes cámara digital, más de una cuenta de email, planeas fiestas o
> blogueas? Entonces, necesitas Windows Live

--
:: God bless you, every day and every night ::
--
TIP 7: no olvides aumentar la configuración del "free space map"

Re: [torontopug] Rolling the ball

Sounds good. The last thing to decide is start time. For me, 7:00 is about the earliest I can manage. 7:30 would be ideal. If you guys want to start earlier, I can simply show up late! :)

Once that's decided, I'll start spreading the word to people I know!

-Jonathan

-----Original Message-----
From: "Ian Bailey" <ian@hardcircle.net>

Date: Wed, 11 Jun 2008 23:09:29
To:torontopug@postgresql.org
Cc:"Jonathan Fuerth" <jonathan@fuerth.ca>,"Steve Singer" <ssinger_pg@sympatico.ca>
Subject: Re: [torontopug] Rolling the ball

Sorry guys, I've been meaning to send out the e-mails, I've just been
caught up with a few things this week.

I've called the Rhino already, and they are find with having us on the
23rd. I told them we'd be about 10 people, but they said we can call
them the Friday before the weekend if we have crazy turnout, and they
can even ask extra servers to come in.

I've given a bit of thought about the venue, and I think the Rhino may
be a better venue for socialization and light discussion, as it is
quite a large place, whereas the Linux Caffe is more conducive to more
in-depth discussion, as it's a bit quieter. To get a bit more turn-out
initially, I'm favouring the Rhino. Plus, it's on the Queen streetcar
line, which makes it a bit more accessible for downtown people. I'm
not feeling any strong opposition to the Rhino, but let me know if
either of you have strong objections.

I have an account on pugs, but if either of you have an account as
well, I have the ability to include all of our posts on the TorontoPUG
page. I'm writing up a post as we speak, to publish as soon as we
agree on the location.

~Ian

On Wed, Jun 11, 2008 at 10:46 PM, Steve Singer <ssinger_pg@sympatico.ca> wrote:
> On Wed, 11 Jun 2008, Jonathan Fuerth wrote:
>
>> Hi everyone,
>>
>> It's been a bit quiet on the list lately, so I'm just trying to get the
>> ball rolling again.
>>
>> Since the decision to meet on the 4th Monday of each month has some
>> research behind it, and there haven't been any objections, I propose we
>> adopt that meeting date and resolve to have our first meeting this month
>> (June 23).
>
> +1 to having a meeting on the 23rd.
>
>>
>> As for where, I think all of the options we've heard so far are great. If
>> I had to narrow down my vote to 2 choices, I would choose The Rhino (because
>> it was Ian's first suggestion) and the Linux Cafe (because it's been
>> suggested several times). If I were forced to narrow it down further, I'd
>> just call both places and see which can accommodate a group on June 23. :)
>
> I'm of a similar view? If anyone (Ian?) has strong feelings for one or the
> other they should feel free to volunteer to call their preferred spot.
>
> Also, does someone have access to post events on the
> pubs.postgres.org/torontopug blog?
>
>
>
>>
>> Best regards,
>>
>> -Jonathan

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

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

RE: [pgsql-es-ayuda] AYUDA CONECTIVIDAD LAN

Muchas gracias, por tu información, ya he configurado los archivos *.CONF para la conexion pero no logro establecer comunicación, tambien he checado mi conexion LAN y esta en orden, por ODBC si puedo acceder localmente,gracias.

NOEL

> Date: Wed, 11 Jun 2008 21:24:42 -0500
> From: jurasec@gmail.com
> To: noelius79@hotmail.com
> Subject: Re: [pgsql-es-ayuda] AYUDA CONECTIVIDAD LAN
> CC: pgsql-es-ayuda@postgresql.org
>
> On Wed, Jun 11, 2008 at 8:18 PM, Noel Martínez Juárez
> <noelius79@hotmail.com> wrote:
> > Q tal?, me interesa colocar un servidor(192.168.1.100) con POSTGRESQL en una
> > red LAN, que archivos son los que tengo que configurar para enlazarme por
> > ODBC desde otra pc en la misma red(ya tengo el driver instalado) a mi base
> > de datos considerando que tengo la versión 8.3, GRACIAS
> >
> > NOEL
> > _____________
>
> Deberias revisar los archivos de la lista, ya se ha tocado este tema,
> pero aca te dejo, unos links:
> http://www.postgresql.org/docs/8.3/static/client-authentication.html
> http://www.postgresql.org/docs/8.3/static/runtime-config-connection.html
>
>
> ___________________
> > ¿Tus fotos son un desorden? La solución a tus males se llama Galería
> > fotográfica de Windows Live
>
>
>
> --
> :: God bless you, every day and every night ::
> --
> TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?
> http://archives.postgresql.org/pgsql-es-ayuda

¿Tienes cámara digital, más de una cuenta de email, planeas fiestas o blogueas? Entonces, necesitas Windows Live

Re: [pgsql-www] Proposal: pulling newsbytes from www.pgfoundry.org

On Wed, 2008-06-11 at 22:58 -0400, Robert Treat wrote:
> On Tuesday 10 June 2008 03:58:40 Dave Page wrote:
> > I'm not convinced that merging them is such a hot idea anyway. It will
> > likely seriously reduce the amount of time any announcement gets front
> > page time which will in turn reduce the usefulness of the section.
> > Further, we then have a potential problem ensuring we don't get
> > duplicate items when one gets approved on www and subsequently on
> > pgFoundry. That of course, applies whether we merge the feed with the
> > existing news, or add it as a new section (ignoring the layout issues
> > that would involve!)
> >
>
> The other concern that I have is that this gives even less face time to core
> project related news, which already has a hard time getting exposure. Things
> like minor releases, project events (beta/gsoc), and large community
> gatherings (oscon/pgcon) get at best limited exposure and that's if aren't
> just lumped in with everything else.

OSCON and PGCON are responsible for their own promotion. As pgfoundry is
an official PostgreSQL supported project, it deserves more face time
than either of those two. One option would be to have:

PostgreSQL News
* Core
* PgFoundry
* Releases

Related News
* OSCON
* PgCon
* West
* East

etc...

Sincerely,

Joshua D. Drake

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

Re: [pgsql-www] Proposal: pulling newsbytes from www.pgfoundry.org

> The other concern that I have is that this gives even less face time to core
> project related news, which already has a hard time getting exposure. Things
> like minor releases, project events (beta/gsoc), and large community
> gatherings (oscon/pgcon) get at best limited exposure and that's if aren't
> just lumped in with everything else.
>

What if we merge them with the blog stream, then?

--Josh

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

RE: [pgsql-es-ayuda] llamadas dinamicas

Te agradezco Julio;

Me surge otra duda y como sería la formacion de l execute si la funcion a la que
se llama devuelve un valor.

Atte.,
Gerardo

----------------------------------------
> Date: Wed, 11 Jun 2008 20:38:24 -0500
> From: jurasec@gmail.com
> To: gergonvel@hotmail.com
> Subject: Re: [pgsql-es-ayuda] llamadas dinamicas
> CC: pgsql-es-ayuda@postgresql.org
>
> 2008/6/11 Gerardo Gonzalez :
>> hola lista.. me pueden ayudar. como se puede hacer una funcion que llame a
>> otra funcion pero de forma dinamica., es decir, tengo una tabla q tiene la
>> sigte estructura: create table funciones ( orden int , funcion varchar(25) )
>> con los siguientes datos orden | Funcion --------------------- 1 | funcion1
>> 2 | funcion2 y lo que necesito es crear una funcion q pueda ejecutar las
>> funciones que se indican en la tabla en el ordenque se indican. Les
>> agredezco su ayuda. gracias. atte., Gerardo.
>
> Puedes usar execute dentro de un pl/pgSql, con esta puedes ir armando
> tu llamada con la cadena que consultes de la tabla de funciones.
>
> Por ejemplo:
>
> select into cadena_funcion funcion from funciones where .... ;
>
> execute cadena_funcion||'('||parametro||')';
>
>> ________________________________
>> Ingresa ya a MSN en Concierto y disfruta los recitales en vivo de tus
>> artistas favoritos. MSN en Concierto
>
>
>
> --
> :: God bless you, every day and every night ::
> --
> TIP 5: ¿Has leído nuestro extenso FAQ?
>

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

_________________________________________________________________
¿Aburrido? Ingresa ya y diviertete como nunca en MSN Juegos.
http://juegos.cl.msn.com/--
TIP 10: no uses HTML en tu pregunta, seguro que quien responda no podrá leerlo

[pgsql-es-ayuda] INCREMENTAR EL VALOR DE UNA PARTE DE UNA COLUMNA DE UNA TABALA ESPECIFICA

Estoy utilizando un erp basado en postgresql en donde es necesario
cambiar una grupo de datos pertenecientes a un columna especifica.

En la red encontré estos datos:

UPDATE parts
SET sellprice = (sellprice * 1.10)
WHERE partsgroup_id =091221

Lo que no entiendo es si primero va la tercer sentencia ya que primero
me actualizaria todos los datos en sellprice.

¿ esto se puede lograr mediante phppgadmin u otro programa ?.

saludos.

--
Ricardo Granados Tiznado
--
TIP 7: no olvides aumentar la configuración del "free space map"

Re: [torontopug] Rolling the ball

Sorry guys, I've been meaning to send out the e-mails, I've just been
caught up with a few things this week.

I've called the Rhino already, and they are find with having us on the
23rd. I told them we'd be about 10 people, but they said we can call
them the Friday before the weekend if we have crazy turnout, and they
can even ask extra servers to come in.

I've given a bit of thought about the venue, and I think the Rhino may
be a better venue for socialization and light discussion, as it is
quite a large place, whereas the Linux Caffe is more conducive to more
in-depth discussion, as it's a bit quieter. To get a bit more turn-out
initially, I'm favouring the Rhino. Plus, it's on the Queen streetcar
line, which makes it a bit more accessible for downtown people. I'm
not feeling any strong opposition to the Rhino, but let me know if
either of you have strong objections.

I have an account on pugs, but if either of you have an account as
well, I have the ability to include all of our posts on the TorontoPUG
page. I'm writing up a post as we speak, to publish as soon as we
agree on the location.

~Ian

On Wed, Jun 11, 2008 at 10:46 PM, Steve Singer <ssinger_pg@sympatico.ca> wrote:
> On Wed, 11 Jun 2008, Jonathan Fuerth wrote:
>
>> Hi everyone,
>>
>> It's been a bit quiet on the list lately, so I'm just trying to get the
>> ball rolling again.
>>
>> Since the decision to meet on the 4th Monday of each month has some
>> research behind it, and there haven't been any objections, I propose we
>> adopt that meeting date and resolve to have our first meeting this month
>> (June 23).
>
> +1 to having a meeting on the 23rd.
>
>>
>> As for where, I think all of the options we've heard so far are great. If
>> I had to narrow down my vote to 2 choices, I would choose The Rhino (because
>> it was Ian's first suggestion) and the Linux Cafe (because it's been
>> suggested several times). If I were forced to narrow it down further, I'd
>> just call both places and see which can accommodate a group on June 23. :)
>
> I'm of a similar view? If anyone (Ian?) has strong feelings for one or the
> other they should feel free to volunteer to call their preferred spot.
>
> Also, does someone have access to post events on the
> pubs.postgres.org/torontopug blog?
>
>
>
>>
>> Best regards,
>>
>> -Jonathan

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

Re: [pgsql-www] Proposal: pulling newsbytes from www.pgfoundry.org

On Tuesday 10 June 2008 03:58:40 Dave Page wrote:
> I'm not convinced that merging them is such a hot idea anyway. It will
> likely seriously reduce the amount of time any announcement gets front
> page time which will in turn reduce the usefulness of the section.
> Further, we then have a potential problem ensuring we don't get
> duplicate items when one gets approved on www and subsequently on
> pgFoundry. That of course, applies whether we merge the feed with the
> existing news, or add it as a new section (ignoring the layout issues
> that would involve!)
>

The other concern that I have is that this gives even less face time to core
project related news, which already has a hard time getting exposure. Things
like minor releases, project events (beta/gsoc), and large community
gatherings (oscon/pgcon) get at best limited exposure and that's if aren't
just lumped in with everything else.

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

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

Re: [torontopug] Rolling the ball

On Wed, 11 Jun 2008, Jonathan Fuerth wrote:

> Hi everyone,
>
> It's been a bit quiet on the list lately, so I'm just trying to get the
> ball rolling again.
>
> Since the decision to meet on the 4th Monday of each month has some
> research behind it, and there haven't been any objections, I propose we
> adopt that meeting date and resolve to have our first meeting this month
> (June 23).

+1 to having a meeting on the 23rd.

>
> As for where, I think all of the options we've heard so far are great. If
> I had to narrow down my vote to 2 choices, I would choose The Rhino
> (because it was Ian's first suggestion) and the Linux Cafe (because it's
> been suggested several times). If I were forced to narrow it down further,
> I'd just call both places and see which can accommodate a group on June
> 23. :)

I'm of a similar view? If anyone (Ian?) has strong feelings for one or the
other they should feel free to volunteer to call their preferred spot.

Also, does someone have access to post events on the
pubs.postgres.org/torontopug blog?

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

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

Re: [HACKERS] Overhauling GUCS

Greg Smith wrote:
> On Wed, 11 Jun 2008, Tom Lane wrote:
>
> > Who said anything about loops? What I am talking about is what happens
> > during
> > set memory_usage = X; // implicitly sets work_mem = X/100, say
> > set work_mem = Y;
> > set memory_usage = Z;
> > What is work_mem now, and what's your excuse for saying so, and how
> > will you document the behavior so that users can understand it?
> > (Just to make things interesting, assume that some of the above SETs
> > happen via changing postgresql.conf rather than directly.)
>
> People are already exposed to issues in this area via things like the
> include file mechanism. You can think of that two ways. You can say,
> "there's already problems like this so who cares if there's another one".
> Or, you can say "let's not add even more confusion like that".
>
> Having a mini programming language for setting parameters is interesting
> and all, and it might be enough to do a good job of handling the basic
> newbie setup chores. But I don't think it's a complete solution and
> therefore I find moving in that direction a bit of a distraction; your
> concerns about ambiguity just amplify that feeling. It's unlikely that
> will get powerful enough to enable the "one true config file" that just
> works for everybody. There's too many things that depend a bit on both
> data access pattern and on overall database size/structure no matter what
> you do.

You are right that the complete solution is going to have to ask users
questions, and my idea of using variables is not going to get us that
far.

--
Bruce Momjian <bruce@momjian.us>

EnterpriseDB

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

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

Re: [HACKERS] Overhauling GUCS

Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Tom Lane wrote:
> >> The idea has a fundamental logical flaw, which is that it's not clear
> >> which parameter wins if the user changes both.
>
> > Yes, you could get into problems by having variable dependency loops,
>
> Who said anything about loops? What I am talking about is what happens
> during
> set memory_usage = X; // implicitly sets work_mem = X/100, say
> set work_mem = Y;
> set memory_usage = Z;

My initial thought was that this would behave like a shell script
variable, meaning once you set something it would affect all references
to it below in postgresql.conf. The problem with that is that we
comment out all settings, so there isn't a logical order like you would
have in a shell script.

I was not thinking of memory_usage implicity changing anything. I
figured postgresql.conf would have:

memory_usage = 100
work_mem = $memory_usage * 0.75

If you change memory_usage via SET, it will not change work_mem at all
because you are not re-initializing the variables.

I am kind of lost how this would work logically and am willing to think
about it some more, but I do think we aren't going to simplify
postgresql.conf without such a facility.

The big problem I see is that right now everything has a constant
default. If we allowed memory_usage to change some of the defaults, how
would we signal that we want the variables based on it to change their
values? This is your behind-the-scenes problem you mentioned.

> What is work_mem now, and what's your excuse for saying so, and how
> will you document the behavior so that users can understand it?
> (Just to make things interesting, assume that some of the above SETs
> happen via changing postgresql.conf rather than directly.)
>
> If the objective is to make configuration easier to understand,
> I don't believe that behind-the-scenes changes of configuration values
> will advance that goal.
>
> > but I see no way to easily improve configuration without it.
>
> The higher-level concepts should be things that a configuration wizard
> works with, and then tells you how to set the postmaster parameters.
> They should not end up in the configure file (unless maybe as comments?)

I am concerned that each wizzard is going to have to duplicate the same
logic each time, and adjust to release-based changes. I thought having
the configuration file itself help with setting some values would be
helpful.

--
Bruce Momjian <bruce@momjian.us>

EnterpriseDB

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

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

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

Re: [pgsql-es-ayuda] AYUDA CONECTIVIDAD LAN

On Wed, Jun 11, 2008 at 8:18 PM, Noel Martínez Juárez
<noelius79@hotmail.com> wrote:
> Q tal?, me interesa colocar un servidor(192.168.1.100) con POSTGRESQL en una
> red LAN, que archivos son los que tengo que configurar para enlazarme por
> ODBC desde otra pc en la misma red(ya tengo el driver instalado) a mi base
> de datos considerando que tengo la versión 8.3, GRACIAS
>
> NOEL
> _____________

Deberias revisar los archivos de la lista, ya se ha tocado este tema,
pero aca te dejo, unos links:
http://www.postgresql.org/docs/8.3/static/client-authentication.html
http://www.postgresql.org/docs/8.3/static/runtime-config-connection.html

___________________
> ¿Tus fotos son un desorden? La solución a tus males se llama Galería
> fotográfica de Windows Live

--
:: God bless you, every day and every night ::
--
TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?

Re: [HACKERS] .psqlrc output for \pset commands

Gregory Stark <stark@enterprisedb.com> writes:
> Anyways the thing that struck me as odd was the messages appearing *before*
> the header. It seems to me the header should print followed by .psqlrc output
> followed by normal output.

I think the reason for the current behavior is to allow \set QUIET in
.psqlrc to affect the printing of the banner. Are we prepared to
give that up?

regards, tom lane

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

Re: [GENERAL] Unable to dump database using pg_dump

Adam Dear <adear@usnx.net> writes:
> madisoncounty=# select ctid,xmin,xmax,cmin,cmax,usename from pg_shadow;
> ctid | xmin | xmax | cmin | cmax | usename
> -------+------+------+------+------+---------------
> (0,1) | 1 | 596 | 596 | 1 | postgres
> (0,2) | 2 | 1 | 1 | 0 | postgres
> (0,5) | 2 | 0 | 0 | 0 | madisoncounty
> (3 rows)

Hm, I thought you deleted the (0,2) tuple ... did you restore a physical
backup or something?

Anyway, as far as I can see the way that you got into this state must
have been

1. The (0,1) tuple must have been the one originally inserted by initdb;
there's no other way it could have xmin=1.

2. Shortly after initdb (at transaction 596 to be exact) this tuple was
updated --- probably by a password-assignment operation --- creating the
tuple at (0,2), which must originally have had xmin = 596, cmin = 1 (the
xmax overlays cmin in 7.4, so we can assume that column value is bogus).

3. Much time passes, and pg_shadow never gets vacuumed so the dead
tuple at (0,1) is never cleaned up. Eventually the XID counter passes 2
billion + 596, and suddenly transaction 596 appears to be in the future,
so the tuple at (0,1) starts to be seen by SELECTs again.

4. At this point you ran VACUUM FREEZE, which replaced the xmins of the
second and third tuples with 2 (FrozenTransactionId) ... but 7.4 does
not think it could ever need to freeze xmax, and at this point VACUUM
wouldn't touch the (0,1) tuple anyway because it considers the tuple as
RECENTLY_DEAD.

So VACUUM won't help you, at least not for another 2 billion
transactions. And the DELETE doesn't work either because it correctly
perceives (0,1) as an updated tuple that's been superseded by (0,2),
which doesn't meet the WHERE clause so DELETE doesn't touch it.
You could delete (0,2) but that leaves you with no working postgres user
(since the system's SnapshotNow rules consider (0,1) as dead), and if
you create another one you're back to having 2 entries in pg_shadow.
Nasty :-(

I can't think of any way out of this using plain 7.4 SQL operations.
You could maybe hack a special case into VACUUM to make it nuke the
dead tuple, but what's probably going to be easier is to manipulate the
data on disk. Are you comfortable enough with editing binary data
to find the "596" and replace it with "2"? It'd be somewhere near
the end of the first (and probably only) block of pg_shadow, and a
few bytes before one of the occurrences of the string "postgres".
BTW, pg_shadow is $PGDATA/global/1260.

(If you try this, do the editing while the postmaster is stopped,
else you might have problems with it buffering the old data.)

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: [GENERAL] Determining offsets to jump to grab a group of records

On Wed, Jun 11, 2008 at 4:39 PM, David Lambert <davidl@dmisoft.com> wrote:
>
> We have already looked into using CURSORS but they must be within a
> transaction and we could have many of these grids open at any given time
> looking at different tables.
>
> So the end result is that we are trying to give users the freedom to go
> through their data in a grid like fashion with seeking and positioning.
>
> We have used direct WHERE clauses in our asp.net applications but we wanted
> the desktop application to be a little bit more responsive and easy to use.
>
> Is there a better way to approach this?

Yes there is. Use an indexed id field of some kind.

select * from table where idfield between 0 and 100;
select * from table where idfield between 1000000 and 1000100;

Will both be equally fast. Offset / limit syntax requires the db to
materialize <offset>+<limit> rows for the query. between and an id
does not.

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

Re: [HACKERS] Overhauling GUCS

On Wed, 11 Jun 2008, Tom Lane wrote:

> Who said anything about loops? What I am talking about is what happens
> during
> set memory_usage = X; // implicitly sets work_mem = X/100, say
> set work_mem = Y;
> set memory_usage = Z;
> What is work_mem now, and what's your excuse for saying so, and how
> will you document the behavior so that users can understand it?
> (Just to make things interesting, assume that some of the above SETs
> happen via changing postgresql.conf rather than directly.)

People are already exposed to issues in this area via things like the
include file mechanism. You can think of that two ways. You can say,
"there's already problems like this so who cares if there's another one".
Or, you can say "let's not add even more confusion like that".

Having a mini programming language for setting parameters is interesting
and all, and it might be enough to do a good job of handling the basic
newbie setup chores. But I don't think it's a complete solution and
therefore I find moving in that direction a bit of a distraction; your
concerns about ambiguity just amplify that feeling. It's unlikely that
will get powerful enough to enable the "one true config file" that just
works for everybody. There's too many things that depend a bit on both
data access pattern and on overall database size/structure no matter what
you do.

[If only there were some technology that did workload profiling and set
the server parameters based on that. Some sort of dynamic tuning tool;
wouldn't that be great? Oh well, that's just a dream right now I guess.]

I'm not sure if I've stated this explicitly yet, but I personally have no
interest in just solving the newbie problem. I want a tool to help out
tuning medium to large installs, and generating a simple config file is
absolutely something that should come out of that as a bonus. Anything
that just targets the simple installs, though, I'm not very motivated to
chase after.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD

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

[PERFORM] 8.3.1 vs 8.2.X on HP-UX PA-RISC 11.11/11.23

We run GCC-compiled postgresql on a number
of HP-UX and Linux boxes.

Our measurements to date show 8.3.1
performance to be about 30% *worse*
than 8.2 on HP-UX for the same "drink the firehose"
insert/update/delete benchmarks. Linux
performance is fine.

Tweaking the new 8.3.1 synchronous_commit
and bg writer delays that *should* speed
things up actually makes them a bit worse,
again only on HP-UX PA-RISK 11.11 and 11.23.

Right now it's 32 bit, both for 8.2 and 8.3.

Any hints?

P. J. Rovero

--
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-es-ayuda] llamadas dinamicas

2008/6/11 Gerardo Gonzalez <gergonvel@hotmail.com>:
> hola lista.. me pueden ayudar. como se puede hacer una funcion que llame a
> otra funcion pero de forma dinamica., es decir, tengo una tabla q tiene la
> sigte estructura: create table funciones ( orden int , funcion varchar(25) )
> con los siguientes datos orden | Funcion --------------------- 1 | funcion1
> 2 | funcion2 y lo que necesito es crear una funcion q pueda ejecutar las
> funciones que se indican en la tabla en el ordenque se indican. Les
> agredezco su ayuda. gracias. atte., Gerardo.

Puedes usar execute dentro de un pl/pgSql, con esta puedes ir armando
tu llamada con la cadena que consultes de la tabla de funciones.

Por ejemplo:

select into cadena_funcion funcion from funciones where .... ;

execute cadena_funcion||'('||parametro||')';

> ________________________________
> Ingresa ya a MSN en Concierto y disfruta los recitales en vivo de tus
> artistas favoritos. MSN en Concierto

--
:: God bless you, every day and every night ::
--
TIP 5: ¿Has leído nuestro extenso FAQ?

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

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

Gregory Stark wrote:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>
> > (Likely counterexample: adding collation info to text values.)
>
> I don't think the argument really needs an example, but I
> would be pretty
> upset if we proposed tagging every text datum with a
> collation. Encoding
> perhaps, though that seems like a bad idea to me on
> performance grounds, but
> collation is not a property of the data at all.

Again not directly related to difficulties upgrading pages...

The recent discussion ...
http://archives.postgresql.org/pgsql-hackers/2008-06/msg00102.php
... mentions keeping collation information together with text data,
however it is referring to keeping it together when processing it,
not when storing the text.

Regards,
Stephen Denne.
--
At the Datamail Group we value teamwork, respect, achievement, client focus, and courage.
This email with any attachments is confidential and may be subject to legal privilege.
If it is not intended for you please advise by replying immediately, destroy it and do not
copy, disclose or use it in any way.

The Datamail Group, through our GoGreen programme, is committed to environmental sustainability.
Help us in our efforts by not printing this email.
__________________________________________________________________
This email has been scanned by the DMZGlobal Business Quality
Electronic Messaging Suite.
Please see http://www.dmzglobal.com/dmzmessaging.htm for details.
__________________________________________________________________

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

Re: [JDBC] Populating large tables with occasional bad values

Craig Ringer wrote:
> John T. Dow wrote:
>
>> If I did this regularly, three options seem easiest.
>>
>> 1 - Load locally to get clean data and then COPY. This requires the
>> server to have access local access to the file to be copied, and if
>> the server is hosted by an isp, it depends on them whether you can do
>> this easily.
>
> You can COPY over a PostgreSQL network connection. See the \copy support
> in psql for one example of how it works.
>
> I've never had cause to try to use it with JDBC so I don't know how/if
> it works in that context.

It's not supported in the standard JDBC driver unfortunately.

> However, batched inserts can be quite fast enough. If you do one INSERT
> INTO per 1000 rows you'll already be seeing a massive performance boost:
>
> INSERT INTO mytable
> VALUES
> (blah, blah),
> (blah, blah),
> (blah, blah),
> -- hundreds of rows later
> (blah, blah);
>
> ... will be a *LOT* faster. If you have to do special processing or
> error handling you can do it once you have the data in a server-side
> staging table - and you can get it there quickly with multi-row inserts
> or (at least using psql) a \copy .

You can get the same effect via JDBC batched inserts (addBatch() /
executeBatch()) without having to actually do a multi-row INSERT
statement. That's probably the most portable approach if you're using JDBC.

-O

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

[pgsql-es-ayuda] AYUDA CONECTIVIDAD LAN

Q tal?, me interesa colocar un servidor(192.168.1.100) con POSTGRESQL en una red LAN, que archivos son los que tengo que configurar para enlazarme por ODBC desde otra pc en la misma red(ya tengo el driver instalado) a mi base de datos considerando que tengo la versión 8.3, GRACIAS

NOEL

¿Tus fotos son un desorden? La solución a tus males se llama Galería fotográfica de Windows Live

Re: [HACKERS] cannot use result of (insert..returning)

Bruce Momjian wrote:
> Heikki Linnakangas wrote:
>
>> dvs wrote:
>>
>>> Hello,
>>>
>>> I need to use query like:
>>> select (insert into test (a) values (x) returning b),c from anytable
>>> where condition
>>> but it say
>>> ERROR: syntax error at or near "into"
>>>
>>> Is this a bug?
>>>
>> No, it's a known limitation.
>>
>
> Is there a TODO item for this? I don't see one, do you?
>
>
Allow INSERT/UPDATE ... RETURNING inside a SELECT 'FROM' clause

http://archives.postgresql.org/pgsql-general/2006-09/msg00803.php
http://archives.postgresql.org/pgsql-hackers/2006-10/msg00693.php

cheers

andrew

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

[pgsql-es-ayuda] llamadas dinamicas

hola lista.. me pueden ayudar. como se puede hacer una funcion que llame a otra funcion pero de forma dinamica., es decir, tengo una tabla q tiene la sigte estructura: create table funciones ( orden int , funcion varchar(25) ) con los siguientes datos orden | Funcion --------------------- 1 | funcion1 2 | funcion2 y lo que necesito es crear una funcion q pueda ejecutar las funciones que se indican en la tabla en el ordenque se indican. Les agredezco su ayuda. gracias. atte., Gerardo.

Ingresa ya a MSN en Concierto y disfruta los recitales en vivo de tus artistas favoritos. MSN en Concierto

Re: [GENERAL] Multithreaded queue in PgSQL

Stevo Slavić wrote:
> I'm trying to make implementation more generic, not to use Postgres
> specific SQL, and through Hibernate and Spring configuration make
> services acquire lock on batch of rows, when trying to acquire lock on
> batch of rows an exception should be thrown if rows are already locked
> by a different service, and through that exception I intend to signal
> to other services that they should try to handle and acquire lock on
> next batch of rows. Will see how that goes.
It's postgres specific, but a serializable transaction and
update/returning fits with how you want it to act.

begin transaction isolation level serializable;
update newsletter_recipients
set ....
where (...) in (select ... from newsletter_recipients where not_sent or
crashed limit 10)
returning *;
commit;

The update marks the rows as processing. The returning gives the
selected ones back to the application without having to issue a select
and an update. The serializable transaction throws an error in other
threads that try to claim the same rows. You could add an offset to the
limit to try to select different rows.

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

Re: [HACKERS] Overhauling GUCS

Gregory Stark <stark@enterprisedb.com> writes:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>> I agree with that for pg_clog and friends, but I'm much more leery of
>> folding WAL into the same framework.

> Well it may still be worthwhile stealing buffers from shared_buffers even if
> we set a special flag marking them as owned by WAL and out of bounds for
> the normal buffer manager.

> At least that way we could always steal more if we want or return some, as
> long as we're careful about when we do it.

... and as long as you can acquire the WAL per-buffer management space out
of nowhere ...

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] Overhauling GUCS

"Josh Berkus" <josh@agliodbs.com> writes:

> Greg,
>
>> At least that way we could always steal more if we want or return some, as
>> long as we're careful about when we do it. That would open the door to having
>> these parameters be dynamically adjustable. That alone would be worthwhile
>> even if we bypass all bells and whistles of the buffer manager.
>>
>
> One hitch, though, is that asynchronous commit could consume big chunks of
> shared_buffers. So we might still need a limit for people who are using async.

Well currently we use a fixed number of fixed-sized buffers, no? I doubt we'll
change that even if we take this tact of making wal_buffers resizable by
stealing buffers from the buffer manager for precisely the reasons Tom was
describing.

--
Gregory Stark
EnterpriseDB

Ask me about EnterpriseDB's RemoteDBA services!

--
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] Overhauling GUCS

Bruce Momjian <bruce@momjian.us> writes:
> Tom Lane wrote:
>> Bruce Momjian <bruce@momjian.us> writes:
>>> The second idea is the idea of having one parameter depend on another.

>> We have tried to do that in the past, and it didn't work well *at all*.

> We have? When?

Just a couple months ago we had to give up enforcing an
interrelationship between NBuffers and MaxConnections, because it got
too complicated and un-explainable. I seem to recall some other
interactions in the distant past, but a quick look through the CVS logs
didn't find any smoking guns.

>> The idea has a fundamental logical flaw, which is that it's not clear
>> which parameter wins if the user changes both.

> Yes, you could get into problems by having variable dependency loops,

Who said anything about loops? What I am talking about is what happens
during
set memory_usage = X; // implicitly sets work_mem = X/100, say
set work_mem = Y;
set memory_usage = Z;
What is work_mem now, and what's your excuse for saying so, and how
will you document the behavior so that users can understand it?
(Just to make things interesting, assume that some of the above SETs
happen via changing postgresql.conf rather than directly.)

If the objective is to make configuration easier to understand,
I don't believe that behind-the-scenes changes of configuration values
will advance that goal.

> but I see no way to easily improve configuration without it.

The higher-level concepts should be things that a configuration wizard
works with, and then tells you how to set the postmaster parameters.
They should not end up in the configure file (unless maybe as comments?)

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] Overhauling GUCS

Magnus Hagander wrote:
> Bruce Momjian wrote:
> > Joshua D. Drake wrote:
> >>
> >> On Wed, 2008-06-11 at 11:45 -0400, Bruce Momjian wrote:
> >>> Greg Sabino Mullane wrote:
> >>>> * The word 'paramters' is still misspelled. :)
> >>> Corrected for 8.4.
> >> Technically this is a bug fix... why not backpatch it too?
> >
> > That might show up as a diff for people doing upgrades where the minor
> > version changed the spelling.
>
> People upgrading won't see it, I think. You only see it when you do a
> new initdb..

The problem is that people doing initdb with different minor versions
will have different stock postgresql.conf files. That isn't a huge
problem, but I don't see a need to create the problem just to fix a
spelling mistake that few have observed.

--
Bruce Momjian <bruce@momjian.us>

EnterpriseDB

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

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

Re: [HACKERS] cannot use result of (insert..returning)

Heikki Linnakangas wrote:
> dvs wrote:
> > Hello,
> >
> > I need to use query like:
> > select (insert into test (a) values (x) returning b),c from anytable
> > where condition
> > but it say
> > ERROR: syntax error at or near "into"
> >
> > Is this a bug?
>
> No, it's a known limitation.

Is there a TODO item for this? I don't see one, do you?

--
Bruce Momjian <bruce@momjian.us>

EnterpriseDB

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

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

Re: [HACKERS] Overhauling GUCS

Greg,

> At least that way we could always steal more if we want or return some, as
> long as we're careful about when we do it. That would open the door to having
> these parameters be dynamically adjustable. That alone would be worthwhile
> even if we bypass all bells and whistles of the buffer manager.
>

One hitch, though, is that asynchronous commit could consume big chunks
of shared_buffers. So we might still need a limit for people who are
using async.

--Josh

--
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] Overhauling GUCS

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> Alvaro Herrera <alvherre@commandprompt.com> writes:
>> Josh Berkus wrote:
>>> Ideally, of course, there would be no wal_buffers setting, and WAL
>>> buffers would be allocated from shared_buffers pool on demand...
>
>> Same for pg_subtrans, pg_clog, etc (as previously discussed)
>
> I agree with that for pg_clog and friends, but I'm much more leery of
> folding WAL into the same framework. Its access pattern is *totally*
> unlike standard caches, so the argument that this would be good for
> performance is resting on nothing but imagination. Also I'm concerned
> about possible deadlocks, because WAL is customarily accessed while
> holding one or more exclusive buffer locks.

Well it may still be worthwhile stealing buffers from shared_buffers even if
we set a special flag marking them as owned by WAL and out of bounds for
the normal buffer manager.

At least that way we could always steal more if we want or return some, as
long as we're careful about when we do it. That would open the door to having
these parameters be dynamically adjustable. That alone would be worthwhile
even if we bypass all bells and whistles of the buffer manager.

--
Gregory Stark
EnterpriseDB

Ask me about EnterpriseDB's RemoteDBA services!

--
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] .psqlrc output for \pset commands

"Bruce Momjian" <bruce@momjian.us> writes:

> In my .psqlrc I have:
>
> \pset format wrapped
>
> and this outputs this on psql startup:
>
> $ psql test
> --> Output format is wrapped.
> psql (8.4devel)
> Type "help" for help.
>
> Is this desirable? \set QUIET at the top of .psqlrc fixes it, but I am
> wondering if we should be automatically doing quiet while .psqlrc is
> processed.

I was wondering about this myself, but I'm still not used to the new banner.
It seems kind of... curt. Perhaps it should just be a single line instead of
two lines both around 20 characters...

Anyways the thing that struck me as odd was the messages appearing *before*
the header. It seems to me the header should print followed by .psqlrc output
followed by normal output.

--
Gregory Stark
EnterpriseDB

Ask me about EnterpriseDB's Slony Replication support!

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

Re: [pgus-board] Resolution Views

On Wed, 2008-06-11 at 15:57 -0700, Selena Deckelmann wrote:
> On Wed, Jun 11, 2008 at 2:34 PM, Joshua D. Drake <jd@commandprompt.com> wrote:

> >> Agreed.
> > ^^^^^^^^
> >
> > Do you mean I can make public the published versions and (for now keep the unpublished for board only?)
>
> Yes, make public the published versions, and keep 'unpublished' for board.

Just to confirm, Michael is this appropriate for you as well?

Joshua D. Drake

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

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

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> (Likely counterexample: adding collation info to text values.)

I don't think the argument really needs an example, but I would be pretty
upset if we proposed tagging every text datum with a collation. Encoding
perhaps, though that seems like a bad idea to me on performance grounds, but
collation is not a property of the data at all.

--
Gregory Stark
EnterpriseDB