Alvaro Herrera <alvherre@commandprompt.com> writes:
> Some sort of "if stats were requested in the last 500 ms, just tell theBTW, we could implement that by, instead of having a global tunable,
> requester to read the existing file".
> Things that come to mind:
> - autovacuum could use a more frequent stats update in certain cases
including a field in the request message saying how stale an existing
file is acceptable for this requestor. 500ms might be the standard
value but autovac could use a smaller number.
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
Saturday, September 6, 2008
Re: [HACKERS] reducing statistics write overhead
Re: [HACKERS] [PATCH] "\ef " in psql
>
> I wrote:
> > ... define
> > \ef with no argument as being the command that presents an empty
> > CREATE FUNCTION command template to fill in.
>
> No complaints? I'll go make that happen.
No complaints, it sounds fine to me.
> What about the general issue that neither \e nor \ef leave you with a
> presentation of what's in the query buffer?
I don't know how that can be fixed; but I agree with Brendan that it's
behaviour that people are used to, and that it can be left alone for
now.
-- ams
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [NOVICE] telnet examples
> For the time being, I've basically given up on this -- we're
> using netcat hooked to `psql` and allowing the client to use
> raw SQL. This is obviously not a long term solution, but it
> does allow us to proceed in the short term.
Good solution. The API for sending queries and returning results is
just too complex to ever emulate in telnet directly.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-novice mailing list (pgsql-novice@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-novice
Re: [GENERAL] Subqueries in Check() -- Still Intentionally Omitted?
> "Richard Broersma" <richard.broersma@gmail.com> writes:
> > I am curious if the motivation is still valid for intentionally
> > omitting check sub-queries. (what was the motivation to begin with?)
>
> > Since we can effectively work around this limitation by doing the same
> > thing with a function in a CHECK constraint, why would we want to
> > prevent anyone from using the standard syntax for achieving the same
> > effect?
>
> Because if we supported the standard syntax, we'd also have to support
> the standard semantics; which a function-in-CHECK does *not* give you.
>
> The standard says that the constraint is guaranteed not to be violated,
> which in the worst case means that any time you update the table(s)
> referenced in the subquery, you have to retest the CHECK expression
> at every row of the table having the constraint. Consider for instance
> CREATE TABLE t1 (x int CHECK (x < (SELECT sum(y) FROM t2)));
> If we change some value of t2.y, do all values of t1.x still satisfy
> their constraint?
>
> In some cases, with enough intelligence you could optimize this into
> something fast enough to be usable; but it's a research problem.
> (The cases that I can see how to optimize are pretty much equivalent to
> plain foreign key constraints, anyway.)
Is this a TODO? I assume it is not.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [ADMIN] rpm install not recognized by yum.
On Wed, 2008-09-03 at 11:24 -0400, slamp slamp wrote:
> how come? also when i performed yum clean all i get
> the message "Repository pgdg82 is listed more than once in the
> configuration". although i only see one declaration of pgdg82, the
> other is pgdg82-source. Anyone have this issue?
Please check /etc/yum.conf file.
We have 8.2 + RHEL 5 on many servers, and we don't have this issue.
--
Devrim GÜNDÜZ, RHCE
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org
Re: [PATCHES] hash index improving v3
> On Fri, Sep 5, 2008 at 2:21 PM, Alex Hunsaker <badalex@gmail.com> wrote:
>> Ok now that I made it so it actually *test* collisions, with the patch
>> it always returns all rows that matched the hashed "key".
> And here is the fix, we just forget to set the recheck flag for bitmap scans.
For the convenience of anyone intending to test, here is an updated
patch against CVS HEAD that incorporates Alex's fix.
regards, tom lane
Re: [HACKERS] [PATCH] "\ef " in psql
> ... define
> \ef with no argument as being the command that presents an empty CREATE
> FUNCTION command template to fill in.
No complaints? I'll go make that happen.
What about the general issue that neither \e nor \ef leave you with a
presentation of what's in the query buffer? I haven't studied readline
enough to know if that's fixable.
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] storing repeating dates / events
> yes i am trying to build a alerting system where events will repeat
> weekly/monthly/annually
>
> what is the best way to store this kind of information in postgres?
Use timestamps. And model your application with them.
--
Jorge Godoy <jgodoy@gmail.com>
Re: [HACKERS] pg_dump/pg_restore items
> What is the state of the following items? I'm a little confused about
> whether or not work is being done on them.
> . splitting pg_dump/pg_restore schema dumps into pre-data and post-data
> sections
A patch for that was proposed and rejected in the last fest; I'm not
sure if anyone is trying to bring it up to speed, but it's in the
archives if anyone wants to.
> . parallel pg_restore
I've not heard that anyone has done any work on this.
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] [COMMITTERS] pgsql: Fix an oversight in the 8.2 patch that improved mergejoin
> On Sat, 2008-09-06 at 13:06 +0100, Gregory Stark wrote:
>> Is that right? The materialize is just doing the same writing that the final
>> pass of the sort would have been doing. Did we discount the costs for sort for
>> that skipping writing that final pass when that was done?
> IIRC the cost of the sort didn't include the final merge, so when we
> avoided the final merge the cost model for the sort became accurate.
> Perhaps we should add something when we don't do that.
> It seems reasonable than an extra node should cost something anyhow, and
> the per tuple cost is the current standard way of indicating that extra
> cost.
Well, the problem with the previous coding was that the costs assigned
to the various nodes simply failed to add up, because the materialize
node injected by create_mergejoin_plan had not been accounted for at all
in the Path costs. It's fair to question whether cost_sort couldn't be
improved to create a more accurate estimate of what's likely to happen
at runtime given recent changes in the sort code --- but that would be a
distinct issue. I'm not entirely sure how to give cost_sort enough
context info, anyway.
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: [PATCHES] hash index improving v3
> - tbm_add_tuples(tbm, &scan->xs_ctup.t_self, 1, false);
> + tbm_add_tuples(tbm, &scan->xs_ctup.t_self, 1, true);
Hah, I bet that explains Jonah's complaint that recheck didn't seem to
be happening in his tests. Nice catch.
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Re: [HACKERS] reducing statistics write overhead
> Some sort of "if stats were requested in the last 500 ms, just tell the
> requester to read the existing file".
> Things that come to mind:
> - autovacuum could use a more frequent stats update in certain cases
BTW, we could implement that by, instead of having a global tunable,
including a field in the request message saying how stale an existing
file is acceptable for this requestor. 500ms might be the standard
value but autovac could use a smaller number.
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: [pgsql-es-ayuda] Organizacion del PSDP-es
postgresql, el resto son tareas pendientes que en el transcurso del
tiempo se tendran que hacer, y segun la capacidad con que se cuente
para abordar ese trabajo, no sobra mencionar esa necesidad.
--
TIP 8: explain analyze es tu amigo
Re: [HACKERS] reducing statistics write overhead
> Some sort of "if stats were requested in the last 500 ms, just tell the
> requester to read the existing file".
Hmm, I was thinking of delaying both the write and the reply signal
until 500ms had elapsed. But the above behavior would certainly be
easier to implement, and would probably be good enough (TM).
> - Maybe we oughta have separate files, one for each database? That way
> we'd reduce unnecessary I/O traffic for both the reader and the writer.
The signaling would become way too complex, I think. Also what do you
do about shared tables?
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: [pgsql-es-ayuda] Organizacion del PSDP-es
> Alvaro,
>
> Te pregunto por ser de las personas con mas experiencias en la lista.
>
> ¿ Que otros lenguajes están avanzados en traducción ?
FR, DE, JA
> Y de ser así,
>
> ¿ Conoces la metodología que han utilizado ?
Han traducido los SGMLs directamente.
Una cosa que sería buena es enfocarse en un proyecto, sin irse demasiado
por las ramas. ¿Queremos traducir la documentación? OK, excelente,
adelante. Por favor no comprometamos al mismo tiempo la traducción del
wiki, del sitio web, y de los videos de Youtube en que aparezca un gordo
con traje de sumo. El que mucho abarca, se lo lleva la corriente; o
algo así.
--
Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J
"Some men are heterosexual, and some are bisexual, and some
men don't think about sex at all... they become lawyers" (Woody Allen)
--
TIP 2: puedes desuscribirte de todas las listas simultáneamente
(envía "unregister TuDirecciónDeCorreo" a majordomo@postgresql.org)
Re: [HACKERS] reducing statistics write overhead
> (In fact, maybe this patch ought to include some sort of maximum update
> rate tunable? The worst case behavior could actually be WORSE than now.)
Some sort of "if stats were requested in the last 500 ms, just tell the
requester to read the existing file".
Things that come to mind:
- autovacuum could use a more frequent stats update in certain cases
- Maybe we oughta have separate files, one for each database? That way
we'd reduce unnecessary I/O traffic for both the reader and the writer.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
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] reducing statistics write overhead
> On Fri, 2008-09-05 at 15:23 -0400, Tom Lane wrote:
>> How necessary is this given the recent fixes to allow the stats file to
>> be kept on a ramdisk?
> I would prefer this approach and back-out the other change.
Even if we get on-demand done, I wouldn't see it as a reason to back out
the statfile relocation work. In an environment where the stats are
demanded frequently, you could still need that for performance.
(In fact, maybe this patch ought to include some sort of maximum update
rate tunable? The worst case behavior could actually be WORSE than now.)
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
[pgsql-es-ayuda] RE: [pgsql-es-ayuda] Manual de instalación OT
> De: Edwin Quijada <listas_quijada@hotmail.com>
> Asunto: RE: [pgsql-es-ayuda] Manual de instalación
> A: hermeszambra@yahoo.com, pgsql-es-ayuda@postgresql.org
> Fecha: jueves, 4 septiembre, 2008, 7:51 pm
> Gabriel, no se que es pelotudo, gracias a Dios, pero es una
> forma de reirnos un poco. Me gusto, lo de traducirlo. :P
>
> *-------------------------------------------------------*
> *-Edwin Quijada
> *-Developer DataBase
> *-JQ Microsistemas
> *-809-849-8087
>
Solo te aclaro lo de pelotudo, si puedo, pelotudo es algo
bobo y sin sentido, en el rio de la plata, boludo y pelotudo son
sinomimos de algo asi, bobo, sin sentido, desganado.
Ahora parece ser que soy defensor de newbies y me definieron Trolls,
me parece que fui muy respetuoso y no quise causar ruido en la lista.
Solamente pienso que instalar postgresql en windows es facil, y las
complicaciones no vienen por el lado de postgresql, si no por algunos
temitas de windows y me dispuse a contestar en privado para no generar
ruido.
A vos y a Jaime los conozco dando excelentes aportes y por eso puse que
me extrañaba esa actitud.
A Jenaro, no lo conozco asi que ni pienso contestarle.
Un abrazo.
____________________________________________________________________________________
Yahoo! MTV Blog & Rock >¡Cuéntanos tu historia, inspira una canción y gánate un viaje a los Premios MTV! Participa aquí http://mtvla.yahoo.com/
--
TIP 8: explain analyze es tu amigo
Re: [GENERAL] Can I truncate statements in the log?
> As part of my log configuration, I log statements that take over 3
> seconds. I find this very useful for optimising tables etc. The problem
> is that it produces verbatim some very large statements which can create
> huge log entries, which are probably responsible themselves for slowing
> the system down. The problem tend to be insert statements for binary
> objects - which can be Megabytes long.
>
> Is it possible to stop logging these excessive insert statements
> somehow, or restricting the log of statements to select, delete etc and
> ignore inserts.
No, sorry.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
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] storing repeating dates / events
Em Saturday 06 September 2008 14:12:49 rkmr.em@gmail.com escreveu:yes i am trying to build a alerting system where events will repeat
Along with the timestamp store a boolean that indicates if the event should> Hi
> I want to store dates / events for example birthdays (or may 5th) that
> repeats every year..
> what is the best way to do in postgres?
> if i use timestamp it is going to be use the current year.. how do i do
> this?
consider the year or not.
But you might surely design it better, specially for things that repeat on
intervals other than yearly.
weekly/monthly/annually
what is the best way to store this kind of information in postgres?
thanks
Re: [GENERAL] storing repeating dates / events
A timestamp includes the year so there shouldn't be any problem. Although, i can't say i'm sure what you think might be the problem. Perhaps you should clarify what it is you want to store, as well as your concerns.rkmr.em@gmail.com wrote:
Hi
I want to store dates / events for example birthdays (or may 5th) that
repeats every year..
what is the best way to do in postgres?
if i use timestamp it is going to be use the current year.. how do i do
this?
if it includes the year, how do i query out and find birthdays for this this year? like if i had a table with column
user text,
dob timestamp without timezone,
can you tell me what the query will be to find todays birthday?
Re: [GENERAL] storing repeating dates / events
> Hi
> I want to store dates / events for example birthdays (or may 5th) that
> repeats every year..
> what is the best way to do in postgres?
> if i use timestamp it is going to be use the current year.. how do i do
> this?
Along with the timestamp store a boolean that indicates if the event should
consider the year or not.
But you might surely design it better, specially for things that repeat on
intervals other than yearly.
--
Jorge Godoy <jgodoy@gmail.com>
Re: [GENERAL] storing repeating dates / events
> Hi
> I want to store dates / events for example birthdays (or may 5th) that
> repeats every year..
> what is the best way to do in postgres?
> if i use timestamp it is going to be use the current year.. how do i do
> this?
>
A timestamp includes the year so there shouldn't be any problem.
Although, i can't say i'm sure what you think might be the problem.
Perhaps you should clarify what it is you want to store, as well as your
concerns.
b
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] storing repeating dates / events
I want to store dates / events for example birthdays (or may 5th) that repeats every year..
what is the best way to do in postgres?
if i use timestamp it is going to be use the current year.. how do i do this?
Re: [HACKERS] Synchronous Log Shipping Replication
> Pavan re-designed the sync replication based on the prototype
> and I posted that design doc on wiki. Please check it if you
> are interested in it.
> http://wiki.postgresql.org/wiki/NTT%27s_Development_Projects
It's good to see the detailed design, many thanks.
I will begin looking at technical details next week.
> This design is too huge. In order to enhance the extensibility
> of postgres, I'd like to divide the sync replication into
> minimum hooks and some plugins and to develop it, respectively.
> Plugins for the sync replication plan to be available at the
> time of 8.4 release.
What is Core's commentary on this plan?
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and 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: [pgsql-es-ayuda] Problema SET DATESTYLE TO EUROPEAN
<clemenlg@gmail.com> wrote:
> Hola,
> Tengo un problemilla con las fechas de postgresql en un servidor. Tengo que
> decir que en los dos pcs que tengo, cuando cambio el formato de fecha de
> postgresql no hay problema, pero hay un servidor, que es el que realmente
> importa, en el cual no puedo cambiar el formato de fecha.
> Si me conecto a la base de datos, y pongo la fecha en europeo:
> SET DATESTYLE TO EUROPEAN, SQL;
> SET
> y lo muestro:
> show datestyle ;
> DateStyle
> -----------
> SQL, DMY
> (1 fila)
> Pero si desconecto y vuelvo a conectar a la base de datos...
> show datestyle ;
> DateStyle
> -----------
> ISO, MDY
> (1 fila)
> Parece que cambia el formato a europeo, pero no, no lo hace.
Y esta correcto, lo que no has comprendido es que el cualquier SET que
hagas dentro de la sesión solo sirve y 'vive' en ella.
> Necesito que esté en europeo, puesto que las consultad que hago, siempre
> trato los datos de las fechas con el formato europeo.
Para hacerlo permanente puedes/debes establecer en el archivo
postgresq.conf, sección Locale and Formatting en la opción:
datestyle = 'iso, mdy'
Suponiendo que estas con 8.3.x, dale una leída a la documentación (si
es otra fíjate en la respectiva):
1. http://www.postgresql.org/docs/8.3/static/runtime-config-client.html#GUC-DATESTYLE
2. http://www.postgresql.org/docs/8.3/static/datatype-datetime.html
En especial a la sección: 8.5.2. Date/Time Output.
Saludos y abrazos...
Marco Antonio Frias Butrón
Slackware Linux User
Linux Registered User #356229
--
Sería absurdo que nosotros, que somos finitos, tratásemos de
determinar las cosas infinitas. -- Descartes.
--
TIP 5: ¿Has leído nuestro extenso FAQ?
http://www.postgresql.org/docs/faqs.FAQ.html
[GENERAL] PostgreSQL SSL problem
I have problems to setup SSL for PostgreSQL server. I did all the steps
which described in the documentation (17.8. Secure TCP/IP Connections
with SSL), but when I try to start the PostgreSQL server the pg_ctl gave
me: "could not start server". And nothing in the logs (I enabled all of
them). I googled around but did not find much.
After I disable SSL option in postgresql.conf the server is starting
successfully.
I have all certificates with proper CA signature, rest of applications
(Postfix, Apache, etc.) work with this certificates very well. I am
using OpenSSL from ports.
Please, advise.
My spec:
FreeBSD 7.0-RELEASE-p3 amd64
PostgreSQL 8.3.3 (installed from ports):
WITH_NLS=true
WITHOUT_PAM=true
WITHOUT_LDAP=true
WITHOUT_MIT_KRB5=true
WITHOUT_HEIMDAL_KRB5=true
WITHOUT_OPTIMIZED_CFLAGS=true
WITH_XML=true
WITHOUT_TZDATA=true
WITHOUT_DEBUG=true
WITH_ICU=true
WITH_INTDATE=true
$ pg_config
BINDIR = /usr/local/bin
DOCDIR = /usr/local/share/doc/postgresql
INCLUDEDIR = /usr/local/include
PKGINCLUDEDIR = /usr/local/include/postgresql
INCLUDEDIR-SERVER = /usr/local/include/postgresql/server
LIBDIR = /usr/local/lib
PKGLIBDIR = /usr/local/lib/postgresql
LOCALEDIR = /usr/local/share/locale
MANDIR = /usr/local/man
SHAREDIR = /usr/local/share/postgresql
SYSCONFDIR = /usr/local/etc/postgresql
PGXS = /usr/local/lib/postgresql/pgxs/src/makefiles/pgxs.mk
CONFIGURE = '--with-libraries=/usr/local/lib'
'--with-includes=/usr/local/include' '--enable-thread-safety'
'--with-docdir=/usr/local/share/doc/postgresql' '--with-openssl'
'--with-system-tzdata=/usr/share/zoneinfo' '--enable-integer-datetimes'
'--enable-nls' '--prefix=/usr/local' '--mandir=/usr/local/man'
'--infodir=/usr/local/info/' '--build=amd64-portbld-freebsd7.0' 'CC=cc'
'CFLAGS=-O2 -fno-strict-aliasing -pipe ' 'LDFLAGS= -pthread
-rpath=/usr/local/lib' 'build_alias=amd64-portbld-freebsd7.0'
CC = cc
CPPFLAGS = -I/usr/local/include
CFLAGS = -O2 -fno-strict-aliasing -pipe -Wall -Wmissing-prototypes
-Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels
-fno-strict-aliasing -fwrapv
CFLAGS_SL = -fPIC -DPIC
LDFLAGS = -pthread -rpath=/usr/local/lib -L/usr/local/lib
-Wl,-R'/usr/local/lib'
LDFLAGS_SL =
LIBS = -lpgport -lintl -lssl -lcrypto -lz -lreadline -lcrypt -lm
VERSION = PostgreSQL 8.3.3
Thanks,
Andriy
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
[BUGS] BUG #4406: silent install error
Bug reference: 4406
Logged by: Mike Gagnon
Email address: mike.gagnon@bellnet.ca
PostgreSQL version: 8.3.1
Operating system: Windows XP
Description: silent install error
Details:
Hi,
When I try to do a silent install, I have created the user and password in
windows before trying this:
MSIEXEC /i "postgresql-8.3-int.msi" /qb /log "c:\logfile.txt"
ADDLOCAL="server,nls,psql,pgadmin,includefiles,libfiles,binfiles"
INTERNALLAUNCH=1 DOSERVICE=1 CREATESERVICEUSER=0 DOINITDB=1
SERVICEDOMAIN="<ComputerName>" SERVICEACCOUNT="postgres"
SERVICEPASSWORD="randompass1" SERVICENAME="PostgreSQL Database Server 8.3"
SUPERUSER="postgres" SUPERPASSWORD="postgrespw" LOCALE=C ENCODING=SQL_ASCII
LISTENPORT=5432 PERMITREMOTE=1 PL_PGSQL=1 PL_PERL=1 PL_PERLU=1 PL_TCL=0
PL_TCLU=0 PL_PYTHONU=0 BASEDIR="c:\mydir\PostgreSQL\8.3"
I then get the following error:
"User account ¡¡¡¡¡¡¡s¡¡¡¡\¡¡¡¡¡W does not exist"
It's as if the installer doesn't pick up the correct username I'm giving
it...
Is there any way around this?
Many thanks,
Mike
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[GENERAL] Efficient processing of staging data
I'm looking for an efficient way to process data that I have stored in a
staging table. This is syslog output, so it consists of text, where I
need regexes to filter it out. The data will be split into several/a lot
of tables.
I currently have a set of queries that
* read from staging and insert into destination table.
* delete from staging (using destination table).
This requires 2 scans over the tables and the index operations (which
pay of here). I do the processing incrementally, in order to keep run
time under control. But for only 4 filters this will take around 6 to 30
minutes.
My later idea was to do a (incremental) table scan on the staging table
and have a function do the processing of the row. The function will then
either:
* decide to do nothing
* decide to insert the (transformed) row into the destination table and
delete it from the staging table.
An obvious extension would be to put this processing in the INSERT
trigger of the staging table, saving the I/O's requires for an insert
and delete from the staging table. I like to do this afterwards for the
moment.
What are the recommended methods and helpful implementation hints to get
it working optimally? I.e. would my method work or are there any better
solutions possible?
How can I write the filtering functions in such a manner that I can
later transform the solution in a trigger based one?
Regards,
- Joris Dobbelsteen
--
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] reducing statistics write overhead
> How necessary is this given the recent fixes to allow the stats file to
> be kept on a ramdisk?
I would prefer this approach and back-out the other change.
On-demand is cheaper and easier to use.
> > Attached is a WIP patch, which basically implements this:
>
> This patch breaks deadlock checking and statement_timeout, because
> backends already use SIGALRM. You can't just take over that signal.
> It's possible that you could get things to work by treating this as an
> additional reason for SIGALRM, but that code is unreasonably complex
> already. I'd suggest finding some other way.
There are other ways already in use in backend, so just use those.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
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] Problema SET DATESTYLE TO EUROPEAN
Tengo un problemilla con las fechas de postgresql en un servidor. Tengo que decir que en los dos pcs que tengo, cuando cambio el formato de fecha de postgresql no hay problema, pero hay un servidor, que es el que realmente importa, en el cual no puedo cambiar el formato de fecha.
Si me conecto a la base de datos, y pongo la fecha en europeo:
SET DATESTYLE TO EUROPEAN, SQL;
SET
y lo muestro:
show datestyle ;
DateStyle
-----------
SQL, DMY
(1 fila)
Pero si desconecto y vuelvo a conectar a la base de datos...
show datestyle ;
DateStyle
-----------
ISO, MDY
(1 fila)
Parece que cambia el formato a europeo, pero no, no lo hace.
Necesito que esté en europeo, puesto que las consultad que hago, siempre trato los datos de las fechas con el formato europeo.
¿Alguien sabe porque en el servidor comentado tengo problemas, y en cambio en mis dos pcs no? La instalación en todos ellos es la que trae por defecto debian...
Muchas Gracias
Fwd: [pgsql-es-ayuda] Sobre NpgSql y C#
En la página de descargas [1] del proyecto Npgsql encuentras varios archivos para descargar, observa los que tienen "ms" (por ejemplo: Npgsql1.0-bin-ms1.1.zip). Los que traen "ms" incluyen la librería Mono.Security que debes registrar también.
Pdta: Te recomiendo el IDE SharpDevelop [2] para desarrollar en .NET.
Saludos.
Germán Carrillo
-----------------
[1] http://pgfoundry.org/frs/?group_id=1000140
[2] http://sharpdevelop.net/OpenSource/SD/
Hola listerosEstoy programando con Windows forms en C#.Net 2005, y como gestor de base de datos PostGreSql 7.X; navegando en el Internet encontre NpgSql el acceso a mi bas ede datos de posgresql; baje 3 archivos de NpgSql (Npgsql.dll, Npgsql.dll.mdb, Npgsql.xml), he registrado el archivo Npgsql en mi maquina en la cual estoy programando (SO. Win XP), despues de agregar el componente a mi cuadro de herramientas; pero al momento de tratar de pegar a mi aplicaionel componente "Npgsqlconnection" me sale un mensaje de error que dice que no encontro el archivo "Mono.Security, Version = 1.0.500, Culture = Neutral ..........."De los 3 archivos mencionados solo he registrado el Npgsql.dllAlguien podria decirme que otro procedimiento adicional debria realizar para que me funione ...?de ante mano las mil gracias por su tiempo y predisposición ...SaludosGrover Navia
Re: Fwd: [HACKERS] [Patch Review] TRUNCATE Permission
On Fri, Sep 5, 2008 at 8:13 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> Updated patch attached, based on comments from Ryan Bradetich and Tom
> Lane, and sync'd to latest CVS version.
Thanks for the update. I am out of town until tomorrow evening.
I will re-review this patch when I get back if it has not been
committed by then.
- Ryan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [COMMITTERS] pgsql: Fix an oversight in the 8.2 patch that improved mergejoin
> tgl@postgresql.org (Tom Lane) writes:
>
> > (The materialize protects the sort from having to support mark/restore,
> > allowing it to do its final merge pass on-the-fly.) We neglected to teach
> > cost_mergejoin about that hack, so it was failing to include the
> > materialize's costs in the estimated cost of the mergejoin.
>
> Is that right? The materialize is just doing the same writing that the final
> pass of the sort would have been doing. Did we discount the costs for sort for
> that skipping writing that final pass when that was done?
IIRC the cost of the sort didn't include the final merge, so when we
avoided the final merge the cost model for the sort became accurate.
Perhaps we should add something when we don't do that.
It seems reasonable than an extra node should cost something anyhow, and
the per tuple cost is the current standard way of indicating that extra
cost.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Re: [pgsql-es-ayuda] Organizacion del PSDP-es
> Hola Javier,
>
> Rta 1:
>
> Yo planteo que el PSDP-es es un equipo, ese equipo tiene diferentes
> tareas que cumplir, una de esas es la traduccion, existen otras tareas
> que tambien se enmarcan dentro del proceso de traduccion o permiten
> llegar al proceso de traduccion, una de esas tareas es la recopilacion
> de material a traducir.
> por lo que solo el equipo alfa realiza traducciones, el equipo beta
> recopila material.
>
> Mesa de coordinacion: es un organo de direccion y coordinacion como su
> nombre lo indica, del PSDP-ES. alli se revisa el avance de la
> traduccion,y se aprueba la traduccion final.
>
> Revisor: Persona que tiene facultades para modificar el trabajo de un
> traductor,por su destreza en el manejo del idioma ingles,
> rechazarlo,aceptarlo o darle sugerencias para que presente una mejor
> traduccion de un texto. tambien se trabaja con la modalidad de
> calificacion de la traduccion.tiene derechos para escribir en cvs
> central.
>
> a) Equipo Alfa: compuesto por traductores y un lider de proyecto
>
> b)Equipo Beta: compuesto por miembros del proyecto, para la
> recopilacion de material, no tienen facultades de revisores, El lider
> del equipo alfa participa de la mesa de coordinacion, no como revisor
> ,sino como responsable por las funciones asignadas.
>
> 2) Rta: OK contamos contigo.
>
> 3).Rta Si, presentaciones o tambien llamadas exposiciones,charlas,
> congresos,conferencias,papers, ver pg Conf 2008.tutoriales, How to.
>
> 4. OK, el ciclo vendria a ser el siguiente,
>
> a)Se define la herramientas a utilizar para la traduccion, ya sea el
> framework o el cvs, o git. (!!hay que poner una fecha limite a
> esto!!).
>
> b). El equipo alfa con base en la propuesta de la lista sobre traducir
> lo mas solicitado por la comunidad ( material para los newbies),
> comienza la traduccion de las secciones, partes y capitulos acordados
> y propuestos en mi pasado mensaje.
>
> c). Al interior del Equipo Alfa los miembros del equipo determinan
> como se distribuyen los capitulos,partes y secciones encomandados por
> la mesa coordinadora.se recomienda repartirlos de una forma equitativa
> de tal manera que un traductor no tenga mas carga de trabajo que
> otro,cuando una seccion,parte o capitulo comprenda una extension muy
> grande igualmente se buscara el equilibrio de trabajo entre los
> traductores del equipo.
>
> d). El equipo de traduccion alfa solo entregara al cvs del PSDP-es, el
> material asignado traducido completamente en archivos ¿¿po?? y sgml o
> xml, (esto esta por definir dependiendo de que herramienta
> utilicemos). pero me imagino que lo importante es entregar un archivo
> fuente traducido.
>
> e) Finalizada la traduccion de el material asignado, es remitida al
> cvs del psdp-es donde los revisores toman la traduccion la revisan y
> emiten su validacion o no. si es positiva pasa a ser parte del
> material final para llevar al cvs central. Si es negatiga o necesita
> cambios se rechaza y se remite al autor para que haga los cambios
> necesarios.
>
> Esto es una definicion del ciclo ha grandes rasgos, ya que podria
> variar si utilizamos el framework o si utilizamos git o cvs, pero en
> esencia creo que se aplica a las tres posibles herramientas, es lo que
> sugiero que se aplique.
>
> Por cierto me resulta algo inquietante, saber que no todos han
> aportado su opinion acerca de mi ultimo mensaje, ¿estoy reinventado la
> rueda? ¿No estoy siendo muy pretensioso con todo esto?, creo que
> estamos creando comunidad, es decir subir el segundo peldaño. se
> requiere mucho trabajo para eso.
> --
> TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda
>
>
>
Alvaro,
Te pregunto por ser de las personas con mas experiencias en la lista.
¿ Que otros lenguajes están avanzados en traducción ?
Y de ser así,
¿ Conoces la metodología que han utilizado ?
Para no reinventar la rueda.
Saludos.
--
-------------------------------------------------------------------------------------------
L.A. Jenaro Centeno Gómez
Al-Día se renueva con la Mejora Continua
Departamento de Tecnologías de la Información
Alimentos La Concordia, S.A. de C.V.
Tel. 01 474 741 9200
Ext. 9280
www.aldia.com.mx
--
TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?
http://archives.postgresql.org/pgsql-es-ayuda
Re: [pgsql-es-ayuda] Organizacion del PSDP-es
Rta 1:
Yo planteo que el PSDP-es es un equipo, ese equipo tiene diferentes
tareas que cumplir, una de esas es la traduccion, existen otras tareas
que tambien se enmarcan dentro del proceso de traduccion o permiten
llegar al proceso de traduccion, una de esas tareas es la recopilacion
de material a traducir.
por lo que solo el equipo alfa realiza traducciones, el equipo beta
recopila material.
Mesa de coordinacion: es un organo de direccion y coordinacion como su
nombre lo indica, del PSDP-ES. alli se revisa el avance de la
traduccion,y se aprueba la traduccion final.
Revisor: Persona que tiene facultades para modificar el trabajo de un
traductor,por su destreza en el manejo del idioma ingles,
rechazarlo,aceptarlo o darle sugerencias para que presente una mejor
traduccion de un texto. tambien se trabaja con la modalidad de
calificacion de la traduccion.tiene derechos para escribir en cvs
central.
a) Equipo Alfa: compuesto por traductores y un lider de proyecto
b)Equipo Beta: compuesto por miembros del proyecto, para la
recopilacion de material, no tienen facultades de revisores, El lider
del equipo alfa participa de la mesa de coordinacion, no como revisor
,sino como responsable por las funciones asignadas.
2) Rta: OK contamos contigo.
3).Rta Si, presentaciones o tambien llamadas exposiciones,charlas,
congresos,conferencias,papers, ver pg Conf 2008.tutoriales, How to.
4. OK, el ciclo vendria a ser el siguiente,
a)Se define la herramientas a utilizar para la traduccion, ya sea el
framework o el cvs, o git. (!!hay que poner una fecha limite a
esto!!).
b). El equipo alfa con base en la propuesta de la lista sobre traducir
lo mas solicitado por la comunidad ( material para los newbies),
comienza la traduccion de las secciones, partes y capitulos acordados
y propuestos en mi pasado mensaje.
c). Al interior del Equipo Alfa los miembros del equipo determinan
como se distribuyen los capitulos,partes y secciones encomandados por
la mesa coordinadora.se recomienda repartirlos de una forma equitativa
de tal manera que un traductor no tenga mas carga de trabajo que
otro,cuando una seccion,parte o capitulo comprenda una extension muy
grande igualmente se buscara el equilibrio de trabajo entre los
traductores del equipo.
d). El equipo de traduccion alfa solo entregara al cvs del PSDP-es, el
material asignado traducido completamente en archivos ¿¿po?? y sgml o
xml, (esto esta por definir dependiendo de que herramienta
utilicemos). pero me imagino que lo importante es entregar un archivo
fuente traducido.
e) Finalizada la traduccion de el material asignado, es remitida al
cvs del psdp-es donde los revisores toman la traduccion la revisan y
emiten su validacion o no. si es positiva pasa a ser parte del
material final para llevar al cvs central. Si es negatiga o necesita
cambios se rechaza y se remite al autor para que haga los cambios
necesarios.
Esto es una definicion del ciclo ha grandes rasgos, ya que podria
variar si utilizamos el framework o si utilizamos git o cvs, pero en
esencia creo que se aplica a las tres posibles herramientas, es lo que
sugiero que se aplique.
Por cierto me resulta algo inquietante, saber que no todos han
aportado su opinion acerca de mi ultimo mensaje, ¿estoy reinventado la
rueda? ¿No estoy siendo muy pretensioso con todo esto?, creo que
estamos creando comunidad, es decir subir el segundo peldaño. se
requiere mucho trabajo para eso.
--
TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda
[HACKERS] pg_dump/pg_restore items
whether or not work is being done on them.
. splitting pg_dump/pg_restore schema dumps into pre-data and post-data
sections
. parallel pg_restore
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
[BUGS] BUG #4405: Valid certificate reported as expired
Bug reference: 4405
Logged by: Andrej Podzimek
Email address: andrej@podzimek.org
PostgreSQL version: 8.3.3
Operating system: Linux
Description: Valid certificate reported as expired
Details:
Hello,
I thought this was a PgAdmin III issue and reported it on the PgAdmin
mailing list. Only now did I realize that psql has exactly the same
problem.
I have been using psql (and PgAdmin III) with SSL for a couple of months. I
set up certificates for both the server and the client, valid until March
2009. Everything worked fine.
Now the bad news: Both psql and PgAdmin refuse to connect since yesterday,
with this error message:
Error connecting to the server: SSL error: sslv3 alert certificate
expired
This is obviously a nonsense, as both certificates are valid and system
clocks on both computers show correct date and time. I even restarted the
PostgreSQL server, which did not help.
There haven't been any such problems up to now, so what could be wrong? Is
there anything I should try?
Best regards,
Andrej Podzimek
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Friday, September 5, 2008
Re: [JDBC] Problem With Euro character
You know that ISO-8859-1 does not have the Euro Symbol? Look for
ISO-8859-15 instead...
Daniel Migowski
TNO schrieb:
> Hello
>
> I'm working on a french web application (Spring+Ibatis+Postgre).
> My PostgreSql version : 8.1
> My db encoding is UTF-8.
> My JDBc Driver version is 8.1-405-jdbc3
>
> There is no problem to display the Euro (€) character in HTML pages,
> but in the PDF this caracter disepear !!!
> Strange...
>
> I've done a little test, this is the recuperation of a String "*€ € €
> € € Euro € Euro € € € €" *:
>
> log.info(c.getObservation());
> log.info(new String (c.getObservation().getBytes("UTF-8")));
> log.info(new String (c.getObservation().getBytes("ISO-8859-1")));
>
> INFO 17:49:10.468 ? ? ? ? ? Euro ? Euro ? ? ? ? (TestEuro.java:14)
> INFO 17:49:10.468 € € € € € Euro € Euro € € € €
> (TestEuro.java:15)
> INFO 17:49:10.468 € € € € € Euro € Euro € € € € (TestEuro.java:16)
>
> Very strange, it seems that my observation have an encoding ISO-8859-1
> in my db UTF-8...
--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
[JDBC] Problem With Euro character
I'm working on a french web application (Spring+Ibatis+Postgre).
My PostgreSql version : 8.1
My db encoding is UTF-8.
My JDBc Driver version is 8.1-405-jdbc3
There is no problem to display the Euro (€) character in HTML pages, but in the PDF this caracter disepear !!!
Strange...
I've done a little test, this is the recuperation of a String "€ € € € € Euro € Euro € € € €" :
log.info(c.getObservation());
log.info(new String (c.getObservation().getBytes("UTF-8")));
log.info(new String (c.getObservation().getBytes("ISO-8859-1")));
INFO 17:49:10.468 ? ? ? ? ? Euro ? Euro ? ? ? ? (TestEuro.java:14)
INFO 17:49:10.468 € € € € € Euro € Euro € € € € (TestEuro.java:15)
INFO 17:49:10.468 € € € € € Euro € Euro € € € € (TestEuro.java:16)
Very strange, it seems that my observation have an encoding ISO-8859-1 in my db UTF-8...
if you have any idea...
Re: [HACKERS] plpgsql is not translate-aware
> In reviewing Volkan Yazici's (sorry for the dots) patch to improve
> plpgsql's error messages, I noticed that we have no PO files for plpgsql
> at all!
Ugh. Yeah, we should fix that. Does it actually just work, seeing
that plpgsql is a loadable library?
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] plpgsql is not translate-aware
> It doesn't seem hard to add; I just had to create a nls.mk file and
> things seem ready to go. Obviously, we'll need to add plpgsql to the
> pgtranslation files in pgfoundry.
Actually this is wrong -- since the library is going to run with
"postgres" text domain, we need to add the files to the backend's
nls.mk:
Index: nls.mk
===================================================================
RCS file: /home/alvherre/Code/cvs/pgsql/src/backend/nls.mk,v
retrieving revision 1.22
diff -c -p -u -r1.22 nls.mk
--- nls.mk 24 Mar 2008 18:08:47 -0000 1.22
+++ nls.mk 5 Sep 2008 16:00:18 -0000
@@ -7,7 +7,7 @@ GETTEXT_FILES := + gettext-files
GETTEXT_TRIGGERS:= _ errmsg errdetail errdetail_log errhint errcontext write_stderr yyerror
gettext-files: distprep
- find $(srcdir)/ $(srcdir)/../port/ -name '*.c' -print >$@
+ find $(srcdir)/ $(srcdir)/../port/ $(srcdir)/../pl/ -name '*.c' -print >$@
my-maintainer-clean:
rm -f gettext-files
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
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] Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] Manual de instalación
herida se volverá a poner a defender a los "newbies" (bonita forma de
defender a alguien). Y para que quieren que esto no va a tener fin.
Coincido con Edwin en dejar de alimentar trolls.
Saludos a todos.
Jaime Casanova escribió:
> 2008/9/4 Moises Alberto Lindo Gutarra <mlindo@gmail.com>:
>
>> Es bueno conocer algún tema, tanto básico como avanzado, pero
>> es mejor compartir de buena forma y no como mofa. Y no es asi
>> la instalación en windows, te olvidaste decirle que tiene que tener un
>> usuario no administrador
>> con el cual deberá correrse el servicio windows.
>>
>>
>
> ah! te refieres a ese usuario que te crea el mismo instalador (cuando
> le das a "Siguiente" claro) y que ademas, si no le pones ninguna
> clave, el mismo le genera una?
>
>
--
-------------------------------------------------------------------------------------------
L.A. Jenaro Centeno Gómez
Al-Día se renueva con la Mejora Continua
Departamento de Tecnologías de la Información
Alimentos La Concordia, S.A. de C.V.
Tel. 01 474 741 9200
Ext. 9280
www.aldia.com.mx
--
TIP 4: No hagas 'kill -9' a postmaster
Re: [pgsql-es-ayuda] PostgreSQL Spanish Documentation Project
> 2008/9/2 Jaime Casanova <jcasanov@systemguards.com.ec>:
>
>> 2008/9/2 Alvaro Herrera <alvherre@alvh.no-ip.org>:
>>
>>>> Déjame llamar a Mario para preguntarle cómo podemos volver a levantar la
>>>> plataforma.
>>>>
>>> OK, dice que ya estaba en ello; está en espera del respaldo más reciente
>>> de la BD, y en cuanto lo tenga lo echará a andar en otro hosting.
>>>
>>>
>> Excelente, por favor avisame en cuanto este arriba..
>>
>> --
>> Atentamente,
>> Jaime Casanova
>> Soporte y capacitación de PostgreSQL
>> Asesoría y desarrollo de sistemas
>> Guayaquil - Ecuador
>> Cel. (593) 87171157
>> --
>> TIP 9: visita nuestro canal de IRC #postgresql-es en irc.freenode.net
>>
>>
>
> Estimados Resumiendo un poco entonces quienes se han manifestado en
> traducir hasta ahora son (orden cronologico de aparicion de los
> correos ) :
>
> - Moises Galan
> - Guido Barosio
> - Raul Duque
> - Teofilo Oviedo
> - Gilberto Castillo
> - Miguel Panuera
> - Javier Chavez
>
> Omiti a Alvaro Herrera y Jaime Casanova, porque estoy asumiendo que
> como siempre tendremos su ayuda ( como alguien dijo por ahi en un par
> de correos, asumiendo su calidad de Robot :-) )
>
> Esto es solo para que Moises quien preparo la documentacion inicial
> tenga mas o menos claro quienes se ofrecieron inicialmente, y en su
> defecto, si tenemos un administrador / coordinador pueda ir teniendo
> en cuenta las personas con que se cuenta inicialmente.
>
> Bueno revisare ahora un poco del manual para ver cantidades de
> paginas, contenidos subdivisiones etc.
>
> Buenas Noches a to2
>
> Jch
>
>
>
>
Apuntame también por favor.
--
-------------------------------------------------------------------------------------------
L.A. Jenaro Centeno Gómez
Al-Día se renueva con la Mejora Continua
Departamento de Tecnologías de la Información
Alimentos La Concordia, S.A. de C.V.
Tel. 01 474 741 9200
Ext. 9280
www.aldia.com.mx
--
TIP 8: explain analyze es tu amigo
Re: [GENERAL] large inserts and fsync
> On 9/5/08 11:10 AM, "Sam Mason" <sam@samason.me.uk> wrote:
>> Have you tried bundling all the INSERT statements into a single
>> transaction?
> Yes, the developer already made sure of that and I verified.
Hmm, in that case the penalty probably comes from pushing WAL data out
to disk synchronously. It might be worth playing with wal_sync_method
and/or raising wal_buffers.
The trouble with turning fsync off is that a system crash midway through
the import might leave you with a corrupt database. If you're willing
to start over from initdb then okay, but if you are importing into a
database that already contains valuable data, I wouldn't recommend it.
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: [HACKERS] [Review] pgbench duration option
I received the following email from a helpful fellow off-list,
pointing out an error in my review:
On Fri, Sep 5, 2008 at 7:03 PM, Ragnar <gnari@hive.is> wrote:
> On fös, 2008-09-05 at 15:07 +1000, Brendan Jurd wrote:
>> Wouldn't this be better written as:
>>
>> if ((duration > 0 && timer_exceeded) || st->cnt >= nxacts)
>> {
>> <stop>
>> }
>
> sorry, but these do not lok as the same thing to me.
>
> in the first variant there will not be a stop if
> (duration > 0) and NOT (timer_exceeded) and (st->cnt >= nxacts)
> but in the second variant there will.
>
> admittedly, i have no idea if that situation can occur.
>
> gnari
>
gnari is right. Looking closer I see that nxacts defaults to 10 in
the absence of a -t option, so my version of the code would end up
stopping when the run reaches 10 transactions, even if the user has
specified a -T option.
Sorry for the error. The (duration > 0) test does in fact need to be separate.
Thanks for the catch, gnari.
Cheers,
BJ
--
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] large inserts and fsync
> > > transaction?
> >
> > Yes, the developer already made sure of that and I verified.
I would verify that again, because fsync shouldn't make much of a difference
in that circumstance. I might not do all 16 million in one transaction, but
if you're doing 10 or 100 thousand at a time, it should be pretty fast.
A language-level auto-commit remains to be disabled, perhaps?
--
Alan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [ADMIN] change max_value in sequence
> I have a table with a serial field defined with an older version of
> postgresql (ver. 7). Back then max_value was 2147483647:
> How can I increase it? By updating the max_value-field?
I think you're looking for ALTER SEQUENCE.
Note that if the column it's feeding into is int4, you'd also need to
alter the column type ...
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
[HACKERS] plpgsql is not translate-aware
In reviewing Volkan Yazici's (sorry for the dots) patch to improve
plpgsql's error messages, I noticed that we have no PO files for plpgsql
at all!
It doesn't seem hard to add; I just had to create a nls.mk file and
things seem ready to go. Obviously, we'll need to add plpgsql to the
pgtranslation files in pgfoundry.
There are 141 new strings to translate, and from spanish I get 71
fuzzies, so it seems an easy project.
Should I go ahead and commit the initial files?
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
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] large inserts and fsync
> On 9/5/08 11:10 AM, "Sam Mason" <sam@samason.me.uk> wrote:
> > On Fri, Sep 05, 2008 at 09:16:41AM -0400, Aaron Burnett wrote:
> >> For an upcoming release there is a 16 million row insert that on our test
> >> cluster takes about 2.5 hours to complete with all indices dropped
> >> beforehand.
> >>
> >> If I turn off fsync, it completes in under 10 minutes.
> >
> > Have you tried bundling all the INSERT statements into a single
> > transaction?
>
> Yes, the developer already made sure of that and I verified.
I was under the impression that the only time PG synced the data to disk
was when the transaction was COMMITed. I've never needed to turn off
fsync for performance reasons even when pulling in hundreds of millions
of rows. I do tend to use a single large COPY rather than many small
INSERT statements. PG spends an inordinate amount of time parsing
millions of SQL statements, whereas a tab delimited file is much easier
to parse.
Could you try bumping "checkpoint_segments" up a bit? or have you tried
that already?
Sam
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [DOCS] Incorrect description of xmax and xip in functions docs
> http://developer.postgresql.org/pgdocs/postgres/functions-info.html
>
> xip_list is described as
>
> "Active txids at the time of the snapshot... "
>
>
> This is incorrect. The xip_list is the list of transactions that are in
> progress *and* less than xmax. There may be transactions in progress
> with an xid higher than xmax. This will happen frequently in fact. This
> is because xmax is defined as the highest/latest completed xid, not the
> highest running xid.
>
> Note that there is no way to discover the list of running xids at the
> time of the snapshot, from the data we hold about snapshots. Nor can the
> snapshot data be used to monitor the number of transactions in progress.
>
> Anyone disagree? If not, I'll patch.
My rewording would be:
"Active txids at the time of the snapshot. The list includes only those
active txids between xmin and xmax; there may be active txids higher
than xmax. A txid that is xmin <= txid < xmax and not in this list was
already completed at the time of the snapshot, and thus either visible
or dead according to its commit status. The list does not include txids
of subtransactions."
And for txid_visible_in_snapshot() comment added:
"Function should not be used with subtransaction xids. It is possible
that this function will return a true result for a subtransaction xid
that was actually still in progress at the time of the snapshot".
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
[ADMIN] How can I avoid Frozenxid wraparound on failover to a standby(PITR) database?
Shortly thereafter(Sometime over the long weekend of course), Postgres shutdown the database to avoid XID wraparound data loss. I presume there were warnings in the log about running out of XIDs, but nobody noticed in time and given what transpired after that I don't think it would have mattered if they had.
As per the documentation, I started the DB in single user mode and attempted to do a full database vacuum. After this ran for about 12hours the pg_xlog directory ran out of disk space. I'm not sure I understand why anything is written to pg_xlog as part of the vacuum process, perhaps someone can enlighten me.
I next started looking at the age(refrozenxid) of the tables in my DB, and was surprised to see that over 4000 of the 5000 tables in this DB had an age over 2Billion. So thats 4000 tables representing over a terabyte of data that need to be vacuumed! I am now vacuuming those tables one at a time, which is taking a long time(This is a scripted process). So there is no way I could have vacuumed the tables quickly enough even given a warning of impending XID wraparound.
Looking through the support mailing lists(Bugs) I see some discussion about the frozenxid updates on the master not being propogated to the slave through the WAL logs, and comments from Tom, Alvaro and Heikki suggesting that they were looking into a solution for PG 8.3 and needed a way around the problem in PG 8.2.
I am currently running PG 8.2.4 on FreeBSD.
So my questions are:
1) What is the recommended way to either solve or get around this problem in PG 8.2.4?
2) Is this "problem" fixed in some more current version of Postgres? I didn't see any mention of it in release notes up to PG 8.3.3?
3) Does this mean that if you are trying to use a warm standby DB with PITR, you need to make a new base backup of your primary DB every 1.5billion transactions, or there abouts, to avoid the problem. If so, I think this should be documented in the "Caveats" section of "Continuous Archiving and Point-in-time-recovery(PITR)" section of the manual.
Regards...
Mark Sherwood
Use Windows Live Messenger to send messages to your buddies on their mobile phones Find out more on our PC to Mobile website
Re: [NOVICE] Problem wth postgresql.conf
> FATAL: syntax error in file "/opt/PostgreSQL/8.3/data/postgresql.conf" line
> 108, near token "MB"
> How can i fix it ?
> shared_buffers = 128MB # min 128kB or max_connections*16kB
I think you need quotes here:
shared_buffers = '128MB'
regards, tom lane
--
Sent via pgsql-novice mailing list (pgsql-novice@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-novice
Re: [GENERAL] xml queries & date format
> i am using the xml add-ons, but the date output format seems to be wrong :
I think the conversion to xml intentionally always uses ISO date format,
because that's required by some spec somewhere.
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
[COMMITTERS] plproxy - plproxy: v2.0.6
-----------
v2.0.6
Modified Files:
--------------
plproxy:
Makefile (r1.28 -> r1.29)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/plproxy/plproxy/Makefile.diff?r1=1.28&r2=1.29)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] plproxy - plproxy: v2.0.6
-----------
v2.0.6
Modified Files:
--------------
plproxy:
NEWS (r1.12 -> r1.13)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/plproxy/plproxy/NEWS.diff?r1=1.12&r2=1.13)
plproxy/debian:
changelog (r1.4 -> r1.5)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/plproxy/plproxy/debian/changelog.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
Re: [GENERAL] max_stack_depth Exceeded
> Ow Mun Heng wrote:
>> Am I doing something wrong?
> If your trigger is defined on the head_raw_all_test_2 table, then yes.
> Because it will do a new insert there, and the new insert will fire the
> trigger again, which will do a new insert, which wil lfire the trigger etc.
Of course, the way to have the row be inserted into the parent table is
to just let the trigger return it, instead of returning null.
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] large inserts and fsync
On 9/5/08 11:10 AM, "Sam Mason" <sam@samason.me.uk> wrote:
> On Fri, Sep 05, 2008 at 09:16:41AM -0400, Aaron Burnett wrote:
>> For an upcoming release there is a 16 million row insert that on our test
>> cluster takes about 2.5 hours to complete with all indices dropped
>> beforehand.
>>
>> If I turn off fsync, it completes in under 10 minutes.
>
> Have you tried bundling all the INSERT statements into a single
> transaction? If you haven't then PG will run each statement in its own
> transaction and then commit each INSERT statement to disk separately,
> incurring large overheads.
>
>
> Sam
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
[DOCS] Incorrect description of xmax and xip in functions docs
xip_list is described as
"Active txids at the time of the snapshot... "
This is incorrect. The xip_list is the list of transactions that are in
progress *and* less than xmax. There may be transactions in progress
with an xid higher than xmax. This will happen frequently in fact. This
is because xmax is defined as the highest/latest completed xid, not the
highest running xid.
Note that there is no way to discover the list of running xids at the
time of the snapshot, from the data we hold about snapshots. Nor can the
snapshot data be used to monitor the number of transactions in progress.
Anyone disagree? If not, I'll patch.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
Re: [GENERAL] large inserts and fsync
> For an upcoming release there is a 16 million row insert that on our test
> cluster takes about 2.5 hours to complete with all indices dropped
> beforehand.
>
> If I turn off fsync, it completes in under 10 minutes.
Have you tried bundling all the INSERT statements into a single
transaction? If you haven't then PG will run each statement in its own
transaction and then commit each INSERT statement to disk separately,
incurring large overheads.
Sam
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [PERFORM] indexing for distinct search in timestamp based table
Re: [GENERAL] a performence question
> Hi,
>
> Maybe someone on this list actually have already tried this:
>
> I'm planning to make a partitioned database. From Postgres documentation
> I can see, that there are basically two methods to route INSERTS into
> partitioned table:
> one. is a TRIGGER
> other. is a RULE
>
> My Table will have over 1000 partitions. Some not so big, but
> significant number of them will be of multimillion rows. Partitioning
> will be done using a single column, on equality.... meaning:
>
> CREATE TABLE mainlog (sel int, tm timestamp, info text,...);
> CREATE TABLE mainlog_p1 (CHECK (sel=1)) INHERITS (mainlog);
> CREATE TABLE mainlog_p2 (CHECK (sel=2)) INHERITS (mainlog);
> ...etc.
>
> If I route INSERT with a TRIGGER, the function would look like:
> CREATE .... TRIGGER...AS $$ DECLARE x RECORD; BEGIN
> SELECT id INTO x FROM current_route; NEW.sel := x.id;
> IF NEW.sel = 1 THEN INSERT INTO mainlog_p1 VALUES (NEW.*);
> ELSE IF NEW.sel = 2 THEN INSERT INTO mainlog_p2 VALUES (NEW.*);
> ....
> END IF;
> RETURN NULL;
> $$;
>
> If I route INSETS with a RULE, I'd have something like 1000 rules hooked
> up to MAINLOG, all looking like:
> CREATE RULE .... ON INSERT ... WHERE EXISTS(SELECT 1 FROM current_route
> WHERE id = 1) DO INSTEAD INSERT INTO mainlog_p1 VALUES SELECT
> x.id,new.tm... FROM (SELECT id FROM current_route) x;
> ... and similar RULES for cases "WHERE id = 2", etc.
>
> My question is, where should I expect better performance on those
> INSERTS).
>
> I would prefer a set of RULES (as I wouldn't like to rewrite TRIGGER
> function every time I add a partition ... a thousand lines function),
> but since they all must make a select query on CURRENT_ROUTE table, may
> be that will not be particularly effective? The TRIGGER function does a
> single query - may be it'll be faster? I was planning to generate some
> dummy data and run a simulation, but may be someone already has that
> experience? Or maybe the TRIGGER should look differently? Or the set of
> RULES?
>
I had a bit spare time so I tested this
see http://filip.rembialkowski.net/postgres-partitioning-performance-rules-vs-triggers/
seems that in your scenario trigger will be better.
but If I had to do this, and if performance was very important, I
would move "partition selection" logic out of the INSERT phase. the
application can know this before the actual insert. unless you want to
shift selections very often...
--
Filip Rembiałkowski
--
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] Verbosity of Function Return Type Checks
===================================================================
RCS file: /projects/cvsroot/pgsql/src/pl/plpgsql/src/pl_exec.c,v
retrieving revision 1.219
diff -c -r1.219 pl_exec.c
*** src/pl/plpgsql/src/pl_exec.c 1 Sep 2008 22:30:33 -0000 1.219
--- src/pl/plpgsql/src/pl_exec.c 5 Sep 2008 13:47:07 -0000
***************
*** 188,194 ****
Oid reqtype, int32 reqtypmod,
bool isnull);
static void exec_init_tuple_store(PLpgSQL_execstate *estate);
! static bool compatible_tupdesc(TupleDesc td1, TupleDesc td2);
static void exec_set_found(PLpgSQL_execstate *estate, bool state);
static void plpgsql_create_econtext(PLpgSQL_execstate *estate);
static void free_var(PLpgSQL_var *var);
--- 188,195 ----
Oid reqtype, int32 reqtypmod,
bool isnull);
static void exec_init_tuple_store(PLpgSQL_execstate *estate);
! static void validate_tupdesc_compat(TupleDesc expected, TupleDesc returned,
! const char *msg);
static void exec_set_found(PLpgSQL_execstate *estate, bool state);
static void plpgsql_create_econtext(PLpgSQL_execstate *estate);
static void free_var(PLpgSQL_var *var);
***************
*** 384,394 ****
{
case TYPEFUNC_COMPOSITE:
/* got the expected result rowtype, now check it */
! if (estate.rettupdesc == NULL ||
! !compatible_tupdesc(estate.rettupdesc, tupdesc))
! ereport(ERROR,
! (errcode(ERRCODE_DATATYPE_MISMATCH),
! errmsg("returned record type does not match expected record type")));
break;
case TYPEFUNC_RECORD:
--- 385,392 ----
{
case TYPEFUNC_COMPOSITE:
/* got the expected result rowtype, now check it */
! validate_tupdesc_compat(tupdesc, estate.rettupdesc,
! "returned record type does not match expected record type");
break;
case TYPEFUNC_RECORD:
***************
*** 705,715 ****
rettup = NULL;
else
{
! if (!compatible_tupdesc(estate.rettupdesc,
! trigdata->tg_relation->rd_att))
! ereport(ERROR,
! (errcode(ERRCODE_DATATYPE_MISMATCH),
! errmsg("returned tuple structure does not match table of trigger event")));
/* Copy tuple to upper executor memory */
rettup = SPI_copytuple((HeapTuple) DatumGetPointer(estate.retval));
}
--- 703,711 ----
rettup = NULL;
else
{
! validate_tupdesc_compat(trigdata->tg_relation->rd_att,
! estate.rettupdesc,
! "returned tuple structure does not match table of trigger event");
/* Copy tuple to upper executor memory */
rettup = SPI_copytuple((HeapTuple) DatumGetPointer(estate.retval));
}
***************
*** 2199,2209 ****
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("record \"%s\" is not assigned yet",
rec->refname),
! errdetail("The tuple structure of a not-yet-assigned record is indeterminate.")));
! if (!compatible_tupdesc(tupdesc, rec->tupdesc))
! ereport(ERROR,
! (errcode(ERRCODE_DATATYPE_MISMATCH),
! errmsg("wrong record type supplied in RETURN NEXT")));
tuple = rec->tup;
}
break;
--- 2195,2204 ----
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("record \"%s\" is not assigned yet",
rec->refname),
! errdetail("The tuple structure of a not-yet-assigned"
! " record is indeterminate.")));
! validate_tupdesc_compat(tupdesc, rec->tupdesc,
! "wrong record type supplied in RETURN NEXT");
tuple = rec->tup;
}
break;
***************
*** 2309,2318 ****
stmt->params);
}
! if (!compatible_tupdesc(estate->rettupdesc, portal->tupDesc))
! ereport(ERROR,
! (errcode(ERRCODE_DATATYPE_MISMATCH),
! errmsg("structure of query does not match function result type")));
while (true)
{
--- 2304,2311 ----
stmt->params);
}
! validate_tupdesc_compat(estate->rettupdesc, portal->tupDesc,
! "structure of query does not match function result type");
while (true)
{
***************
*** 5145,5167 ****
}
/*
! * Check two tupledescs have matching number and types of attributes
*/
! static bool
! compatible_tupdesc(TupleDesc td1, TupleDesc td2)
{
! int i;
! if (td1->natts != td2->natts)
! return false;
! for (i = 0; i < td1->natts; i++)
! {
! if (td1->attrs[i]->atttypid != td2->attrs[i]->atttypid)
! return false;
! }
! return true;
}
/* ----------
--- 5138,5174 ----
}
/*
! * Validates compatibility of supplied TupleDesc pair by checking number and type
! * of attributes.
*/
! static void
! validate_tupdesc_compat(TupleDesc expected, TupleDesc returned, const char *msg)
{
! int i;
! if (!expected || !returned)
! ereport(ERROR,
! (errcode(ERRCODE_DATATYPE_MISMATCH),
! errmsg("%s", msg)));
! if (expected->natts != returned->natts)
! ereport(ERROR,
! (errcode(ERRCODE_DATATYPE_MISMATCH),
! errmsg("%s", msg),
! errdetail("Number of returned columns (%d) does not match expected column count (%d).",
! returned->natts, expected->natts)));
! for (i = 0; i < expected->natts; i++)
! if (expected->attrs[i]->atttypid != returned->attrs[i]->atttypid)
! ereport(ERROR,
! (errcode(ERRCODE_DATATYPE_MISMATCH),
! errmsg("%s", msg),
! errdetail("Returned type \"%s\" does not match expected type \"%s\" in column \"%s\".",
! format_type_with_typemod(returned->attrs[i]->atttypid,
! returned->attrs[i]->atttypmod),
! format_type_with_typemod(expected->attrs[i]->atttypid,
! expected->attrs[i]->atttypmod),
! NameStr(expected->attrs[i]->attname))));
}
/* ----------
On Fri, 5 Sep 2008, Alvaro Herrera <alvherre@commandprompt.com> writes:
> Please use the patch I posted yesterday, as it had all the issues I
> found fixed. There were other changes in that patch too.
My bad. Patch is modified with respect to suggestions[1][2] from
Tom. (All 115 tests passed in cvs tip.)
Regards.
[1] "char *msg" is replaced with "const char *msg".
[2] "errmsg(msg)" is replaced with 'errmsg("%s", msg)'.
Re: [HACKERS] 8.4devel out of memory
> ERROR: out of memory
> DETAIL: Failed on request of size 8.
> What would be the reasonable next step here?
I bet the log would be of interest. :-)
-Kevin
[COMMITTERS] npgsql - Npgsql2: Fixed ClearAllPools which were missing a line to
-----------
Fixed ClearAllPools which were missing a line to remove the ConnectorsList. Thanks Christian Holzner (support at tuga dot it) for heads up and patch.
Modified Files:
--------------
Npgsql2/src/Npgsql:
NpgsqlConnectorPool.cs (r1.11 -> r1.12)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/npgsql/Npgsql2/src/Npgsql/NpgsqlConnectorPool.cs.diff?r1=1.11&r2=1.12)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Re: [HACKERS] Need more reviewers!
> >
> > I think this should be organised with different kinds of reviewer:
>
> The list is correct but too verbose. And it does not attack the core
> of the problem. I think the problem is not:
>
> What can/should I do?
>
> but instead:
>
> Can I take the responsibility?
Completely agree. The list was really an example of the different styles
of review that are possible, not a rigid categorisation that must be
followed.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[COMMITTERS] plproxy - plproxy: update
-----------
update
Modified Files:
--------------
plproxy:
AUTHORS (r1.3 -> r1.4)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/plproxy/plproxy/AUTHORS.diff?r1=1.3&r2=1.4)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] stackbuilder - wizard: Allow installed apps to be reinstalled.
-----------
Allow installed apps to be reinstalled.
Modified Files:
--------------
wizard:
AppList.cpp (r1.18 -> r1.19)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/stackbuilder/wizard/AppList.cpp.diff?r1=1.18&r2=1.19)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Re: [HACKERS] Need more reviewers!
> On Fri, 2008-09-05 at 16:03 +0200, Markus Wanner wrote:
> > > I don't *want* the rule, I just think we *need* the rule because
> > > otherwise sponsors/managers/etc make business decisions to exclude that
> > > aspect of the software dev process.
> >
> > I agree that making sponsors/managers/etc aware of that aspect of the
> > dev process is necessary and worthwhile. However, I don't think a rule
> > for *patch submitters* helps with that. There must be other ways to
> > convince managers to encourage reviewers.
>
> Such as? You might think those arguments exist and work, but I would say
> they manifestly do not. Almost all people doing reviews are people that
> have considerable control over their own time, or are directed by people
> that understand the Postgres review process and wish to contribute to it
> for commercial reasons.
Well, the number of companies who are *interested* their patches getting
in is rather small... I think it's more common for companies to think
they are already donating to Postgres by encouraging their staff to
write patches and publish them.
So such applying such strict policy for everyone seems bad idea.
Although I quite agree on strongly encouraging patch submitters to review.
And those 3-4 companies who have direct commercial interests in Postgres
development should probably internally rethink their time allocation.
Note also we are only on our 2nd commitfest so its quite normal that
people are not used to the process .
We need to work few political aspects:
* Making reviewers to more at ease.
* Encouraging patch submitters to review.
And technical aspects:
* The (hopefully short and relaxed) rules for reviewers should be
more visible. Best would be on (every) Commitfest page.
* Wiki editing rules should be visible.
Well, and then:
* Although the wiki looks nice it's pain to operate.
--
marko
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers