Concurrencia

antes que nada, esta es una lista en ingles... estoy redireccionando
tu mail a una lista mas adecuada

On 3/13/06, Editores S.A. <editores@editores.com.co> wrote:

Tengo una consulta acerca de manejo de concurrencia en postgres con PHP

En un acceso de 50 usuarios simultaneamente como agilizar el bolqueo de
tablas accesadas

en postgres rara vez necesitas bloquear tablas... si por algun motivo
lo necesitas usas LOCK TABLE o SELECT ... FOR UPDATE

la unica forma de "agilizar" un bloquueo es mantener la transaccion lo
mas corta posible

y como puedo garantizar un refresco de pantalla en PHP, que la informacion
desplegada este actualizada.

eso es php... basicamente haces un select de los datos y redisplayas

evitar un desbordamiento de memoria por vistas sobre la BD

????

--
Atentamente,
Jaime Casanova

"What they (MySQL) lose in usability, they gain back in benchmarks, and that's
all that matters: getting the wrong answer really fast."
Randal L. Schwartz

redirecting to pgsql-es-ayuda@postgresql.org

On 3/13/06, Editores S.A. <editores@editores.com.co> wrote:

Tengo una consulta acerca de manejo de concurrencia en postgres con PHP

En un acceso de 50 usuarios simultaneamente como agilizar el bolqueo de
tablas accesadas
y como puedo garantizar un refresco de pantalla en PHP, que la informacion
desplegada este actualizada. evitar un desbordamiento de memoria por
vistas sobre la BD

--
Atentamente,
Jaime Casanova

"What they (MySQL) lose in usability, they gain back in benchmarks, and that's
all that matters: getting the wrong answer really fast."
Randal L. Schwartz

On 15/03/06, Jaime Casanova <systemguards@gmail.com> wrote:

antes que nada, esta es una lista en ingles... estoy redireccionando
tu mail a una lista mas adecuada

On 3/13/06, Editores S.A. <editores@editores.com.co> wrote:

Tengo una consulta acerca de manejo de concurrencia en postgres con PHP

En un acceso de 50 usuarios simultaneamente como agilizar el bolqueo de
tablas accesadas

en postgres rara vez necesitas bloquear tablas... si por algun motivo
lo necesitas usas LOCK TABLE o SELECT ... FOR UPDATE

la unica forma de "agilizar" un bloquueo es mantener la transaccion lo
mas corta posible

y como puedo garantizar un refresco de pantalla en PHP, que la informacion
desplegada este actualizada.

eso es php... basicamente haces un select de los datos y redisplayas

evitar un desbordamiento de memoria por vistas sobre la BD

Mhh, si te refieres a algun error de programacion en el manejo de
memoria (memory leak) bueno, puede suceder. Como un ejemplo muy simple
y adrede mira el caso de esta funcion

void
example()
{
char *b;
b = (char *)malloc(sizeof(char *));
}

int
main()
{
while(1)
example();
}
o en casos mucho mas complicados. Sin embargo el codigo se revisa
muchas veces ante de lanzar un release. Ademas hay proyectos como lo
es http://scan.coverity.com/ que buscan errores de programacion en
aplicaciones OpenSource, entre ellos PostgreSQL. Despues publican los
resultados y se analizan para determinar si realmente es un bug o
algun Falso-Positivo.

Mario Gonzalez escribi�:

Mhh, si te refieres a algun error de programacion en el manejo de
memoria (memory leak) bueno, puede suceder. Como un ejemplo muy simple
y adrede mira el caso de esta funcion

void
example()
{
char *b;
b = (char *)malloc(sizeof(char *));
}

Observa que Postgres rara vez hace esto. Generalmente se usa palloc()
en lugar de malloc(). La diferencia es que palloc() registra cada
bloque emplazado ("allocated") como perteneciente a un "contexto". Con
cierta periodicidad el contexto puede "resetearse", en cuyo caso todos
los bloques emplazados se liberan automaticamente. Por ejemplo tu
funcion podria hacer algo asi:

void example() {
MemoryContext context,
oldcontext;
int i;

context = AllocSetContextCreate( ... algunos parametros ...);
oldcontext = MemoryContextSwitchTo(context);

for (i = 0; i < 1000; i++) {
char *b;
b = palloc(sizeof(char *));
}

MemoryContextSwitchTo(oldcontext);
AllocSetDelete(context);
}

por mucho que tu llames a esta funcion un millon de veces, nunca va a
usar mas de de (1000 * sizeof(char*)), aunque nunca hagas pfree().

Pero no entiendo que tiene que ver esto con la pregunta original :-)

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

On 16/03/06, Alvaro Herrera <alvherre@commandprompt.com> wrote:

Mario Gonzalez escribió:

Mhh, si te refieres a algun error de programacion en el manejo de
memoria (memory leak) bueno, puede suceder. Como un ejemplo muy simple
y adrede mira el caso de esta funcion

void
example()
{
char *b;
b = (char *)malloc(sizeof(char *));
}

Observa que Postgres rara vez hace esto. Generalmente se usa palloc()
en lugar de malloc(). La diferencia es que palloc() registra cada
bloque emplazado ("allocated") como perteneciente a un "contexto". Con
cierta periodicidad el contexto puede "resetearse", en cuyo caso todos
los bloques emplazados se liberan automaticamente. Por ejemplo tu
funcion podria hacer algo asi:

void example() {
MemoryContext context,
oldcontext;
int i;

context = AllocSetContextCreate( ... algunos parametros ...);
oldcontext = MemoryContextSwitchTo(context);

for (i = 0; i < 1000; i++) {
char *b;
b = palloc(sizeof(char *));
}

MemoryContextSwitchTo(oldcontext);
AllocSetDelete(context);
}

Humm, interesante eh? Pero por regla general por que no se usa
palloc() en todos los codigos? Quiza tendra un costo el crear un
MemoryContext.

por mucho que tu llames a esta funcion un millon de veces, nunca va a
usar mas de de (1000 * sizeof(char*)), aunque nunca hagas pfree().

Pero no entiendo que tiene que ver esto con la pregunta original :-)

De editores@editores.com.co preguntaron por un desbordamiento de
memoria o manejo de memoria si mal no recuerdo. Por eso mande el mail
:)

Mario Gonzalez escribi�:

On 16/03/06, Alvaro Herrera <alvherre@commandprompt.com> wrote:

Observa que Postgres rara vez hace esto. Generalmente se usa palloc()
en lugar de malloc(). La diferencia es que palloc() registra cada
bloque emplazado ("allocated") como perteneciente a un "contexto". Con
cierta periodicidad el contexto puede "resetearse", en cuyo caso todos
los bloques emplazados se liberan automaticamente.

Humm, interesante eh? Pero por regla general por que no se usa
palloc() en todos los codigos? Quiza tendra un costo el crear un
MemoryContext.

Porque MemoryContext es un concepto propio de Postgres :-) malloc es
parte del estandar que define la libc. palloc usa malloc internamente.
Ciertamente usar los contextos tiene un costo de ejecucion, pero en
terminos de tiempo de programador es muchisimo mas eficiente. Por otra
parte, los contextos asi como los usa Postgres estan bien adaptados para
un programa que funciona como servidor, pero no para un cliente. No
significa que no se puedan usar ni que no sea buena idea usarlos, sino
que no son una idea tan increiblemente superior.

Yo se que Samba4 usa un concepto semejante. Y hay otros, pero no
recuerdo. Tridgell mencionaba otros en una entrevista que le hicieron a
proposito de Samba4 y su programita c/r a BitKeeper.

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

On 16/03/06, Alvaro Herrera <alvherre@commandprompt.com> wrote:

Mario Gonzalez escribió:

On 16/03/06, Alvaro Herrera <alvherre@commandprompt.com> wrote:

Observa que Postgres rara vez hace esto. Generalmente se usa palloc()
en lugar de malloc(). La diferencia es que palloc() registra cada
bloque emplazado ("allocated") como perteneciente a un "contexto". Con
cierta periodicidad el contexto puede "resetearse", en cuyo caso todos
los bloques emplazados se liberan automaticamente.

Humm, interesante eh? Pero por regla general por que no se usa
palloc() en todos los codigos? Quiza tendra un costo el crear un
MemoryContext.

Porque MemoryContext es un concepto propio de Postgres :-) malloc es
parte del estandar que define la libc. palloc usa malloc internamente.

Te entiendo. Pero cuando me referia a «todos los codigos» me referia
a los codigos de PostgreSQL, jeje :) Porque he visto que hay varias
lineas que hacen uso de malloc() directamente, quiza para una tarea
rapida que no vale la pena crear un context.... quizas.

Hablando de manejo de memoria, Gnome saco su version 2.14 y con ella
varias novedades como la inclusion de GSlice que segun dicen, es dos
veces mas rapido que malloc(). ¿Como se pudiera hacer un benchmark
decente que mida la asignacion de memoria? Por ejemplo, usando
palloc() v/s malloc() Para empezar, pudiera bastar compilando las
funciones mencionadas en estos mails y aplicandole un time? Algo
como...

time ./with_malloc

Mario Gonzalez escribi�:

On 16/03/06, Alvaro Herrera <alvherre@commandprompt.com> wrote:

Porque MemoryContext es un concepto propio de Postgres :-) malloc es
parte del estandar que define la libc. palloc usa malloc internamente.

Te entiendo. Pero cuando me referia a �todos los codigos� me referia
a los codigos de PostgreSQL, jeje :) Porque he visto que hay varias
lineas que hacen uso de malloc() directamente, quiza para una tarea
rapida que no vale la pena crear un context.... quizas.

Ah! Puedes dar un ejemplo?

Hablando de manejo de memoria, Gnome saco su version 2.14 y con ella
varias novedades como la inclusion de GSlice que segun dicen, es dos
veces mas rapido que malloc(). �Como se pudiera hacer un benchmark
decente que mida la asignacion de memoria? Por ejemplo, usando
palloc() v/s malloc() Para empezar, pudiera bastar compilando las
funciones mencionadas en estos mails y aplicandole un time?

No tengo idea lo que es o hace GSlice. Pero el tema de emplazamiento de
memoria no solo es importante que sea rapido, sino que simplifique la
tarea de programacion. Si tienes que hacer free() de cada elemento a
que haces malloc(), los programas se vuelven complicados rapidamente; es
muy facil perder rastro de que cosas debes liberar. En una funcion o
dos da lo mismo, es trivial. Pero seguirle la pista a todo el
emplazamiento de memoria del backend es muy dificil; y cuando haces un
ROLLBACK tienes que liberarlo todo de una sola vez. Y que pasa si
tienes una transaccion, haces un par de cosas y luego creas un
savepoint, haces otro par de cosas y luego abortas el savepoint? Tienes
que liberar la memoria correspondiente al savepoint pero no el resto.
Y al terminar la transaccion debes liberarlo todo. Esto es dificil de
hacer en general, pero con el tema de los contextos es trivial.

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

On 16/03/06, Alvaro Herrera <alvherre@commandprompt.com> wrote:

Mario Gonzalez escribió:

On 16/03/06, Alvaro Herrera <alvherre@commandprompt.com> wrote:

Porque MemoryContext es un concepto propio de Postgres :-) malloc es
parte del estandar que define la libc. palloc usa malloc internamente.

Te entiendo. Pero cuando me referia a «todos los codigos» me referia
a los codigos de PostgreSQL, jeje :) Porque he visto que hay varias
lineas que hacen uso de malloc() directamente, quiza para una tarea
rapida que no vale la pena crear un context.... quizas.

Ah! Puedes dar un ejemplo?

Claro. Cuando estaba revisando lo de coverity en una de las tantas
funciones que pertencen a pgsql/src/interfaces/libpq/fe-protocol3.c,
especificamente la pqGetCopyData3() en la linea 1206

*buffer = (char *) malloc(msgLength + 1);

IMO, crear un context en este caso especifico es demasiado, porque
bastaria hacer un PQmemfree()

O sea que, el uso de malloc() o palloc() dependera del uso que se
le de a la memoria y cuan dificil sea manipularla a lo largo del
codigo. ¿Esta bien?

Hablando de manejo de memoria, Gnome saco su version 2.14 y con ella

[...]

Mario Gonzalez escribi�:

On 16/03/06, Alvaro Herrera <alvherre@commandprompt.com> wrote:

Ah! Puedes dar un ejemplo?

Claro. Cuando estaba revisando lo de coverity en una de las tantas
funciones que pertencen a pgsql/src/interfaces/libpq/fe-protocol3.c,
especificamente la pqGetCopyData3() en la linea 1206

Ese es codigo del lado del cliente, no del servidor.

O sea que, el uso de malloc() o palloc() dependera del uso que se
le de a la memoria y cuan dificil sea manipularla a lo largo del
codigo. �Esta bien?

Mas o menos. En Postgres esa decision ya esta tomada: en el codigo del
servidor se usa palloc, en todo el resto se usa malloc (psql, libpq,
initdb, etc)

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

On 16/03/06, Alvaro Herrera <alvherre@commandprompt.com> wrote:

Mario Gonzalez escribió:

On 16/03/06, Alvaro Herrera <alvherre@commandprompt.com> wrote:

Ah! Puedes dar un ejemplo?

Claro. Cuando estaba revisando lo de coverity en una de las tantas
funciones que pertencen a pgsql/src/interfaces/libpq/fe-protocol3.c,
especificamente la pqGetCopyData3() en la linea 1206

Ese es codigo del lado del cliente, no del servidor.

O sea que, el uso de malloc() o palloc() dependera del uso que se
le de a la memoria y cuan dificil sea manipularla a lo largo del
codigo. ¿Esta bien?

Mas o menos. En Postgres esa decision ya esta tomada: en el codigo del
servidor se usa palloc, en todo el resto se usa malloc (psql, libpq,
initdb, etc)

Ok, ya esta claro :-)