Re: [PATCHES] "fix" for plpgsql polymorphism
On Wed, Jul 02, 2003 at 07:31:28PM -0700, Joe Conway wrote: I haven't looked at the plpgsql code so IMBFOS, but > + /* > + * Normal return values get a var node > + */ > + var = malloc(sizeof(PLpgSQL_var)); > + memset(var, 0, sizeof(PLpgSQL_var)); why is this a malloc() and not palloc()? And when/where/how is it freed? -- Alvaro Herrera () "El Maquinismo fue proscrito so pena de cosquilleo hasta la muerte" (Ijon Tichy en Viajes, Stanislaw Lem) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] "fix" for plpgsql polymorphism
On Thu, Jul 03, 2003 at 12:11:36AM -0400, Tom Lane wrote: > Joe Conway <[EMAIL PROTECTED]> writes: > > Alvaro Herrera wrote: > >> why is this a malloc() and not palloc()? And when/where/how is it freed? > > > It isn't, at least not until the backend exits ;-) > > > This is how plpgsql is done throughout, pretty much. It's not so bad > > when you remember that plpgsql functions are "compiled" once, and then > > cached for future calls by the same backend. > > I think palloc would actually be wrong there, because it would allocate > memory that would go away soon (certainly not later than end of > transaction) whereas the structure needs to live as long as the plpgsql > function cache entry does. Without a switch into a suitably-long-lived > context, this code can't use palloc. That'd be TopMemoryContext. Not too much a win, I think. Maybe each plpgsql function should have it's own context, destroyed by CREATE OR REPLACE FUNCTION, for example. -- Alvaro Herrera () "I dream about dreams about dreams", sang the nightingale under the pale moon (Sandman) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[PATCHES] updated libpq spanish translation
One untranslated message ("NOTICE"). Please install.
$ msgfmt -c -v po/es.po
99 mensajes traducidos, 1 mensaje sin traducir.
--
Alvaro Herrera ()
Voy a acabar con todos los humanos / con los humanos yo acabaré
voy a acabar con todos / con todos los humanos acabaré (Bender)
# Spanish message translation file for libpq
# Karim <[EMAIL PROTECTED]>, 2002.
# Updated on august 2003 by Alvaro Herrera <[EMAIL PROTECTED]>
msgid ""
msgstr ""
"Project-Id-Version: PostgreSQL 7.4\n"
"POT-Creation-Date: 2003-08-23 23:14-0400\n"
"PO-Revision-Date: 2003-08-23 23:29-0400\n"
"Last-Translator: Álvaro Herrera <[EMAIL PROTECTED]>\n"
"Language-Team: Karim Mribti <[EMAIL PROTECTED]>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=ISO-8859-1\n"
"Content-Transfer-Encoding: 8bit\n"
#: fe-auth.c:232
#, c-format
msgid "Kerberos 4 error: %s\n"
msgstr "error de Kerberos 4: %s\n"
#: fe-auth.c:394
#, c-format
msgid "could not set socket to blocking mode: %s\n"
msgstr "no se ha podido poner el socket en modo de bloqueo: %s\n"
#: fe-auth.c:411 fe-auth.c:415
#, c-format
msgid "Kerberos 5 authentication rejected: %*s\n"
msgstr "autentificación Kerberos 5 denegada: %*s\n"
#: fe-auth.c:441
#, c-format
msgid "could not restore non-blocking mode on socket: %s\n"
msgstr "no se ha podido restablecer el modo de no bloqueo en el socket: %s\n"
#: fe-auth.c:509
msgid "SCM_CRED authentication method not supported\n"
msgstr "el método de autentificación SCM_CRED no está soportado\n"
#: fe-auth.c:600
msgid "Kerberos 4 authentication failed\n"
msgstr "autentificación Kerberos 4 fallida\n"
#: fe-auth.c:606
msgid "Kerberos 4 authentication not supported\n"
msgstr "el método de autentificación Kerberos 4 no está soportado\n"
#: fe-auth.c:616
msgid "Kerberos 5 authentication failed\n"
msgstr "autentificación Kerberos 5 fallida\n"
#: fe-auth.c:622
msgid "Kerberos 5 authentication not supported\n"
msgstr "el método de autentificación Kerberos 5 no está soportado\n"
#: fe-auth.c:650
#, c-format
msgid "authentication method %u not supported\n"
msgstr "el método de autentificación %u no está soportado\n"
#: fe-auth.c:687
#, c-format
msgid "invalid authentication service name \"%s\", ignored\n"
msgstr "nombre de servicio de autentificación \"%s\" no válido, ignorado\n"
#: fe-auth.c:758
#, c-format
msgid "fe_getauthname: invalid authentication system: %d\n"
msgstr "fe_getauthname: sistema de autentificación no válido: %d\n"
#: fe-connect.c:451
#, c-format
msgid "unrecognized sslmode: \"%s\"\n"
msgstr "modo ssl no reconocido: \"%s\"\n"
#: fe-connect.c:469
#, c-format
msgid "sslmode \"%s\" invalid when SSL support is not compiled in\n"
msgstr ""
"modo ssl \"%s\" no es válido cuando no se ha compilado con soporte SSL\n"
#: fe-connect.c:781
#, c-format
msgid "could not set socket to non-blocking mode: %s\n"
msgstr "no se ha podido establecer el socket en modo de no-bloqueo: %s\n"
#: fe-connect.c:808
#, c-format
msgid "could not set socket to TCP no delay mode: %s\n"
msgstr "no se ha podido establecer el socket en modo TCP sin retardo: %s\n"
#: fe-connect.c:839
#, c-format
msgid ""
"could not connect to server: %s\n"
"\tIs the server running locally and accepting\n"
"\tconnections on Unix domain socket \"%s\"?\n"
msgstr ""
"no se ha podido conectar con el servidor: %s\n"
"\t¿Está el servidor en ejecución local y acepta \n"
"\tconexiónes en el socket de dominio Unix \"%s\"?\n"
#: fe-connect.c:851
#, c-format
msgid ""
"could not connect to server: %s\n"
"\tIs the server running on host \"%s\" and accepting\n"
"\tTCP/IP connections on port %s?\n"
msgstr ""
"no se ha podido conectar con el servidor: %s\n"
"\t¿Está el servidor en ejecución en el host %s y acepta \n"
"\tconexiones TCP/IP en el puerto %s?\n"
#: fe-connect.c:935
#, c-format
msgid "could not translate hostname \"%s\" to address: %s\n"
msgstr "no se pudo traducir el nombre \"%s\" a una dirección: %s\n"
#: fe-connect.c:939
#, c-format
msgid "could not translate local service to address: %s\n"
msgstr "no se pudo traducir servicio local a dirección: %s\n"
#: fe-connect.c:1141
msgid "invalid connection state, probably indicative of memory corruption\n"
msgstr "estado de conexión no válido, probablemente por
[PATCHES] psql spanish l10n
Attached is a (new) spanish PO file for psql: $ LANG= msgfmt -v -c po/es.po 269 translated messages, 2 untranslated messages. Please install. Don't forget to add to nls.mk... Thanks. -- Alvaro Herrera () Voy a acabar con todos los humanos / con los humanos yo acabaré voy a acabar con todos / con todos los humanos acabaré (Bender) # translation of psql. # This file is put in the public domain. # <[EMAIL PROTECTED]>, 2003. # <[EMAIL PROTECTED]>, 2003. # msgid "" msgstr "" "Project-Id-Version: PostgreSQL 7.4\n" "POT-Creation-Date: 2003-08-23 23:45-0400\n" "PO-Revision-Date: 2003-08-24 14:22-0400\n" "Last-Translator: Álvaro Herrera <[EMAIL PROTECTED]>\n" "Language-Team: Hackers <[EMAIL PROTECTED]>\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=iso-8859-1\n" "Content-Transfer-Encoding: 8bit\n" #: command.c:154 msgid "Warning: This syntax is deprecated.\n" msgstr "Atención: esta sintaxis está obsoleta.\n" #: command.c:161 #, c-format msgid "Invalid command \\%s. Try \\? for help.\n" msgstr "Comando \\%s no válido. Use \\? para obtener ayuda.\n" #: command.c:163 #, c-format msgid "invalid command \\%s\n" msgstr "comando \\%s no válido\n" #: command.c:290 #, c-format msgid "could not get home directory: %s\n" msgstr "No se ha podido obtener directorio home: %s\n" #: command.c:306 #, c-format msgid "\\%s: could not change directory to \"%s\": %s\n" msgstr "\\%s: no se pudo cambiar directorio a \"%s\": %s\n" #: command.c:411 command.c:780 msgid "no query buffer\n" msgstr "no hay búfer de consulta\n" #: command.c:476 #, c-format msgid "%s: invalid encoding name or conversion procedure not found\n" msgstr "" "%s: nombre de codificación no válido o procedimiento de conversión\n" "no encontrado\n" #: command.c:538 command.c:569 command.c:580 command.c:594 command.c:636 #: command.c:760 command.c:789 #, c-format msgid "\\%s: missing required argument\n" msgstr "\\%s: falta argumento requerido\n" #: command.c:624 msgid "Query buffer is empty." msgstr "El búfer de consulta está vacío." #: command.c:657 msgid "Query buffer reset (cleared)." msgstr "El búfer de consulta ha sido reiniciado (limpiado)." #: command.c:668 #, c-format msgid "Wrote history to file \"%s\".\n" msgstr "Se escribió historial a archivo \"%s\".\n" #: command.c:700 command.c:1160 command.c:1257 command.c:1975 common.c:81 #: copy.c:88 copy.c:116 mainloop.c:78 mainloop.c:340 describe.c:51 msgid "out of memory\n" msgstr "memoria agotada\n" #: command.c:715 command.c:765 #, c-format msgid "\\%s: error\n" msgstr "\\%s: error\n" #: command.c:804 command.c:824 command.c:1022 command.c:1035 command.c:1046 #: command.c:1617 command.c:1630 command.c:1642 command.c:1655 command.c:1669 #: command.c:1691 command.c:1721 common.c:130 copy.c:379 #, c-format msgid "%s: %s\n" msgstr "%s: %s\n" #: command.c:890 #, c-format msgid "\\%s: extra argument \"%s\" ignored\n" msgstr "\\%s: argumento extra \"%s\" ignorado\n" #: command.c:983 command.c:1011 command.c:1133 msgid "parse error at the end of line\n" msgstr "error de procesamiento en el fin de línea\n" #: command.c:1362 command.c:1386 startup.c:176 startup.c:194 msgid "Password: " msgstr "Contraseña: " #: command.c:1400 common.c:176 common.c:346 common.c:396 common.c:612 #, c-format msgid "%s" msgstr "%s" #: command.c:1404 msgid "Previous connection kept\n" msgstr "Se ha mantenido la conexión anterior\n" #: command.c:1416 #, c-format msgid "\\connect: %s" msgstr "\\connect: %s" #: command.c:1428 #, c-format msgid "You are now connected to database \"%s\".\n" msgstr "Ahora está conectado a la base de datos \"%s\".\n" #: command.c:1430 #, c-format msgid "You are now connected as new user \"%s\".\n" msgstr "Ahora está conectado como el usuario \"%s\".\n" #: command.c:1433 #, c-format msgid "You are now connected to database \"%s\" as user \"%s\".\n" msgstr "" "Ahora está conectado a la base de datos \"%s\"\n" "con el usuario \"%s\".\n" #: command.c:1555 #, c-format msgid "could not start editor \"%s\"\n" msgstr "no se ha podido iniciar el editor \"%s\"\n" #: command.c:1557 msgid "could not start /bin/sh\n" msgstr "no se ha podido iniciar /bin/sh\n" #: command.c:
[PATCHES] small typos
Patchers,
This fixes three minor typos in hba.c.
--
Alvaro Herrera ()
"There was no reply" (Kernel Traffic)
Index: src/backend/libpq/hba.c
===
RCS file: /home/alvherre/cvs/pgsql-server/src/backend/libpq/hba.c,v
retrieving revision 1.108
diff -c -r1.108 hba.c
*** src/backend/libpq/hba.c 26 Jul 2003 13:50:02 - 1.108
--- src/backend/libpq/hba.c 24 Aug 2003 23:22:03 -
***
*** 1289,1295
{
ereport(LOG,
(errcode_for_socket_access(),
!errmsg("could not connect to IDENT server at address
\"%s\", port %s): %m",
remote_addr_s, ident_port)));
ident_return = false;
goto ident_inet_done;
--- 1289,1295
{
ereport(LOG,
(errcode_for_socket_access(),
!errmsg("could not connect to IDENT server at address
\"%s\", port %s: %m",
remote_addr_s, ident_port)));
ident_return = false;
goto ident_inet_done;
***
*** 1309,1315
{
ereport(LOG,
(errcode_for_socket_access(),
!errmsg("could not send query to IDENT server at
address \"%s\", port %s): %m",
remote_addr_s, ident_port)));
ident_return = false;
goto ident_inet_done;
--- 1309,1315
{
ereport(LOG,
(errcode_for_socket_access(),
!errmsg("could not send query to IDENT server at
address \"%s\", port %s: %m",
remote_addr_s, ident_port)));
ident_return = false;
goto ident_inet_done;
***
*** 1324,1330
{
ereport(LOG,
(errcode_for_socket_access(),
!errmsg("could not receive response from IDENT server
at address \"%s\", port %s): %m",
remote_addr_s, ident_port)));
ident_return = false;
goto ident_inet_done;
--- 1324,1330
{
ereport(LOG,
(errcode_for_socket_access(),
!errmsg("could not receive response from IDENT server
at address \"%s\", port %s: %m",
remote_addr_s, ident_port)));
ident_return = false;
goto ident_inet_done;
---(end of broadcast)---
TIP 8: explain analyze is your friend
[PATCHES] message not following the guidelines
This message seems to be breaking the message guidelines.
--
Alvaro Herrera ()
"Porque francamente, si para saber manejarse a uno mismo hubiera que
rendir examen... ¿Quién es el machito que tendría carnet?" (Mafalda)
Index: opclasscmds.c
===
RCS file: /respaldo/alvherre/cvs/pgsql-server/src/backend/commands/opclasscmds.c,v
retrieving revision 1.18
diff -c -r1.18 opclasscmds.c
*** opclasscmds.c 17 Aug 2003 19:58:04 - 1.18
--- opclasscmds.c 11 Sep 2003 02:08:19 -
***
*** 195,201
if (procedures[item->number - 1] != InvalidOid)
ereport(ERROR,
(errcode(ERRCODE_INVALID_OBJECT_DEFINITION),
!errmsg("DefineOpClass:
procedure number %d appears more than once",
item->number)));
funcOid = LookupFuncNameTypeNames(item->name,
item->args,
false);
--- 195,201
if (procedures[item->number - 1] != InvalidOid)
ereport(ERROR,
(errcode(ERRCODE_INVALID_OBJECT_DEFINITION),
!errmsg("procedure number %d
appears more than once",
item->number)));
funcOid = LookupFuncNameTypeNames(item->name,
item->args,
false);
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[PATCHES] NLS changes
Patchers,
Here is a patch related to NLS that
- adds .y files to gettext-files in backend/nls.mk. gram.y contains
several translatable messages that are not catched by update-po unless
the gram.c file is generated. I don't know if this is desirable but I
think it's better to have to gram.y file processed.
Maybe this part of the patch could be left out (it's the first,
trivial chunk).
- makes more translator-friendly the messages in gram.y, because a lot
of them are only a keyword away of being equal. This avoids having
the translator process the same thing several times.
- adds a couple of comments for the translator (I had to peek at the
source code to see what the %s was about, so I guess this is needed).
Also, I've noted that psql's \h messages are not translatable. Is there
a way to make them so?
I have the backend messages almost done:
$ LANG= msgfmt -c -v es.po
1757 translated messages, 29 untranslated messages.
I'll submit after I resolve a couple of translations that are not clear.
--
Alvaro Herrera ()
"La victoria es para quien se atreve a estar solo"
Index: nls.mk
===
RCS file: /home/alvherre/cvs/pgsql-server/src/backend/nls.mk,v
retrieving revision 1.6
diff -c -r1.6 nls.mk
*** nls.mk 28 Jul 2003 00:25:21 - 1.6
--- nls.mk 13 Sep 2003 03:52:55 -
***
*** 7,13
GETTEXT_TRIGGERS:= errmsg errdetail errhint errcontext postmaster_error yyerror
gettext-files:
! find $(srcdir)/ -name '*.c' -print >$@
my-maintainer-clean:
rm -f gettext-files
--- 7,13
GETTEXT_TRIGGERS:= errmsg errdetail errhint errcontext postmaster_error yyerror
gettext-files:
! find $(srcdir)/ -name '*.[cy]' -print >$@
my-maintainer-clean:
rm -f gettext-files
Index: parser/gram.y
===
RCS file: /home/alvherre/cvs/pgsql-server/src/backend/parser/gram.y,v
retrieving revision 2.432
diff -c -r2.432 gram.y
*** parser/gram.y 9 Sep 2003 23:22:20 - 2.432
--- parser/gram.y 14 Sep 2003 05:57:58 -
***
*** 969,982
if ($3 < 0)
ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
!errmsg("INTERVAL(%d)
precision must not be negative",
! $3)));
if ($3 > MAX_INTERVAL_PRECISION)
{
ereport(NOTICE,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
!errmsg("INTERVAL(%d)
precision reduced to maximum allowed, %d",
! $3,
MAX_INTERVAL_PRECISION)));
$3 = MAX_INTERVAL_PRECISION;
}
--- 969,984
if ($3 < 0)
ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
!/* translator: %s is
a type name (INTERVAL, TIMESTAMP, etc) */
!errmsg("%s(%d)
precision must not be negative",
!
"INTERVAL", $3)));
if ($3 > MAX_INTERVAL_PRECISION)
{
ereport(NOTICE,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
!/* translator: %s is
a type name (INTERVAL, TIMESTAMP, etc) */
!errmsg("%s(%d)
precision reduced to maximum allowed, %d",
!
"INTERVAL", $3, MAX_INTERVAL_PRECISION)));
$3 = MAX_INTERVAL_PRECISION;
}
***
*** 5086,5099
if ($3 < 0)
ereport(ERROR,
Re: [PATCHES] NLS changes
On Sun, Sep 14, 2003 at 02:14:22AM -0400, Alvaro Herrera wrote: > - adds .y files to gettext-files in backend/nls.mk. gram.y contains > several translatable messages that are not catched by update-po unless > the gram.c file is generated. I don't know if this is desirable but I > think it's better to have to gram.y file processed. > Maybe this part of the patch could be left out (it's the first, > trivial chunk). I just realized that scan.l should also be included, because there are four or five strings in there. But maybe the pot should instead be generated on a non-clean tree so those strings are extracted from the .c files? I downloaded the postgres.pot file from http://developer.postgresql.org/~petere/ and those strings are not included there. -- Alvaro Herrera () "Tiene valor aquel que admite que es un cobarde" (Fernandel) ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [BUGS] bug in clusterdb script
On Sat, Sep 27, 2003 at 08:02:17PM -0400, Bruce Momjian wrote: > > Your patch has been added to the PostgreSQL unapplied patches list at: > > http://momjian.postgresql.org/cgi-bin/pgpatches > > I will try to apply it within the next 48 hours. Keep in mind that this applies to the 7.3 branch only, because in 7.4 the script got reimplemented. -- Alvaro Herrera () "The Gord often wonders why people threaten never to come back after they've been told never to return" (www.actsofgord.com) ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[PATCHES] more spanish updates
Peter, Attached are psql and libpq spanish PO files, 100% translated. $ LC_MESSAGES=C msgfmt -c -v libpq-es.po 100 translated messages. $ LC_MESSAGES=C msgfmt -c -v psql-es.po 453 translated messages. Please install. -- Alvaro Herrera () "Por suerte hoy explotó el califont porque si no me habría muerto de aburrido" (Papelucho) psql-es.po.gz Description: Binary data libpq-es.po.gz Description: Binary data ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] more spanish updates
On Sat, Oct 04, 2003 at 08:13:23PM +0200, Peter Eisentraut wrote: > Alvaro Herrera writes: > > > Attached are psql and libpq spanish PO files, 100% translated. > > Installed. Thanks. Did you get this one? http://archives.postgresql.org/pgsql-patches/2003-10/msg9.php (backend translation) -- Alvaro Herrera () "The problem with the future is that it keeps turning into the present" (Hobbes) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] spanish translation updates
Peter, Attached are pg_controldata, pgscripts and libpq spanish translations. I will be asking for review from the rest of the spanish group so there probably will be more updates as we get the style polished. Please install. Thanks. -- Alvaro Herrera () "El que vive para el futuro es un iluso, y el que vive para el pasado, un imbécil" (Luis Adler, "Los tripulantes de la noche") libpq-es.po.gz Description: Binary data pg_controldata-es.po.gz Description: Binary data pgscripts-es.po.gz Description: Binary data ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [Fwd: [PATCHES] Make psql use all pretty print options]
On Fri, Oct 10, 2003 at 12:42:50PM +0800, Christopher Kings-Lynne wrote: > OK, for reviewers. Note the index predicate and the check constraint in > particular. It seems to have the nice property of allowing output to be copy-n-pasted without further modification. -- Alvaro Herrera () "The Gord often wonders why people threaten never to come back after they've been told never to return" (www.actsofgord.com) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] spanish updates, take 2
I attach the whole spanish PO catalogs again, correcting some typos. They are at 100% again. I already posted them three days ago, but they got lost probably because the size of the mail. I will post the backend and libpq catalog separately. -- Alvaro Herrera () Si no sabes adonde vas, es muy probable que acabes en otra parte. libpq-es.po.gz Description: Binary data pg_controldata-es.po.gz Description: Binary data pg_dump-es.po.gz Description: Binary data pg_resetxlog-es.po.gz Description: Binary data scripts-es.po.gz Description: Binary data ---(end of broadcast)--- TIP 8: explain analyze is your friend
[PATCHES] spanish psql update
The spanish psql message catalog is attached. -- Alvaro Herrera () "La gente vulgar solo piensa en pasar el tiempo; el que tiene talento, en aprovecharlo" psql-es.po.gz Description: Binary data ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[PATCHES] spanish pg_dump catalog
One string added and some typos corrected. Please install. -- Alvaro Herrera () "La experiencia nos dice que el hombre peló millones de veces las patatas, pero era forzoso admitir la posibilidad de que en un caso entre millones, las patatas pelarían al hombre" (Ijon Tichy) pg_dump-es.po.gz Description: Binary data ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [HACKERS] BEGIN vs START TRANSACTION
On Mon, Nov 10, 2003 at 11:23:20AM -0500, Tom Lane wrote: > IIRC, the code patch only added about two lines to gram.y. It seems a > bit silly to add *more* lines of documentation to explain that the two > statements aren't alike than it would take lines of code to make them > work alike. But maybe it would be useful to point out the difference; for example, users will get confused if they try to start a subtransaction inside a plpgsql function using BEGIN. -- Alvaro Herrera () "El miedo atento y previsor es la madre de la seguridad" (E. Burke) ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] ALTER TABLE modifications
On Fri, Nov 14, 2003 at 08:59:05AM -0500, Dave Cramer wrote: > I tried the current patch on a RC2 release, and I noticed one > undesirable side affect. > > Modifying a column moves it to the end. In high availability situations > this would not be desirable, I would imagine it would break lots of > code. This is expected. Doing otherwise would incur into a much bigger performance hit. Anyway, IMHO no code should use SELECT * in any case, which is the only scenario where one would expect physical column order to matter, isn't it? -- Alvaro Herrera () "La primera ley de las demostraciones en vivo es: no trate de usar el sistema. Escriba un guión que no toque nada para no causar daños." (Jakob Nielsen) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] introduce "default_use_oids"
On Mon, Dec 01, 2003 at 05:07:40PM -0500, Bruce Momjian wrote: > Neil Conway wrote: > > This patch adds a new GUC var, "default_use_oids", which follows the > > proposal for eventually deprecating OIDs on user tables that I posted > > earlier to pgsql-hackers. pg_dump now always specifies WITH OIDS or > > WITHOUT OIDS when dumping a table. The documentation has been updated. > > > > Comments are welcome. Hum, sorry to be late, but wasn't one of the supposed strenghts of pg_dump supposed to be that you could take a dump and load it on a different RDBMS? I haven't tried it so I don't know if it works, but this patch takes out the ability to do that -- no one else will accept WITH/WITHOUT OIDS, so the dump will have to be modified. Is a switch provided to stop the emission of those modifiers? -- Alvaro Herrera () "Escucha y olvidarás; ve y recordarás; haz y entenderás" (Confucio) ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] fork/exec patch
On Sun, Dec 14, 2003 at 06:53:22PM -0500, Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > I don't think we ever discussed it, but it seemed logical and a minimal > > change to the code. We already have a GUC write of non-default values > > for exec and no one had issues with that. > > You can hardly claim that "no one had issues with that". I complained > about it and I think other people did too. It's a messy, ugly approach; > moreover we have no field experience that says it's reliable. Don't the FSM and the system catalog cache use a similar mechanism? -- Alvaro Herrera () "Limítate a mirar... y algun día veras" ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] Alpha test
On Mon, Dec 22, 2003 at 06:36:32PM -0500, Bruce Momjian wrote: > Seems we have to test for __alpha and __alpha_. This applied patch > makes that consistent. Won't something like the following work? #ifdef(__alpha) #define __alpha__ 1 #endif so you only have to test for one of them? Just an idea. -- Alvaro Herrera () Si no sabes adonde vas, es muy probable que acabes en otra parte. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[PATCHES] trivial typos
Attached is a patch that fixes some trivial typos and alignment. Please
apply.
--
Alvaro Herrera ()
"Siempre hay que alimentar a los dioses, aunque la tierra esté seca" (Orual)
diff -cr --exclude=CVS 00orig/src/backend/access/transam/xact.c
01trivial/src/backend/access/transam/xact.c
*** 00orig/src/backend/access/transam/xact.c2004-01-15 23:32:18.0 -0300
--- 01trivial/src/backend/access/transam/xact.c 2004-01-15 23:34:42.0 -0300
***
*** 87,93
*
*Support for transaction blocks is provided via the functions:
*
! *StartTransactionBlock
*CommitTransactionBlock
*AbortTransactionBlock
*
--- 87,93
*
*Support for transaction blocks is provided via the functions:
*
! *BeginTransactionBlock
*CommitTransactionBlock
*AbortTransactionBlock
*
***
*** 108,114
*
*/ StartTransactionCommand();
*1) /ProcessUtility(); << begin
! * \StartTransactionBlock();
*\ CommitTransactionCommand();
*
*/ StartTransactionCommand();
--- 108,114
*
*/ StartTransactionCommand();
*1) /ProcessUtility(); << begin
! * \BeginTransactionBlock();
*\ CommitTransactionCommand();
*
*/ StartTransactionCommand();
***
*** 127,133
*The point of this example is to demonstrate the need for
*StartTransactionCommand() and CommitTransactionCommand() to
*be state smart -- they should do nothing in between the calls
! *to StartTransactionBlock() and EndTransactionBlock() and
*outside these calls they need to do normal start/commit
*processing.
*
--- 127,133
*The point of this example is to demonstrate the need for
*StartTransactionCommand() and CommitTransactionCommand() to
*be state smart -- they should do nothing in between the calls
! *to BeginTransactionBlock() and EndTransactionBlock() and
*outside these calls they need to do normal start/commit
*processing.
*
***
*** 399,405
{
TransactionState s = CurrentTransactionState;
! return (cid == s->commandId) ? true : false;
}
--- 399,405
{
TransactionState s = CurrentTransactionState;
! return (cid == s->commandId);
}
***
*** 860,866
AtStart_Locks();
/*
!* Tell the trigger manager to we're starting a transaction
*/
DeferredTriggerBeginXact();
--- 860,866
AtStart_Locks();
/*
!* Tell the trigger manager we're starting a transaction
*/
DeferredTriggerBeginXact();
diff -cr --exclude=CVS 00orig/src/include/access/xact.h
01trivial/src/include/access/xact.h
*** 00orig/src/include/access/xact.h2004-01-15 23:32:29.0 -0300
--- 01trivial/src/include/access/xact.h 2004-01-19 19:32:19.0 -0300
***
*** 75,86
*/
typedef struct TransactionStateData
{
! TransactionId transactionIdData;
! CommandId commandId;
! AbsoluteTime startTime;
! int startTimeUsec;
! TransState state;
! TBlockState blockState;
} TransactionStateData;
typedef TransactionStateData *TransactionState;
--- 75,86
*/
typedef struct TransactionStateData
{
! TransactionId transactionIdData;
! CommandId commandId;
! AbsoluteTimestartTime;
! int startTimeUsec;
! TransState state;
! TBlockState blockState;
} TransactionStateData;
typedef TransactionStateData *TransactionState;
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
[PATCHES] small smgr refactoring
I attach a small patch that slightly refactors some code in
storage/smgr/smgr.c. Regression test pass. There's no change in
functionality, only code reordering. (Well, it changes an ad-hoc linked
list into a proper List).
Please review and if Ok, apply.
--
Alvaro Herrera ()
"At least to kernel hackers, who really are human, despite occasional
rumors to the contrary" (LWN.net)
diff -cr --exclude=CVS 01trivial/src/backend/access/transam/xact.c
02smgr/src/backend/access/transam/xact.c
*** 01trivial/src/backend/access/transam/xact.c 2004-01-15 23:34:42.0 -0300
--- 02smgr/src/backend/access/transam/xact.c2004-01-19 19:37:54.0 -0300
***
*** 865,870
--- 865,875
DeferredTriggerBeginXact();
/*
+* Initialize the smgr subsystem
+*/
+ PendingDeletesBeginXact();
+
+ /*
* done with start processing, set current transaction state to "in
* progress"
*/
diff -cr --exclude=CVS 01trivial/src/backend/storage/smgr/smgr.c
02smgr/src/backend/storage/smgr/smgr.c
*** 01trivial/src/backend/storage/smgr/smgr.c 2004-01-15 23:33:55.0 -0300
--- 02smgr/src/backend/storage/smgr/smgr.c 2004-01-19 19:37:54.0 -0300
***
*** 97,105
* executed immediately, but is just entered in the list. When and if
* the transaction commits, we can delete the physical file.
*
! * NOTE: the list is kept in TopMemoryContext to be sure it won't disappear
! * unbetimes. It'd probably be OK to keep it in TopTransactionContext,
! * but I'm being paranoid.
*/
typedef struct PendingRelDelete
--- 97,104
* executed immediately, but is just entered in the list. When and if
* the transaction commits, we can delete the physical file.
*
! * NOTE: the list is kept in TopTransactionContext, so the items will
! * automatically disappear when the transaction ends.
*/
typedef struct PendingRelDelete
***
*** 108,118
int16 which; /* which storage manager? */
boolisTemp; /* is it a temporary relation? */
boolatCommit; /* T=delete at commit; F=delete at
abort */
- struct PendingRelDelete *next; /* linked-list link */
} PendingRelDelete;
! static PendingRelDelete *pendingDeletes = NULL; /* head of linked list */
/*
*smgrinit(), smgrshutdown() -- Initialize or shut down all storage
--- 107,118
int16 which; /* which storage manager? */
boolisTemp; /* is it a temporary relation? */
boolatCommit; /* T=delete at commit; F=delete at
abort */
} PendingRelDelete;
! static List *pendingDeletes;
+ static void smgrDeleteItem(PendingRelDelete *pending);
+ static void addPendingDelete(int16 which, Relation reln, bool atCommit);
/*
*smgrinit(), smgrshutdown() -- Initialize or shut down all storage
***
*** 168,174
smgrcreate(int16 which, Relation reln)
{
int fd;
- PendingRelDelete *pending;
if ((fd = (*(smgrsw[which].smgr_create)) (reln)) < 0)
ereport(ERROR,
--- 168,173
***
*** 177,190
RelationGetRelationName(reln;
/* Add the relation to the list of stuff to delete at abort */
! pending = (PendingRelDelete *)
! MemoryContextAlloc(TopMemoryContext, sizeof(PendingRelDelete));
! pending->relnode = reln->rd_node;
! pending->which = which;
! pending->isTemp = reln->rd_istemp;
! pending->atCommit = false; /* delete if abort */
! pending->next = pendingDeletes;
! pendingDeletes = pending;
return fd;
}
--- 176,182
RelationGetRelationName(reln;
/* Add the relation to the list of stuff to delete at abort */
! addPendingDelete(which, reln, false);
return fd;
}
***
*** 198,218
int
smgrunlink(int16 which, Relation reln)
{
- PendingRelDelete *pending;
/* Make sure the file is closed */
if (reln->rd_fd >= 0)
smgrclose(which, reln);
/* Add the relation to the list of stuff to delete at commit */
! pending = (PendingRelDelete *)
! MemoryContextAlloc(TopMemoryContext, sizeof(PendingRelDelete));
! pending->relnode = reln->rd_node;
! pending->which = which;
! pending->isTemp = reln->rd_istemp;
! pending->atCommit = true; /* delete if commit */
! pending->next = pendingDeletes;
! pendingDeletes = pending;
/*
* NOTE: if the relation was created in t
Re: [PATCHES] small smgr refactoring
On Mon, Jan 19, 2004 at 06:20:21PM -0500, Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > (Well, it changes an ad-hoc linked > > list into a proper List). > > Why? AFAICT that just makes the code bigger, uglier, and slower ... Oh, does it? Hmm. When I originally wrote this, it used FastList. The idea was that every subtransaction has its own FastList, and that at subtransaction commit, the list is appended to the parent's list. If the subtrasaction ends, the list is walked and each file created inside the subtransaction is deleted, and files marked for deletion are forgotten. (i.e. do nothing, and the structs are released when the memory context disappears.) It used FastList because append was a fast operation. It now uses List because Neil is going to make List fast at append ... now that you ask, it could probably just use lcons ... (OTOH if List makes the code bigger and uglier, why is it used all around the backend? I might buy the slower part, though.) > I am pretty dubious of PendingDeletesBeginXact, too, That one I might have a hard time justifying. I think I left that because I had trouble at bootstrap. I will try building without this routine to see if it works (it's really a pain to have a slow computer -- I try to rebuild the least). But probably I'll have to add it later, when the list converges in part of a more complex structure. But then, maybe it won't be needed even in that situation. > and of moving this list out of TopMemoryContext. Please justify. Huh? TopMemoryContext is certainly a bad place for the allocation. The elements certainly do not have to live beyond transaction end; I don't see the point in use TopMemoryContext for this. -- Alvaro Herrera () "La experiencia nos dice que el hombre peló millones de veces las patatas, pero era forzoso admitir la posibilidad de que en un caso entre millones, las patatas pelarían al hombre" (Ijon Tichy) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] installdir patch for win32
On Thu, Mar 25, 2004 at 07:57:19PM -0500, Tom Lane wrote: > I'm not expecting to see zero ifdefs --- certainly not in the port > modules ;-). But Bruce's search, further up in the thread, showed that > #ifdef WIN32's are sneaking into a lot of modules that probably > shouldn't have any platform dependencies. Don't forget about the EXEC_BACKEND businness ... is there any chance those could refactored somehow? -- Alvaro Herrera () "Amanece. (Ignacio Reyes) El Cerro San Cristóbal me mira, cínicamente, con ojos de virgen" ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[PATCHES] Removing cruft in access/transam/xact.c
Patchers,
This patch removes the unnecesary TRANS_* states that supposedly
represented "low level transaction state". The state is actually
unnecesary because the states can be accurately represented using the
TBLOCK_* states. This simplifies the code somewhat.
It also allows the state machinery to be actually represented as a
directed graph. If you look closely you'll see that the first graph I
posted yesterday was missing the StartTransactionCommand stuff; it
wasn't representable in an obvious ways. This patch corrects that, by
adding a new TBLOCK_STARTED state.
I also attach the graph that represents this machinery. Don't add this
to the source; it will probably be better to add the .dot source file.
I also removed some #ifdef NOT_USED code, and the IsTransactionState()
function, which can be replaced by IsTransactionOrTransactionBlock().
Maybe the latter can be renamed ...
This passes the full regression test suite. Please review and apply if
OK.
--
Alvaro Herrera ()
"I think my standards have lowered enough that now I think 'good design'
is when the page doesn't irritate the living f*ck out of me." (JWZ)
Index: src/backend/access/transam/xact.c
===
RCS file: /home/alvherre/cvs/pgsql-server/src/backend/access/transam/xact.c,v
retrieving revision 1.164
diff -c -r1.164 xact.c
*** src/backend/access/transam/xact.c 11 Feb 2004 22:55:24 - 1.164
--- src/backend/access/transam/xact.c 27 Mar 2004 02:53:00 -
***
*** 197,203
FirstCommandId, /* command id */
0, /* scan command id */
0x0,/* start time */
- TRANS_DEFAULT, /* transaction state */
TBLOCK_DEFAULT /* transaction block state from the
client
* perspective */
};
--- 197,202
***
*** 239,305
*
*/
- #ifdef NOT_USED
-
- /*
- *TransactionFlushEnabled()
- *SetTransactionFlushEnabled()
- *
- *These are used to test and set the "TransactionFlushState"
- *variable. If this variable is true (the default), then
- *the system will flush all dirty buffers to disk at the end
- *of each transaction. If false then we are assuming the
- *buffer pool resides in stable main memory, in which case we
- *only do writes as necessary.
- *
- */
- static intTransactionFlushState = 1;
-
- int
- TransactionFlushEnabled(void)
- {
- return TransactionFlushState;
- }
-
- void
- SetTransactionFlushEnabled(bool state)
- {
- TransactionFlushState = (state == true);
- }
- #endif
-
-
- /*
- *IsTransactionState
- *
- *This returns true if we are currently running a query
- *within an executing transaction.
- */
- bool
- IsTransactionState(void)
- {
- TransactionState s = CurrentTransactionState;
-
- switch (s->state)
- {
- case TRANS_DEFAULT:
- return false;
- case TRANS_START:
- return true;
- case TRANS_INPROGRESS:
- return true;
- case TRANS_COMMIT:
- return true;
- case TRANS_ABORT:
- return true;
- }
-
- /*
-* Shouldn't get here, but lint is not happy with this...
-*/
- return false;
- }
-
/*
*IsAbortedTransactionBlockState
*
--- 238,243
***
*** 850,867
TransactionState s = CurrentTransactionState;
/*
-* check the current transaction state
-*/
- if (s->state != TRANS_DEFAULT)
- elog(WARNING, "StartTransaction and not in default state");
-
- /*
-* set the current transaction state information appropriately during
-* start processing
-*/
- s->state = TRANS_START;
-
- /*
* Make sure we've freed any old snapshot, and reset xact state variables
*/
FreeXactSnapshot();
--- 788,793
***
*** 893,904
*/
DeferredTriggerBeginXact();
- /*
-* done with start processing, set current transaction state to "in
-* progress"
-*/
- s->state = TRANS_INPROGRESS;
-
}
/*
--- 819,824
***
*** 907,920
static void
CommitTransaction(void)
{
- TransactionState s = CurrentTransactionState;
-
- /*
-* check the current transaction state
-*/
- if (s->
Re: [PATCHES] Removing cruft in access/transam/xact.c
On Sat, Mar 27, 2004 at 12:21:07AM -0500, Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > This patch removes the unnecesary TRANS_* states that supposedly > > represented "low level transaction state". The state is actually > > unnecesary because the states can be accurately represented using the > > TBLOCK_* states. > > Really? > > Your changes to StartTransaction() are alone enough to refute the above > claim. With these changes, there is no longer any state in xact.c that > can detect a failure during transaction startup. Yeah, I'd agree with you, but as you can see there is no decision and no action taken based on the value of the transaction state in the current code. At most there are some elog(WARNING), and besides showing a message to the user, there is no side effect. Actually, there is *a single* elog(FATAL) in CleanupTransaction(). > The similar changes that remove the ability to recognize failures > during AbortTransaction are even worse, because cleanup after a failed > transaction is exactly where you would most expect software bugs to > pop up. > We could talk about a different solution to detecting such failures > (maybe it's okay to convert the whole thing into a critical section) > but simply removing all hope of detecting a failure won't do. I think each of StartTransaction, AbortTransaction, CleanupTransaction and CommitTransaction should verify the TBLOCK state before doing anything, and elog(FATAL) if they are called from a state they shouldn't. In fact, I remember clearly seeing a WARNING from this code in the Chris K-L's failure when he got a disk full. I haven't read that log but I suspect it would have been better if a stronger check had taken place. > The comments in xact.c make it perfectly clear that it took several > tries for the Berkeley crew to get this code right. Yeah. Fact is, the code has been hacked and whacked a lot. I think the only cleanups I've seen in the CVS logs were by yourself, several years ago ... > I'm not eager to simplify it on the basis of one person's unsupported > assertion that the complexity is unnecessary. If you can prove it's > unnecessary, let's see the proof. I'm not sure how a proof should be, but the fact that the TRANS states are not used except for log readers amusement should be an indicator. > > This passes the full regression test suite. > > The regression test suite does not cover "can't-happen" cases ... Of course. The current situation is barely sustainable for the current transaction machinery. If something goes wild, going on with the current routine may cause little or no harm. With subtransactions the whole thing will be different (corrupting the transaction stack, for example) and we will need stronger state checking. Would you agree to the change if I add checks as I outlined above? -- Alvaro Herrera () Bob [Floyd] used to say that he was planning to get a Ph.D. by the "green stamp method," namely by saving envelopes addressed to him as 'Dr. Floyd'. After collecting 500 such letters, he mused, a university somewhere in Arizona would probably grant him a degree. (Don Knuth) ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Removing cruft in access/transam/xact.c
On Sat, Mar 27, 2004 at 09:12:15PM -0400, Alvaro Herrera wrote: > On Sat, Mar 27, 2004 at 12:21:07AM -0500, Tom Lane wrote: > > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > > This patch removes the unnecesary TRANS_* states that supposedly > > > represented "low level transaction state". The state is actually > > > unnecesary because the states can be accurately represented using the > > > TBLOCK_* states. > > > > Really? > > The similar changes that remove the ability to recognize failures > > during AbortTransaction are even worse, because cleanup after a failed > > transaction is exactly where you would most expect software bugs to > > pop up. I think I see your point. CleanupTransaction is not allowed to "clean up" if AbortTransaction did not finish properly. However if this is the criterion to apply to all those routines, I think they should all have elog(FATAL) in case they do not see the correct state. Why do they only have elog(WARNING) and are allowed to continue? > > We could talk about a different solution to detecting such failures > > (maybe it's okay to convert the whole thing into a critical section) > > but simply removing all hope of detecting a failure won't do. IMHO all of StartTransaction, CommitTransaction, CleanupTransaction and AbortTransaction should be critical sections. However, they do quite a lot of work. Is this acceptable? If not, maybe I'll leave the TRANS states as means to detect incomplete execution, but clean up the code anyway and change all those elog(WARNING) into elog(FATAL). Comments? -- Alvaro Herrera () "La verdad no siempre es bonita, pero el hambre de ella sí" ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Removing cruft in access/transam/xact.c
On Sat, Mar 27, 2004 at 12:21:07AM -0500, Tom Lane wrote: [...] > The similar changes that remove the ability to recognize failures > during AbortTransaction are even worse, because cleanup after a failed > transaction is exactly where you would most expect software bugs to > pop up. Hey, I was just adding the code back when I noticed that AbortTransaction() sets the TRANS_ABORT state just _before_ doing it's work, not after. And all functions are executed with interrupts held (HOLD_INTERRUPTS / RELEASE_INTERRUPTS). So the comments I made earlier are irrelevant. After all this, I still think the TRANS state is unnecesary. I will add checks in the low level routines so they see what TBLOCK state they are called in, which should be enough to keep the current functionality and robustness. -- Alvaro Herrera () "A wizard is never late, Frodo Baggins, nor is he early. He arrives precisely when he means to." (Gandalf, en LoTR FoTR) ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Removing cruft in access/transam/xact.c
On Sun, Mar 28, 2004 at 06:16:59PM -0400, Alvaro Herrera wrote:
> After all this, I still think the TRANS state is unnecesary. I will add
> checks in the low level routines so they see what TBLOCK state they are
> called in, which should be enough to keep the current functionality
> and robustness.
Please review this one.
--
Alvaro Herrera ()
"La persona que no quería pecar / estaba obligada a sentarse
en duras y empinadas sillas/ desprovistas, por cierto
de blandos atenuantes" (Patricio Vogel)
Index: src/backend/access/transam/xact.c
===
RCS file: /home/alvherre/cvs/pgsql-server/src/backend/access/transam/xact.c,v
retrieving revision 1.164
diff -c -r1.164 xact.c
*** src/backend/access/transam/xact.c 11 Feb 2004 22:55:24 - 1.164
--- src/backend/access/transam/xact.c 28 Mar 2004 22:55:45 -
***
*** 197,203
FirstCommandId, /* command id */
0, /* scan command id */
0x0,/* start time */
- TRANS_DEFAULT, /* transaction state */
TBLOCK_DEFAULT /* transaction block state from the
client
* perspective */
};
--- 197,202
***
*** 239,305
*
*/
- #ifdef NOT_USED
-
- /*
- *TransactionFlushEnabled()
- *SetTransactionFlushEnabled()
- *
- *These are used to test and set the "TransactionFlushState"
- *variable. If this variable is true (the default), then
- *the system will flush all dirty buffers to disk at the end
- *of each transaction. If false then we are assuming the
- *buffer pool resides in stable main memory, in which case we
- *only do writes as necessary.
- *
- */
- static intTransactionFlushState = 1;
-
- int
- TransactionFlushEnabled(void)
- {
- return TransactionFlushState;
- }
-
- void
- SetTransactionFlushEnabled(bool state)
- {
- TransactionFlushState = (state == true);
- }
- #endif
-
-
- /*
- *IsTransactionState
- *
- *This returns true if we are currently running a query
- *within an executing transaction.
- */
- bool
- IsTransactionState(void)
- {
- TransactionState s = CurrentTransactionState;
-
- switch (s->state)
- {
- case TRANS_DEFAULT:
- return false;
- case TRANS_START:
- return true;
- case TRANS_INPROGRESS:
- return true;
- case TRANS_COMMIT:
- return true;
- case TRANS_ABORT:
- return true;
- }
-
- /*
-* Shouldn't get here, but lint is not happy with this...
-*/
- return false;
- }
-
/*
*IsAbortedTransactionBlockState
*
--- 238,243
***
*** 852,866
/*
* check the current transaction state
*/
! if (s->state != TRANS_DEFAULT)
! elog(WARNING, "StartTransaction and not in default state");
!
! /*
!* set the current transaction state information appropriately during
!* start processing
!*/
! s->state = TRANS_START;
!
/*
* Make sure we've freed any old snapshot, and reset xact state variables
*/
--- 790,798
/*
* check the current transaction state
*/
! if (s->blockState != TBLOCK_DEFAULT)
! elog(WARNING, "StartTransaction and not in DEFAULT state");
!
/*
* Make sure we've freed any old snapshot, and reset xact state variables
*/
***
*** 893,904
*/
DeferredTriggerBeginXact();
- /*
-* done with start processing, set current transaction state to "in
-* progress"
-*/
- s->state = TRANS_INPROGRESS;
-
}
/*
--- 825,830
***
*** 909,919
{
TransactionState s = CurrentTransactionState;
! /*
!* check the current transaction state
!*/
! if (s->state != TRANS_INPROGRESS)
! elog(WARNING, "CommitTransaction and not in in-progress state");
/*
* Tell the trigger manager that this transaction is about to be
--- 835,842
{
TransactionState s = CurrentTransactionState;
! if (s->blockState != TBLOCK_INPROGRESS)
! elog(WARNING, "CommitTransaction and not in INPROGRESS state"
[PATCHES] xact.c cleanup -- uncontroversial try
Hackers,
This is a cleanup patch for access/transam/xact.c. It is a trimmed down
version of the previous patch, with the controversial part removed. It
only removes some #ifdef NOT_USED code, and adds a new TBLOCK state
which signals the fact that StartTransaction() has been executed.
Please review and apply if OK.
--
Alvaro Herrera ()
"El sabio habla porque tiene algo que decir;
el tonto, porque tiene que decir algo" (Platon).
Index: src/backend/access/transam/xact.c
===
RCS file: /home/alvherre/cvs/pgsql-server/src/backend/access/transam/xact.c,v
retrieving revision 1.164
diff -c -r1.164 xact.c
*** src/backend/access/transam/xact.c 11 Feb 2004 22:55:24 - 1.164
--- src/backend/access/transam/xact.c 30 Mar 2004 20:44:15 -
***
*** 239,274
*
*/
- #ifdef NOT_USED
-
- /*
- *TransactionFlushEnabled()
- *SetTransactionFlushEnabled()
- *
- *These are used to test and set the "TransactionFlushState"
- *variable. If this variable is true (the default), then
- *the system will flush all dirty buffers to disk at the end
- *of each transaction. If false then we are assuming the
- *buffer pool resides in stable main memory, in which case we
- *only do writes as necessary.
- *
- */
- static intTransactionFlushState = 1;
-
- int
- TransactionFlushEnabled(void)
- {
- return TransactionFlushState;
- }
-
- void
- SetTransactionFlushEnabled(bool state)
- {
- TransactionFlushState = (state == true);
- }
- #endif
-
-
/*
*IsTransactionState
*
--- 239,244
***
*** 1171,1176
--- 1141,1155
*/
case TBLOCK_DEFAULT:
StartTransaction();
+ s->blockState = TBLOCK_STARTED;
+ break;
+
+ /*
+* We should never experience this -- it means the STARTED
state
+* was not changed in the previous CommitTransactionCommand.
+*/
+ case TBLOCK_STARTED:
+ elog(WARNING, "StartTransactionCommand: unexpected
TBLOCK_STARTED");
break;
/*
***
*** 1202,1210
*/
case TBLOCK_END:
elog(WARNING, "StartTransactionCommand: unexpected
TBLOCK_END");
- s->blockState = TBLOCK_DEFAULT;
CommitTransaction();
StartTransaction();
break;
/*
--- 1181,1189
*/
case TBLOCK_END:
elog(WARNING, "StartTransactionCommand: unexpected
TBLOCK_END");
CommitTransaction();
StartTransaction();
+ s->blockState = TBLOCK_DEFAULT;
break;
/*
***
*** 1247,1257
switch (s->blockState)
{
/*
* If we aren't in a transaction block, just do our usual
* transaction commit.
*/
! case TBLOCK_DEFAULT:
CommitTransaction();
break;
/*
--- 1226,1246
switch (s->blockState)
{
/*
+* This shouldn't happen, because it means the previous
+* StartTransactionCommand didn't set the STARTED state
+* appropiately.
+*/
+ case TBLOCK_DEFAULT:
+ elog(WARNING, "CommitTransactionCommand: unexpected
TBLOCK_DEFAULT");
+ break;
+
+ /*
* If we aren't in a transaction block, just do our usual
* transaction commit.
*/
! case TBLOCK_STARTED:
CommitTransaction();
+ s->blockState = TBLOCK_DEFAULT;
break;
/*
***
*** 1314,1326
switch (s->blockState)
{
/*
* if we aren't in a transaction block, we just do the basic
* abort & cleanup transaction.
*/
! case TBLOCK_DEFAULT:
AbortTransaction();
CleanupTrans
[PATCHES] Basic subtransaction facility
Hackers,
Here is a very preliminar patch that allows the user to say "BEGIN"
inside a transaction and have the system react accordingly. This is
only a modification to xact.c (and slightly to other places to allow it
to work); the important functions are empty.
It compiles fine for me with both SUBTRANSACTIONS defined and not
defined; when not defined, the behavior is the same as the current code.
Please note that I have made some errors more fatal than they are now,
as bugs in this code will have much worse effects than a flaw in the
current transaction system.
One quick note: there are two ENDABORT states for a subtransaction,
SUBENDABORT_OK and SUBENDABORT_ERROR. They signal whether the parent
transaction should be aborted after the child transaction finishes or
not: an aborted subtransaction where the user issues COMMIT should
abort the parent transaction; if the user issues ROLLBACK, the parent
can be allowed to continue.
Please have a look and comment. This file does not move a lot so I
don't think it will suffer from a lot of code drift.
--
Alvaro Herrera ()
"I think my standards have lowered enough that now I think 'good design'
is when the page doesn't irritate the living f*ck out of me." (JWZ)
Index: src/backend/access/transam/xact.c
===
RCS file: /home/alvherre/cvs/pgsql-server/src/backend/access/transam/xact.c,v
retrieving revision 1.165
diff -c -r1.165 xact.c
*** src/backend/access/transam/xact.c 5 Apr 2004 03:11:39 - 1.165
--- src/backend/access/transam/xact.c 14 Apr 2004 02:50:02 -
***
*** 189,194
--- 189,219
static void RecordTransactionAbort(void);
static void StartTransaction(void);
+ #ifdef SUBTRANSACTIONS
+ static void StartSubTransaction(void);
+ static void CommitSubTransaction(void);
+ static void AbortSubTransaction(void);
+ static void CleanupSubTransaction(void);
+ static void PushCurrentTransaction(void);
+ static void PopTransaction(void);
+ static bool IsSubTransaction(void);
+ static void ShowTransactionState(void);
+ static void ShowTransactionStateRec(TransactionState, int);
+ #else /* SUBTRANSACTIONS */
+ #define StartSubTransaction()
+ #define CommitSubTransaction()
+ #define AbortSubTransaction()
+ #define CleanupSubTransaction()
+ #define PushCurrentTransaction()
+ #define PopTransaction()
+ #define IsSubTransaction() (false)
+ #define ShowTransactionState()
+ #define ShowTransactionStateRec()
+ #endif /* SUBTRANSACTIONS */
+
+ static char *BlockStateAsString(TBlockState);
+ static char *TransStateAsString(TransState);
+
/*
*global variables holding the current transaction state.
*/
***
*** 200,205
--- 225,237
TRANS_DEFAULT, /* transaction state */
TBLOCK_DEFAULT /* transaction block state from the
client
* perspective */
+ #ifdef SUBTRANSACTIONS
+ ,
+ 0, /* nesting level */
+ NULL, /* top transaction memory
context */
+ NULL, /* commit memory context */
+ NULL/* parent transaction */
+ #endif
};
static TransactionState CurrentTransactionState = &CurrentTransactionStateData;
***
*** 281,287
{
TransactionState s = CurrentTransactionState;
! if (s->blockState == TBLOCK_ABORT)
return true;
return false;
--- 313,320
{
TransactionState s = CurrentTransactionState;
! if (s->blockState == TBLOCK_ABORT ||
! s->blockState == TBLOCK_SUBABORT)
return true;
return false;
***
*** 1145,1189
break;
/*
-* We should never experience this -- it means the STARTED
state
-* was not changed in the previous CommitTransactionCommand.
-*/
- case TBLOCK_STARTED:
- elog(WARNING, "StartTransactionCommand: unexpected
TBLOCK_STARTED");
- break;
-
- /*
-* We should never experience this -- if we do it means the
-* BEGIN state was not changed in the previous
-* CommitTransactionCommand(). If we get it, we print a
-* warning and change to the in-progress state.
-*/
- case TBLOCK_BEGIN:
- elog(WARNING, "StartTransactionCommand: unexpected
TBLOCK_BEGIN");
-
Re: [PATCHES] Basic subtransaction facility
On Sat, Apr 17, 2004 at 10:03:40AM -0400, Bruce Momjian wrote: > Do you want this applied? If you want. When not #defined, the behavior is the same as the current code, so it shouldn't affect anything. However I posted mainly so people could comment on the modifications, and maybe Heikki Linnakangas could see how it affects his two phase commit patch. Also, that code does not change a lot, so there's little risk of code drift to worry about; this makes it unlikely that I'd have a lot of work to do to update it to a future CVS tip. But maybe applying it means it gets more testing. > ------- > > Alvaro Herrera wrote: > > Hackers, > > > > Here is a very preliminar patch that allows the user to say "BEGIN" > > inside a transaction and have the system react accordingly. This is > > only a modification to xact.c (and slightly to other places to allow it > > to work); the important functions are empty. > > > > It compiles fine for me with both SUBTRANSACTIONS defined and not > > defined; when not defined, the behavior is the same as the current code. > > Please note that I have made some errors more fatal than they are now, > > as bugs in this code will have much worse effects than a flaw in the > > current transaction system. > > > > One quick note: there are two ENDABORT states for a subtransaction, > > SUBENDABORT_OK and SUBENDABORT_ERROR. They signal whether the parent > > transaction should be aborted after the child transaction finishes or > > not: an aborted subtransaction where the user issues COMMIT should > > abort the parent transaction; if the user issues ROLLBACK, the parent > > can be allowed to continue. > > > > > > Please have a look and comment. This file does not move a lot so I > > don't think it will suffer from a lot of code drift. -- Alvaro Herrera () "At least to kernel hackers, who really are human, despite occasional rumors to the contrary" (LWN.net) ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] Basic subtransaction facility
On Sun, Apr 18, 2004 at 11:29:05AM -0400, Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > If you want. When not #defined, the behavior is the same as the current > > code, so it shouldn't affect anything. However I posted mainly so > > people could comment on the modifications, and maybe Heikki Linnakangas > > could see how it affects his two phase commit patch. > > I have not reviewed it yet, but would like to do so before it goes in. I noticed that I sent an old version because of a system crash (the *one* time I don't review vi -r differences it bites me ... argh). It has several obvious mistakes. Please do not waste your time reviewing that; I'll submit a corrected version later, which will also contain some more changes. Thanks. -- Alvaro Herrera () "Find a bug in a program, and fix it, and the program will work today. Show the program how to find and fix a bug, and the program will work forever" (Oliver Silfridge) ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Basic subtransaction facility
On Mon, Apr 19, 2004 at 11:13:35AM -0400, Alvaro Herrera wrote:
> I noticed that I sent an old version because of a system crash (the
> *one* time I don't review vi -r differences it bites me ... argh). It
> has several obvious mistakes. Please do not waste your time reviewing
> that; I'll submit a corrected version later, which will also contain
> some more changes.
Ok, hopefully this one is better.
I'm thinking that I'll to add a new elog level to signal a can't-happen
condition within the transaction machinery, which would abort the whole
transaction tree (more than ERROR) but would not take the whole backend
down (less than FATAL). What should it be called? Do people agree that
it's needed?
--
Alvaro Herrera ()
"Et put se mouve" (Galileo Galilei)
Index: src/backend/access/transam/xact.c
===
RCS file: /home/alvherre/cvs/pgsql-server/src/backend/access/transam/xact.c,v
retrieving revision 1.165
diff -c -r1.165 xact.c
*** src/backend/access/transam/xact.c 5 Apr 2004 03:11:39 - 1.165
--- src/backend/access/transam/xact.c 20 Apr 2004 05:25:52 -
***
*** 189,194
--- 189,224
static void RecordTransactionAbort(void);
static void StartTransaction(void);
+ #ifdef SUBTRANSACTIONS
+ static void StartSubTransaction(void);
+ static void CommitSubTransaction(void);
+ static void AbortSubTransaction(void);
+ static void CleanupSubTransaction(void);
+ static void PushCurrentTransaction(void);
+ static void PopTransaction(void);
+ static bool IsSubTransaction(void);
+ static void ShowTransactionState(char *);
+ static void ShowTransactionStateRec(TransactionState, int);
+
+ static void AtSubStart_Memory(void);
+ static void AtSubCommit_Memory(void);
+ static void AtSubCleanup_Memory(void);
+
+ #else /* SUBTRANSACTIONS */
+ #define StartSubTransaction()
+ #define CommitSubTransaction()
+ #define AbortSubTransaction()
+ #define CleanupSubTransaction()
+ #define PushCurrentTransaction()
+ #define PopTransaction()
+ #define IsSubTransaction() (false)
+ #define ShowTransactionState(foo)
+ #define ShowTransactionStateRec()
+ #endif /* SUBTRANSACTIONS */
+
+ static char *BlockStateAsString(TBlockState);
+ static char *TransStateAsString(TransState);
+
/*
*global variables holding the current transaction state.
*/
***
*** 200,205
--- 230,247
TRANS_DEFAULT, /* transaction state */
TBLOCK_DEFAULT /* transaction block state from the
client
* perspective */
+ #ifdef SUBTRANSACTIONS
+ ,
+ 0, /* nesting level */
+ NULL, /* commit memory context */
+ NULL, /* deferred trigger queue */
+ NIL,/* smgr pending deletes */
+ NIL,/* async notifies */
+ NULL, /* lightweight locks */
+ NIL,/* regular locks */
+ NULL, /* parent transaction */
+
+ #endif
};
static TransactionState CurrentTransactionState = &CurrentTransactionStateData;
***
*** 281,287
{
TransactionState s = CurrentTransactionState;
! if (s->blockState == TBLOCK_ABORT)
return true;
return false;
--- 323,330
{
TransactionState s = CurrentTransactionState;
! if (s->blockState == TBLOCK_ABORT ||
! s->blockState == TBLOCK_SUBABORT)
return true;
return false;
***
*** 452,459
--- 495,544
ALLOCSET_DEFAULT_MAXSIZE);
MemoryContextSwitchTo(TopTransactionContext);
+
+ /*
+* This context will be used to hold data that survives
+* subtransaction commit but disappears on subtransaction end.
+* Most if not all of the transaction-local structures should
+* live here.
+*/
+ CommitContext = AllocSetContextCreate(TopTransactionContext,
+
"CommitContext",
+
ALLOCSET_DEFAULT_MINSIZE,
+
ALLOCSET_DEFAULT_INITSIZE,
+
ALLOCSET_DEFAULT_MAXSIZE);
}
+ #ifdef SUBTRANSACTIONS
+ /*
Re: [PATCHES] doc improv: backup/restore
On Wed, Apr 21, 2004 at 01:22:25PM -0400, Neil Conway wrote: > This patch improves the backup & restore documentation somewhat: I added > a few more cross-refs, documented increasing checkpoint_segments, and > made a few other minor improvements. > > I intend to apply this within 24 hours barring any complaints. I'm not sure, but seems the reference to work_mem is gone? -- Alvaro Herrera () "El sentido de las cosas no viene de las cosas, sino de las inteligencias que las aplican a sus problemas diarios en busca del progreso." (Ernesto Hernández-Novich) ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[PATCHES] Remove traces of xfunc
Hackers,
While playing with the init code I noticed traces of Hellerstein's
"expensive function optimization". It is completely disabled, uses
functions nowhere to be defined, and is out of date. So I removed it.
Here is the patch. Note that it takes out the "pruneable" field from
struct RelOptInfo, since it's not used.
Tom Lane has said a couple of times that he thinks this maybe can be
resurrected; but even if it is, most likely it won't use this code
(what code? These are only hooks.)
(To the patcher: the file src/backend/lib/lispsort.c can also be removed
after this change)
--
Alvaro Herrera ()
"Hoy es el primer día del resto de mi vida"
Index: src/backend/optimizer/path/allpaths.c
===
RCS file: /home/alvherre/cvs/pgsql-server/src/backend/optimizer/path/allpaths.c,v
retrieving revision 1.112
diff -c -r1.112 allpaths.c
*** src/backend/optimizer/path/allpaths.c 14 Jan 2004 23:01:55 - 1.112
--- src/backend/optimizer/path/allpaths.c 24 Apr 2004 01:53:10 -
***
*** 531,546
{
rel = (RelOptInfo *) lfirst(x);
- #ifdef NOT_USED
-
- /*
-* * for each expensive predicate in each path in each
-* distinct rel, * consider doing pullup -- JMH
-*/
- if (XfuncMode != XFUNC_NOPULL && XfuncMode != XFUNC_OFF)
- xfunc_trypullup(rel);
- #endif
-
/* Find and save the cheapest paths for this rel */
set_cheapest(rel);
--- 531,536
Index: src/backend/optimizer/plan/createplan.c
===
RCS file: /home/alvherre/cvs/pgsql-server/src/backend/optimizer/plan/createplan.c,v
retrieving revision 1.168
diff -c -r1.168 createplan.c
*** src/backend/optimizer/plan/createplan.c 29 Feb 2004 17:36:05 - 1.168
--- src/backend/optimizer/plan/createplan.c 24 Apr 2004 01:29:14 -
***
*** 167,185
break;
}
- #ifdef NOT_USED /* fix xfunc */
- /* sort clauses by cost/(1-selectivity) -- JMH 2/26/92 */
- if (XfuncMode != XFUNC_OFF)
- {
- set_qpqual((Plan) plan,
- lisp_qsort(get_qpqual((Plan) plan),
- xfunc_clause_compare));
- if (XfuncMode != XFUNC_NOR)
- /* sort the disjuncts within each clause by cost -- JMH 3/4/92
*/
- xfunc_disjunct_sort(plan->qpqual);
- }
- #endif
-
return plan;
}
--- 167,172
Index: src/backend/optimizer/util/pathnode.c
===
RCS file: /home/alvherre/cvs/pgsql-server/src/backend/optimizer/util/pathnode.c,v
retrieving revision 1.103
diff -c -r1.103 pathnode.c
*** src/backend/optimizer/util/pathnode.c 29 Mar 2004 19:58:04 - 1.103
--- src/backend/optimizer/util/pathnode.c 24 Apr 2004 01:39:45 -
***
*** 243,251
* A path is worthy if it has either a better sort order (better pathkeys)
* or cheaper cost (on either dimension) than any of the existing old paths.
*
! * Unless parent_rel->pruneable is false, we also remove from the rel's
! * pathlist any old paths that are dominated by new_path --- that is,
! * new_path is both cheaper and at least as well ordered.
*
* The pathlist is kept sorted by TOTAL_COST metric, with cheaper paths
* at the front. No code depends on that for correctness; it's simply
--- 243,251
* A path is worthy if it has either a better sort order (better pathkeys)
* or cheaper cost (on either dimension) than any of the existing old paths.
*
! * We also remove from the rel's pathlist any old paths that are dominated
! * by new_path --- that is, new_path is both cheaper and at least as well
! * ordered.
*
* The pathlist is kept sorted by TOTAL_COST metric, with cheaper paths
* at the front. No code depends on that for correctness; it's simply
***
*** 342,351
}
/*
!* Remove current element from pathlist if dominated by new,
!* unless xfunc told us not to remove any paths.
*/
! if (remove_old && parent_rel->pruneable)
{
List *p1_next = lnext(p1);
--- 342,350
}
/*
!* Remove current element from pathlist if dominated by new.
*/
! if (remove_old
Re: [PATCHES] Remove traces of xfunc
On Sun, Apr 25, 2004 at 12:20:01AM -0400, Neil Conway wrote: > On 24-Apr-04, at 5:58 PM, Alvaro Herrera wrote: > >While playing with the init code I noticed traces of Hellerstein's > >"expensive function optimization". It is completely disabled, uses > >functions nowhere to be defined, and is out of date. So I removed it. > > I'll apply this within 24 hours. Cool. I forgot to mention that the Makefile in src/backend/lib has to be modified too if you drop the lispsort.c file. -- Alvaro Herrera () Jajaja! Solo hablaba en serio! ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] subtransactions -- storage manager
Hackers,
This patch adds subtransaction support into the storage manager. Files
created or dropped inside a subtransaction are correctly dealt with at
subtransaction commit or abort.
This works:
create table foo (a int);
create table foo2 (a int);
begin;
begin;
create table bar (a int);
select relfilenode, relname from pg_class where relname in ('foo',
'bar');
drop table foo2;
rollback;
drop table foo;
create table baz (a int);
select relfilenode, relname from pg_class where relname='baz';
commit;
At this point, the files for "bar" and "foo" have disappeared, while
"foo2" and "baz" remain. (Note however that the catalog entries are not
correct -- this is because we don't have correctly recorded results in
pg_clog.)
While making this I realized I had made a mistake regarding portal
memory, so I also correct it with this patch. As a side effect, the
following works;
begin;
begin;
declare foo cursor for select 1;
commit;
begin;
declare bar cursor for select 1;
rollback;
fetch all from foo; -- returns 1 row
fetch all from bar; -- no such cursor
rollback;
(This patch will only apply cleanly with the previous patch applied.)
Still missing:
- support for prepared statements, async notifies. Easy.
- support for on commit actions. Not sure.
- support for deferred triggers. Not so easy, maybe hard.
- correct LWLock handling. Should be easy (release them all on abort)
- correct regular lock handling. Not so easy.
- pg_clog/pg_subtrans. Need a solution.
PS: somehow I managed to get tired of the phrase "nested transactions"
and I'm using the term "subtransactions" instead. In my head they are
the same thing ...
--
Alvaro Herrera ()
Hi! I'm a .signature virus!
cp me into your .signature file to help me spread!
diff -cr --exclude-from=diff-ignore 08simple/src/backend/access/transam/xact.c
10smgr/src/backend/access/transam/xact.c
*** 08simple/src/backend/access/transam/xact.c 2004-04-20 01:25:52.0 -0400
--- 10smgr/src/backend/access/transam/xact.c2004-04-25 13:34:13.376961237 -0400
***
*** 202,207
--- 202,208
static void AtSubStart_Memory(void);
static void AtSubCommit_Memory(void);
+ static void AtSubAbort_Memory(void);
static void AtSubCleanup_Memory(void);
#else /* SUBTRANSACTIONS */
***
*** 382,387
--- 383,434
/*
+ * TransactionGetPendingDeletes
+ */
+ List *
+ TransactionGetPendingDeletes(void)
+ {
+ TransactionState s = CurrentTransactionState;
+
+ return s->pendingDeletes;
+ }
+
+ /*
+ * TransactionSetPendingDeletes
+ */
+ void
+ TransactionSetPendingDeletes(List *pending)
+ {
+ TransactionState s = CurrentTransactionState;
+
+ s->pendingDeletes = pending;
+ }
+
+ /*
+ * TransactionGetParentPendingDeletes
+ */
+ List *
+ TransactionGetParentPendingDeletes(void)
+ {
+ TransactionState s = CurrentTransactionState;
+
+ Assert(s->parent != NULL);
+ return s->parent->pendingDeletes;
+ }
+
+ /*
+ * TransactionSetParentPendingDeletes
+ */
+ void
+ TransactionSetParentPendingDeletes(List *pending)
+ {
+ TransactionState s = CurrentTransactionState;
+
+ Assert(s->parent != NULL);
+ s->parent->pendingDeletes = pending;
+ }
+
+ /*
*TransactionIdIsCurrentTransactionId
*
*During bootstrap, we cheat and say "it's not my transaction ID" even though
***
*** 479,484
--- 526,533
static void
AtStart_Memory(void)
{
+ TransactionState s = CurrentTransactionState;
+
/*
* We shouldn't have a transaction context already.
*/
***
*** 507,512
--- 556,563
ALLOCSET_DEFAULT_MINSIZE,
ALLOCSET_DEFAULT_INITSIZE,
ALLOCSET_DEFAULT_MAXSIZE);
+
+ s->commitContext = CommitContext;
}
#ifdef SUBTRANSACTIONS
***
*** 537,542
--- 588,595
ALLOCSET_DEFAULT_MINSIZE,
ALLOCSET_DEFAULT_INITSIZE,
ALLOCSET_DEFAULT_MAXSIZE);
+
+ s->commitContext = CommitContext;
}
#endif /* SUBTRANSACTIONS */
***
*** 884,889
--- 937,954
MemoryContextSwitchTo(TopMemoryContext);
[PATCHES] nested transactions
Hackers, Here is my current patch implementing nested transactions. At this point I'd like some actual testing. If you have any use for this please test it and tell me how it behaves for you. Report any annoyances. Still missing: - deal with deferred triggers. - do something with catcache reference counting Obvious bugs: - I just noticed the commit handling of child transactions is wrong. A concurrent backend could see as committed tuples that should be regarded as in progress. (Breaks both serializable and read committed isolation levels.) subtrans.c should go into src/backend/access/transam/subtrans.c subtrans.h should go into src/include/access/subtrans.h -- Alvaro Herrera () "Investigación es lo que hago cuando no sé lo que estoy haciendo" (Wernher von Braun) ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] nested transactions
On Fri, May 14, 2004 at 04:41:06PM -0400, Alvaro Herrera wrote: > Hackers, > > Here is my current patch implementing nested transactions. Turns out the patch is too big and the server won't publish it. Meanwhile, Bruce has posted it as ftp://candle.pha.pa.us/pub/postgresql/mypatches/nested.diff Sorry for the inconvenience, -- Alvaro Herrera () "Everybody understands Mickey Mouse. Few understand Hermann Hesse. Hardly anybody understands Einstein. And nobody understands Emperor Norton." ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] PITR Phase 1 - Full set of patches
On Thu, Apr 29, 2004 at 11:21:53PM +0100, Simon Riggs wrote: > ...my patch building experience is less than some might > expect so there are various possible annoyances here. I am on hand to > help and to learn by my mistakes. I see you attached one patch for every file ... this works, but is error prone. May I suggest another approach: 1. get CVSup if you can. I have Linux, so I got the ezm3 package and the CVSup package. Compile/install ezm3 (it's a Modula-3 compiler) first and then CVSup. Google for them, I don't have URLs. 2. get the whole Postgres repository using CVSup with this config file: >>>>>>>> *default host=cvsup.postgresql.org *default compress *default release=cvs *default delete use-rel-suffix # *default tag=. # base directory where CVSup will store its 'bookmarks' file(s) *default base=/home/alvherre/cvs # prefix directory where CVSup will store the actual distribution(s) *default prefix=/home/alvherre/cvs # complete distribution repository >>>>>>>> This will create a "cvsroot". Adjust the path, obviously. Note that case matters because I have a "cvs" directory with the cvsroot, and a "CVS" directory for the checkouts. This may be a stupid idea but it is how I did it some time ago :-) 3. Checkout a couple of trees cvs -d /home/alvherre/cvs co pgsql I have several pgsql trees: /home/alvherre/CVS/pgsql/source/00orig this is the pristine CVS tip. My first modification in /home/alvherre/CVS/pgsql/source/01xact second in /home/alvherre/CVS/pgsql/source/02blahblah etc, you get the idea. (I have a "74_rel" and "73_rel" too, just in case.) Then I created a "build" tree, in /home/alvherre/CVS/pgsql/build. So each time I want to compile, I create a /home/alvherre/CVS/pgsql/build/00orig, cd to it, and then do ../../source/00orig/configure --enable-debug [etc] --prefix=/home/alvherre/CVS/pgsql/install/00orig 4. To generate a patch, just do cd /home/alvherre/CVS/pgsql/01xact cvs -q diff Note that sometimes I do things incrementally, so I do "incremental diffs" by commands like cd /home/alvherre/CVS/pgsql/source diff -cr --exclude-from=ignore-diff 01xact 02blahblah The ignore-diff file is there because some files are built on the source tree and generate a lot of irrelevant differences. It contains >>>>>>>> pl_gram.c pl.tab.h pl_scan.c psqlscan.c sql_help.h preproc.c preproc.h pgc.c guc-file.c fmgrtab.c fmgroids.h parse.h gram.c scan.c bootparse.c bootstrap_tokens.h bootscanner.c *~ tags CVS .*sw[poq] >>>>>>>> So, by this time you are wondering why do I use a number as the start of the tree name. Well, this is because I have a script which allows me to - build (configure, make) - install (make install) - initdb - run a server - run a psql client - run a "make check" against a running server And I may want to do any combination of the above with any combination of the pgsql trees I have, simultaneously. So I picked a random number as "base", and the scripts takes the sum of this number and the number at the start of tree name, and uses it as the port (--with-pgport). So I can run all servers and clients, with no conflict. If there is any interest I can post the script too. It's somewhat ugly but it has worked for me. -- Alvaro Herrera () "La virtud es el justo medio entre dos defectos" (Aristóteles) ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] PITR Phase 1 - Full set of patches
On Thu, Apr 29, 2004 at 09:58:49PM -0400, Alvaro Herrera wrote: > Note that sometimes I do things incrementally, so I do "incremental > diffs" by commands like > cd /home/alvherre/CVS/pgsql/source > diff -cr --exclude-from=ignore-diff 01xact 02blahblah ^^^ Note that this should be -Ncr -- I don't create a lot of new files ... -- Alvaro Herrera () "Cuando no hay humildad las personas se degradan" (A. Christie) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] subtransactions -- storage manager
On Thu, Apr 29, 2004 at 11:38:52PM +0100, Simon Riggs wrote: > On Sun, 2004-04-25 at 19:06, Alvaro Herrera wrote: > > - pg_clog/pg_subtrans. Need a solution. > As you're aware, our current work overlaps. > pg_clog doesn't seem like the place to record subtransactions, though > maybe it is... could we not give subtransactions a txnid just as with > flat transactions? That way we can record everything in pg_clog AND > recovery will work without further modification - as long as the failure > of a top level transaction causes failure of every subtransaction EVEN > if the subtrans originally committed. > > If you add pg_subtrans, you will need to make recovery work all over > again...really, you don't want to be doing that, do you? I'm not sure if I follow you. I suppose you haven't read the previous discussions on this issue. pg_subtrans will have, for each Xid, the Xid of its parent xact; if it's toplevel (as all xacts are implicitly in the current implementation), it will have 0. In pg_clog, a committed subxact will be marked with 11; committed top-level xact will still be 10. Aborted xact (toplevel and subxact) will have 01. So whenever you see a xact with 10 in pg_clog, you know it committed. Whenever you see 11, you know you have to fetch pg_subtrans and check its parent (which could in turn be 11 so you have to recurse; or 10 so you know it's committed; or 01 so you know if it's aborted; or 00 so you know it's in progress). After "a suitable time" (after the parent xact commits) the 11 can be changed to 10. I don't think there's really a change in how recovery works. There will likely be more traffic to pg_xlog involving writes to pg_clog and pg_subtrans but it shouldn't affect much, should it? -- Alvaro Herrera () "Linux transformó mi computadora, de una `máquina para hacer cosas', en un aparato realmente entretenido, sobre el cual cada día aprendo algo nuevo" (Jaime Salinas) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] new aggregate functions v1
On Sat, May 01, 2004 at 04:21:21PM +0200, Fabien COELHO wrote: > (2) bitwise integer aggregates named bit_and and bit_or for > int2, int4, int8 and bit types. They are not standard, > however they exist in other db (eg mysql), and I needed them > for some other stuff. I'm sure people won't like to add functions just because "some other DB has them". Maybe we could take this kind of "compatibility functions" all together into some gborg module and let people install that if they want closer compatibility. So we could have "Mysql compatible functions", "Oracle compatible functions", etc. Thus the backend would be free from this stuff, and people who needs it just installs the whole package. -- Alvaro Herrera () "La realidad se compone de muchos sueños, todos ellos diferentes, pero en cierto aspecto, parecidos..." (Yo, hablando de sueños eróticos) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[PATCHES] smgr cleanup
Hackers,
This patch removes a couple of no-ops. I'm trying to get rid of unused
code that is in the transaction processing path.
Unrelated: it also adds an index term to the performance tips chapter.
The smgrcommit and smgrabort functions no longer do anything useful so I
removed them. We could argue that a hypotethical future storage manager
could do something at commit/abort so the hooks are needed, but we
haven't had a different storage manager for years.
If there are no objections, please apply.
--
Alvaro Herrera ()
"Pensar que el espectro que vemos es ilusorio no lo despoja de espanto,
sólo le suma el nuevo terror de la locura" (Perelandra, CSLewis)
Index: doc/src/sgml/perform.sgml
===
RCS file: /home/alvherre/cvs/pgsql-server/doc/src/sgml/perform.sgml,v
retrieving revision 1.45
diff -c -r1.45 perform.sgml
*** doc/src/sgml/perform.sgml 22 Apr 2004 17:38:14 - 1.45
--- doc/src/sgml/perform.sgml 4 May 2004 00:44:07 -
***
*** 5,10
--- 5,14
Performance Tips
+
+performance
+
+
Query performance can be affected by many things. Some of these can
be manipulated by the user, while others are fundamental to the underlying
Index: src/backend/access/transam/xact.c
===
RCS file: /home/alvherre/cvs/pgsql-server/src/backend/access/transam/xact.c,v
retrieving revision 1.165
diff -c -r1.165 xact.c
*** src/backend/access/transam/xact.c 5 Apr 2004 03:11:39 - 1.165
--- src/backend/access/transam/xact.c 4 May 2004 01:31:37 -
***
*** 475,483
TransactionId xid = GetCurrentTransactionId();
XLogRecPtr recptr;
- /* Tell bufmgr and smgr to prepare for commit */
- BufmgrCommit();
-
START_CRIT_SECTION();
/*
--- 475,480
***
*** 964,970
smgrDoPendingDeletes(true);
AtCommit_Cache();
AtEOXact_Buffers(true);
- /* smgrcommit already done */
AtCommit_Locks();
--- 961,966
***
*** 1074,1080
smgrDoPendingDeletes(false);
AtAbort_Cache();
AtEOXact_Buffers(false);
- smgrabort();
AtAbort_Locks();
--- 1070,1075
Index: src/backend/storage/buffer/bufmgr.c
===
RCS file: /home/alvherre/cvs/pgsql-server/src/backend/storage/buffer/bufmgr.c,v
retrieving revision 1.164
diff -c -r1.164 bufmgr.c
*** src/backend/storage/buffer/bufmgr.c 25 Apr 2004 23:50:54 - 1.164
--- src/backend/storage/buffer/bufmgr.c 4 May 2004 00:45:19 -
***
*** 940,956
}
/*
- * Do whatever is needed to prepare for commit at the bufmgr and smgr levels
- */
- void
- BufmgrCommit(void)
- {
- /* Nothing to do in bufmgr anymore... */
-
- smgrcommit();
- }
-
- /*
* BufferGetBlockNumber
*Returns the block number associated with a buffer.
*
--- 940,945
Index: src/backend/storage/smgr/md.c
===
RCS file: /home/alvherre/cvs/pgsql-server/src/backend/storage/smgr/md.c,v
retrieving revision 1.104
diff -c -r1.104 md.c
*** src/backend/storage/smgr/md.c 19 Apr 2004 17:42:58 - 1.104
--- src/backend/storage/smgr/md.c 4 May 2004 00:46:51 -
***
*** 576,605
}
/*
- *mdcommit() -- Commit a transaction.
- */
- bool
- mdcommit(void)
- {
- /*
-* We don't actually have to do anything here...
-*/
- return true;
- }
-
- /*
- *mdabort() -- Abort a transaction.
- */
- bool
- mdabort(void)
- {
- /*
-* We don't actually have to do anything here...
-*/
- return true;
- }
-
- /*
*mdsync() -- Sync previous writes to stable storage.
*/
bool
--- 576,581
Index: src/backend/storage/smgr/smgr.c
===
RCS file: /home/alvherre/cvs/pgsql-server/src/backend/storage/smgr/smgr.c,v
retrieving revision 1.70
diff -c -r1.70 smgr.c
*** src/backend/storage/smgr/smgr.c 11 Feb 2004 22:55:25 - 1.70
--- src/backend/storage/smgr/smgr.c 4 May 2004 01:10:48 -
***
*** 47,54
char *buffer);
BlockNumber (*smgr_nblocks) (SMgrRelation reln);
BlockNumber (*smgr_truncate) (SMgrRelation reln, BlockNumber nblocks);
- bool(*smgr_commit) (void); /* may be NULL */
- bool(*smgr_abort) (void); /* may be NULL */
bool(*smgr_sync) (void);/* may be NULL */
} f_smgr;
--- 47,52
***
*** 56
Re: [PATCHES] [BUGS] BUG #1134: ALTER USER ... RENAME breaks md5
On Tue, Apr 27, 2004 at 09:37:50AM +0200, Fabien COELHO wrote: > Even of the salt is based on the login, the point is that it is stored > separatly, so the system does not rely on the login string to check the > password. > > The only other scheme which requires the user password somehow is the HTTP > digest authentification, and AFAIK no one in the world uses it;-) I think (some of the) SASL authentication mechanisms also use a digest of the user and password, if that's what you meant. But the username and password have to be stored separately on the server anyway, just like HTTP digest -- they are means of hiding it on the wire, not on disk. -- Alvaro Herrera () "El miedo atento y previsor es la madre de la seguridad" (E. Burke) ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] Basic subtransaction facility
I wrote ten seconds ago:
> This version does. This patch includes both patches I
> posted and a few more changes, and does the following:
I mean this one.
--
Alvaro Herrera ()
"¿Qué importan los años? Lo que realmente importa es comprobar que
a fin de cuentas la mejor edad de la vida es estar vivo" (Mafalda)
Index: src/backend/access/transam/xact.c
===
RCS file: /home/alvherre/cvs/pgsql-server/src/backend/access/transam/xact.c,v
retrieving revision 1.165
diff -c -r1.165 xact.c
*** src/backend/access/transam/xact.c 5 Apr 2004 03:11:39 - 1.165
--- src/backend/access/transam/xact.c 26 Apr 2004 13:25:30 -
***
*** 189,194
--- 189,227
static void RecordTransactionAbort(void);
static void StartTransaction(void);
+ #ifdef SUBTRANSACTIONS
+ static void StartSubTransaction(void);
+ static void CommitSubTransaction(void);
+ static void AbortSubTransaction(void);
+ static void CleanupSubTransaction(void);
+ static void PushCurrentTransaction(void);
+ static void PopTransaction(void);
+ static bool IsSubTransaction(void);
+ static void ShowTransactionState(char *);
+ static void ShowTransactionStateRec(TransactionState, int);
+
+ static void AtSubStart_Memory(void);
+ static void AtSubCommit_Memory(void);
+ static void AtSubAbort_Memory(void);
+ static void AtSubCleanup_Memory(void);
+ static void AtSubCommit_Notifies(void);
+
+ static char *TransStateAsString(TransState);
+
+ #else /* SUBTRANSACTIONS */
+ #define StartSubTransaction()
+ #define CommitSubTransaction()
+ #define AbortSubTransaction()
+ #define CleanupSubTransaction()
+ #define PushCurrentTransaction()
+ #define PopTransaction()
+ #define IsSubTransaction() (false)
+ #define ShowTransactionState(foo)
+ #define ShowTransactionStateRec()
+ #endif /* SUBTRANSACTIONS */
+
+ static char *BlockStateAsString(TBlockState);
+
/*
*global variables holding the current transaction state.
*/
***
*** 198,205
0, /* scan command id */
0x0,/* start time */
TRANS_DEFAULT, /* transaction state */
! TBLOCK_DEFAULT /* transaction block state from the
client
* perspective */
};
static TransactionState CurrentTransactionState = &CurrentTransactionStateData;
--- 231,251
0, /* scan command id */
0x0,/* start time */
TRANS_DEFAULT, /* transaction state */
! TBLOCK_DEFAULT, /* transaction block state from the
client
* perspective */
+ #ifdef SUBTRANSACTIONS
+ 0, /* nesting level */
+ NULL, /* commit memory context */
+ NULL, /* deferred trigger queue */
+ #endif /* SUBTRANSACTIONS */
+ NIL,/* smgr pending deletes */
+ NIL /* async notifies */
+ #ifdef SUBTRANSACTIONS
+ ,
+ NULL, /* lightweight locks */
+ NIL,/* regular locks */
+ NULL/* parent transaction */
+ #endif
};
static TransactionState CurrentTransactionState = &CurrentTransactionStateData;
***
*** 281,287
{
TransactionState s = CurrentTransactionState;
! if (s->blockState == TBLOCK_ABORT)
return true;
return false;
--- 327,334
{
TransactionState s = CurrentTransactionState;
! if (s->blockState == TBLOCK_ABORT ||
! s->blockState == TBLOCK_SUBABORT)
return true;
return false;
***
*** 337,342
--- 384,484
return s->startTime;
}
+ /*
+ * TransactionGetPendingDeletes
+ */
+ List *
+ TransactionGetPendingDeletes(void)
+ {
+ TransactionState s = CurrentTransactionState;
+
+ return s->pendingDeletes;
+ }
+
+ /*
+ * TransactionSetPendingDeletes
+ */
+ void
+ TransactionSetPendingDeletes(List *pending)
+ {
+ TransactionState s = CurrentTransactionState;
+
+ s->pendingDeletes = pending;
+ }
+
+ #ifdef SUBTRANSACTIONS
+ /*
+ * TransactionGetParentPendingDeletes
+ */
+ List *
+ TransactionGetParentPendingDeletes(void)
+ {
+ TransactionState s = CurrentTransactionState;
+
+ Assert(s->parent != NU
Re: [PATCHES] Basic subtransaction facility
On Mon, Apr 26, 2004 at 11:30:16PM -0400, Bruce Momjian wrote: > > Alvaro, where are we on this patch. I think the suggestion was to > throw FATAL rather than add a new error level. > > Is this ready to be applied? I forgot to verify if it worked correctly with #undef SUBTRANSACTIONS --- it didn't. This version does. This patch includes both patches I posted and a few more changes, and does the following: - adds subtransaction state knowledge to xact.c - adds subtransaction support to smgr, portals (cursors) and async notifies. - adds a new memory context related to the subxact tree (is reset only on subtrans abort). - corrects a couple of bugs in the previous patches. - mantains a Xid list of committed subxacts, for use in future changes involving pg_clog - adds support for executing BEGIN inside an aborted transaction, not only as a simple query (1st patch did this) but also as messages of v3 protocol and prepared statements. - works cleanly with SUBTRANSACTIONS undefined (you get the current behavior, no BEGIN is allowed inside a running transaction) and defined (all of the above). - keeps the original behavior of using FATAL whenever an bug is found inside xact.c I feel this one is ready to be applied. Tom wanted to review it, of course. Still missing: - deal with prepared statements, deferred triggers - save state in pg_clog - visibility rules -- Alvaro Herrera () "La realidad se compone de muchos sueños, todos ellos diferentes, pero en cierto aspecto, parecidos..." (Yo, hablando de sueños eróticos) ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Basic subtransaction facility
On Mon, Apr 26, 2004 at 11:30:16PM -0400, Bruce Momjian wrote: > Alvaro, where are we on this patch. I think the suggestion was to > throw FATAL rather than add a new error level. The assumption was that we would only want an additional level for catching can't-happen conditions. ISTM this is not true. Consider an out of memory error: do we want to only rollback the affected subtransaction, or the whole transaction tree? If we want the latter we will have to invent a new elevel. In fact, I think we should mark ERROR as aborting the whole transaction tree, and create a new level which would abort the innermost subtransaction. We would then change whatever is appropiate to the new elevel. Doing otherwise would leave us open to unexpected conditions causing only subtrans abort, which could lead to unreliable behavior. In short, I think all elog(ERROR) should have different behaviour from ereport(ERROR), at least. And I don't think the answer should be elog(FATAL) for the former. -- Alvaro Herrera () "Ni aun el genio muy grande llegaría muy lejos si tuviera que sacarlo todo de su propio interior" (Goethe) ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] Basic subtransaction facility
On Thu, Apr 29, 2004 at 12:26:01AM -0400, Bruce Momjian wrote: > I don't understand your elog(ERROR) vs. ereport(ERROR) distinction. Was > that a typo? Nope. When Tom upgraded the error handling, he changed almost everything to ereport(), but in the places where there's a violation of expected conditions, he retained elog(). We don't provide special error code, nor there is space for errhints etc. Those unexpected conditions I thought we could just abort the transaction tree; but maybe we have to close the backend as Manfred and Tom say. I don't think there's space for PANIC though (unless we suspect shared state corruption ... is that checked for anywhere? I haven't looked.) -- Alvaro Herrera () "No single strategy is always right (Unless the boss says so)" (Larry Wall) ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] Basic subtransaction facility
On Thu, Apr 29, 2004 at 02:42:23PM -0400, Tom Lane wrote: > In general I tend to agree with Manfred's point: if you have reason to > suspect global corruption of a backend's state then you should do FATAL > (or possibly PANIC). If you do not suspect this then you ought to just > ERROR. I do not see the use-case for abort-all-levels-of-xact-but- > don't-exit. Ok, I'm not wedded to the idea of a new elevel. So you think elog(ERROR) should rather be elog(FATAL) ? -- Alvaro Herrera () Y una voz del caos me habló y me dijo "Sonríe y sé feliz, podría ser peor". Y sonreí. Y fui feliz. Y fue peor. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Basic subtransaction facility
On Thu, Apr 29, 2004 at 07:29:07PM +0200, Peter Eisentraut wrote: > Bruce Momjian wrote: > > I think his point was that there are some errors that should abort > > the outer transaction too. I think Alvaro mentioned out of memory, > > but that is a FATAL error. Alvaro, what error were you thinking of > > that should abort the outer transaction? > > Theoretically, if you abort the inner transaction, that could free up > memory for use by the outer transaction. Yes, this is planned to happen. -- Alvaro Herrera () "La tristeza es un muro entre dos jardines" (Khalil Gibran) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Basic subtransaction facility
On Thu, Apr 29, 2004 at 06:42:31PM +0200, Manfred Koizar wrote: > On Wed, 28 Apr 2004 12:02:44 -0400, Alvaro Herrera > <[EMAIL PROTECTED]> wrote: > >In fact, I think we should mark ERROR as aborting the whole transaction > >tree, and create a new level which would abort the innermost > >subtransaction. We would then change whatever is appropiate to the new > >elevel. Doing otherwise would leave us open to unexpected conditions > >causing only subtrans abort, which could lead to unreliable behavior. > > Why? Subtransaction commit propagates an error state to the parent > transaction. And if a subtransaction is rolled back the parent can > continue cleanly no matter what was the reason for the subtrans abort. Not necessarily; consider can't-happen conditions, like everything that is marked elog(ERROR) rather than ereport(ERROR). Corrupt hashes, should-exist catalog entries that are not there, etc. They should not be frequent, be we should be prepared for them. -- Alvaro Herrera () "La virtud es el justo medio entre dos defectos" (Aristóteles) ---(end of broadcast)--- TIP 8: explain analyze is your friend
[PATCHES] Nested xacts, try 5
Hackers, I attach a updated nested transactions patch. Hopefully the list server will actually distribute it this time. I'd really like to get some testing and comment. Does this actually work on the scenarios where those of you who would be using it expect it to work? In this patch, relcache and catcache reference counting is handled as previously discussed on pgsql-hackers: each item carries a stack onto which the current refcount is pushed when a subtransaction starts, and it is restored if the subtransaction aborts. This is a "first cut" and probably there some bug in the logic, but the basic cases work. Also, Locks are released on subtrans abort based on the list of committed child transactions, rather than relabeling at subtrans commit; I suspect it's cheaper as we don't have to rehash the lock with the new tag. Main transaction commit and abort are logged with a list of committed subtransactions. At recovery, those are marked committed or aborted. I added some logic to the pg_subtrans code so that a subcommitted transaction whose parent is either committed or aborted (recursively) is marked as committed/aborted if its Xid is lesser than a cutoff point. The cutoff is taken from the xmin calculated at GetSnapshotData, so by the time pg_clog is modified, no transaction is running which should see them as in-progress. Please comment on this, as the idea is new. The change is done in TransactionIdDidCommit() and TransactionIdDidAbort() (and so the SubtransCutoffXid is kept in transam.c, which may seem strange but it's actually the only place where it can be). What's missing: - deferred trigger handling - Tom mentioned buffer manager state reversing. I haven't investigated this yet. - check that relcache and catcache code is correct. I'm almost sure there's a bug. Hopefully not much else. -- Alvaro Herrera () Tulio: oh, para qué servirá este boton, Juan Carlos? Policarpo: No, aléjense, no toquen la consola! Juan Carlos: Lo apretaré una y otra vez. nested-all-5.patch.gz Description: Binary data /* * subtrans.h * * PostgreSQL subtrans-log manager * * Portions Copyright (c) 1996-2003, PostgreSQL Global Development Group * Portions Copyright (c) 1994, Regents of the University of California * * $PostgreSQL$ */ #ifndef SUBTRANS_H #define SUBTRANS_H #include "access/xlog.h" /* exported because lwlock.c needs it */ #define NUM_SUBTRANS_BUFFERS8 extern void SubTransSetParent(TransactionId xid, TransactionId parent); extern TransactionId SubTransGetParent(TransactionId xid); extern TransactionId SubTransGetTopmostTransaction(TransactionId xid); extern bool SubTransXidsHaveCommonAncestor(TransactionId xid1, TransactionId xid2); extern int SUBTRANSShmemSize(void); extern void SUBTRANSShmemInit(void); extern void BootStrapSUBTRANS(void); extern void StartupSUBTRANS(void); extern void ShutdownSUBTRANS(void); extern void CheckPointSUBTRANS(void); extern void ExtendSUBTRANS(TransactionId newestXact); extern void TruncateSUBTRANS(TransactionId oldestXact); #endif /* SUBTRANS_H */ subtrans.c.gz Description: Binary data ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[PATCHES] Nested xacts 5, updated
I attach my current patch. Please test and review. -- Alvaro Herrera () "La experiencia nos dice que el hombre peló millones de veces las patatas, pero era forzoso admitir la posibilidad de que en un caso entre millones, las patatas pelarían al hombre" (Ijon Tichy) nested-all-9.patch.gz Description: Binary data ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] Cancel/Kill backend functions
On Thu, May 27, 2004 at 08:08:34PM +0200, Magnus Hagander wrote: > >Magnus Hagander wrote: > >> Okay, here is an updated patch. now uses IsBackendPid(), which is > >> closely modeled (read cut-and-pasted) from > >> TransactionIdIsInProgress(). I wonder what can happen if a backend passes the IsBackendPid() test and terminates just before the kill() signal? It should be pretty unlikely but you could signal the wrong process ... shouldn't the SInvalLock be held throughout the whole operation? -- Alvaro Herrera () "El número de instalaciones de UNIX se ha elevado a 10, y se espera que este número aumente" (UPM, 1972) ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] Cancel/Kill backend functions
On Fri, May 28, 2004 at 01:01:10AM -0400, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > Magnus Hagander wrote:
> >> You'd actually need to get a pid *reuse* during that short time.
>
> > That isn't so implausible on a system which assigns PIDs randomly.
> > Holding the SInvalLock doesn't remove the race condition, but it
> > makes it less likely to occur for essentially very little cost.
>
> Other than holding a fairly critical lock for an operation that will
> take an unknown amount of time.
With this comment, I take it you'd disagree with my recoding of
TransactionIdIsCurrentTransactionId().
The current code has to scan only the xid's in each PGPROC struct.
However I had to rewrite it to peek at pg_subtrans, and this is done
while the SInvalLock is share-locked. pg_subtrans may need to do some
I/O to get the data, and there could be multiple queries, depending on
the nesting level.
I could write it to save the xid's in PGPROC in a first pass, then
release the SInvalLock, then look at pg_subtrans. But I think doing it
this way has a ("is a?") race condition.
--
Alvaro Herrera ()
Bob [Floyd] used to say that he was planning to get a Ph.D. by the "green
stamp method," namely by saving envelopes addressed to him as 'Dr. Floyd'.
After collecting 500 such letters, he mused, a university somewhere in
Arizona would probably grant him a degree. (Don Knuth)
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [PATCHES] fix oid casting inconsistency
On Mon, Feb 16, 2004 at 10:00:49PM -0500, Neil Conway wrote: > This patch removes the quotes from "oid", to make this error message > consistent with the error messages for rejected input to most other > types. > > While I suppose it's possible that some applications might be > examining this error message string, (a) this particular error message > isn't very likely be used for that (b) we have error codes now. This kind of error message consistency enhancement has been applied liberally in the past. -- Alvaro Herrera () "If you have nothing to say, maybe you need just the right tool to help you not say it." (New York Times, about Microsoft PowerPoint) ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] eventlog fix
On Thu, Jun 03, 2004 at 12:33:29AM +0200, Laurent Ballester wrote: > I modify pgevent.c, for your both remarks: "capital G" are disappears from > source and I move GetModuleFilename() before RegCreateKey() call. > > I sent full set file again, it will be easier to apply. > /* Global variables */ > HANDLE g_hModule = NULL; /* hModule of DLL */ We don't use this hungarian notation anywhere ... it certainly looks ugly. -- Alvaro Herrera () "Y eso te lo doy firmado con mis lágrimas" (Fiebre del Loco) ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] PITR Archival
On Tue, Jun 15, 2004 at 04:34:30PM +0100, Simon Riggs wrote: > I have a considerable amount still to learn about CVS, diff and patch, > so anybody wanting to spend 10-15 mins on the phone with me would > greatly enhance my chances of helping patch my patch, when the bugs roll > in. Can't help you with the phone thingie, but if you want to see what's in a patch and be able to edit it nicely, I suggest you use meld. It's a python dual-pane GTK display, really nice. Too slow for real coding (on my machine that is) but real good for seeing what you changed. Watch out for use of Ctrl, Shift and Alt -- very handy. Can use CVS as well, or you can use two source trees. -- Alvaro Herrera () "There is evil in the world. There are dark, awful things. Occasionally, we get a glimpse of them. But there are dark corners; horrors almost impossible to imagine... even in our worst nightmares." (Van Helsing, Dracula A.D. 1972) ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] Nested transactions
On Wed, Jun 16, 2004 at 11:45:36PM +0100, Simon Riggs wrote: > The patch looks impressively technical, but overall I'm not exactly sure > what it does...I guess I'm just not clear why I would want it, except as > the main technical pre-work to later syntax changes. I'm sure some short > explanations would clear that up for me very quickly... :) Right. I have never intended to be implementing a known SQL standard feature. What I'm doing is allowing the whole backend to go back to a know state after an error is encountered. With this in place, implementing SAVEPOINTs the way SQL expects them to work appears to be a very trivial exercise. > Perhaps what I've just asked about is trivial icing on the cake you've > just baked, I think this phrase very precisely describes it. At least, that's what I expect. You may not see it, but a savepoint is just the start of a nested transaction in disguise. Consider: begin; insert into foo values (1); savepoint dammit; insert into foo values (2); select foo; -- fails rollback to dammit; insert into foo values (3); commit; You expect the transaction to finish with tuples 1 and 3 in table foo, right? Well, this is exactly the same as begin; insert into foo values (1); begin; -- dammit insert into foo values (2); select foo; -- fails, goes to aborted state rollback; insert into foo values (3); commit; So all that's needed for the former to work is to be able to define a "name" for a transaction (using a cute syntax) and being able to rollback to it. Definitely trivial, after all the work I have put into making the latter work. In extant releases you can only do this: begin; insert into foo values (1); insert into foo values (2); select foo; -- oops, can't go back! rollback; begin; insert into foo values (1); insert into foo values (3); commit; You are forced to send all the commands before the aborting one to the server again. And there's no way to "undo" a command in the transaction, short of aborting it completely. I don't know what Oracle or other DBMSs expect in this area. Anyone care to give me a few pointers? If I'm missing something, I want to know as soon as possible. -- Alvaro Herrera () "Before you were born your parents weren't as boring as they are now. They got that way paying your bills, cleaning up your room and listening to you tell them how idealistic you are." -- Charles J. Sykes' advice to teenagers ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] Nested transactions
On Thu, Jun 17, 2004 at 10:01:32AM +0800, Christopher Kings-Lynne wrote: > >And consider this case: > > > > BEGIN; > > ... > > SAVEPOINT x; > > SELECT func_call(); > > SELECT func_call(); > > COMMIT; > > > >Now if func_call has a savepoint, it is really nested because it can't > >know whether the savepoint X will be used to roll back, so its status is > >dependent on the status of X. Now, if we used savepoints in func_call, > >what happens in the second function call when we define a savepoint with > >the same name? I assume we overwrite the original, but using nested > >transaction syntax seems much clearer. > > It also seems in this example that func_call() probably shouldn't have > permission to rollback to savepoint x? Otherwise it would get...weird. I don't think we should explicitly forbid it. I think it should be forbidden to close the outermost transaction inside a function (else the function would not be able to terminate correctly), but for levels before that one it'd be OK. -- Alvaro Herrera () "Cuando mañana llegue pelearemos segun lo que mañana exija" (Mowgli) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] Nested transactions
On Wed, Jun 16, 2004 at 09:36:33PM -0400, Bruce Momjian wrote: > And consider this case: > > BEGIN; > ... > SAVEPOINT x; > SELECT func_call(); > SELECT func_call(); > COMMIT; > > Now if func_call has a savepoint, it is really nested because it can't > know whether the savepoint X will be used to roll back, so its status is > dependent on the status of X. Now, if we used savepoints in func_call, > what happens in the second function call when we define a savepoint with > the same name? Hm, that's a good question. What happens if you define two savepoints with the same name? According to SQL2003, the previous savepoint "is destroyed", but it's not clear to me whether this means rolling back all of its changes or just forgetting it. What's clear is that you can roll back only to the latest one. Also, in SQL2003 there can be multiple "savepoint levels". I think for a first implementation it would be fine if we had only one level. It would, wouldn't it? -- Alvaro Herrera () "Estoy de acuerdo contigo en que la verdad absoluta no existe... El problema es que la mentira sí existe y tu estás mintiendo" (G. Lama) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[PATCHES] Some index entries
The attached patch adds some index entries pointing to the cursor
reference pages. Please apply.
--
Alvaro Herrera ()
Thou shalt study thy libraries and strive not to reinvent them without
cause, that thy code may be short and readable and thy days pleasant
and productive. (7th Commandment for C Programmers)
Index: doc/src/sgml/ref/close.sgml
===
RCS file: /home/alvherre/cvs/pgsql-server/doc/src/sgml/ref/close.sgml,v
retrieving revision 1.20
diff -c -r1.20 close.sgml
*** doc/src/sgml/ref/close.sgml 29 Nov 2003 19:51:38 - 1.20
--- doc/src/sgml/ref/close.sgml 17 Jun 2004 02:37:27 -
***
*** 18,23
--- 18,28
CLOSE
+
+ cursor
+ CLOSE
+
+
CLOSE name
Index: doc/src/sgml/ref/declare.sgml
===
RCS file: /home/alvherre/cvs/pgsql-server/doc/src/sgml/ref/declare.sgml,v
retrieving revision 1.30
diff -c -r1.30 declare.sgml
*** doc/src/sgml/ref/declare.sgml 29 Nov 2003 19:51:38 - 1.30
--- doc/src/sgml/ref/declare.sgml 17 Jun 2004 02:38:28 -
***
*** 18,23
--- 18,28
DECLARE
+
+ cursor
+ DECLARE
+
+
DECLARE name [ BINARY ] [ INSENSITIVE ]
[ [ NO ] SCROLL ]
Index: doc/src/sgml/ref/fetch.sgml
===
RCS file: /home/alvherre/cvs/pgsql-server/doc/src/sgml/ref/fetch.sgml,v
retrieving revision 1.36
diff -c -r1.36 fetch.sgml
*** doc/src/sgml/ref/fetch.sgml 23 Mar 2004 22:57:09 - 1.36
--- doc/src/sgml/ref/fetch.sgml 17 Jun 2004 03:14:41 -
***
*** 18,23
--- 18,28
FETCH
+
+ cursor
+ FETCH
+
+
FETCH [ direction { FROM | IN } ]
cursorname
Index: doc/src/sgml/ref/move.sgml
===
RCS file: /home/alvherre/cvs/pgsql-server/doc/src/sgml/ref/move.sgml,v
retrieving revision 1.27
diff -c -r1.27 move.sgml
*** doc/src/sgml/ref/move.sgml 23 Mar 2004 22:39:22 - 1.27
--- doc/src/sgml/ref/move.sgml 17 Jun 2004 02:38:14 -
***
*** 18,23
--- 18,28
MOVE
+
+ cursor
+ MOVE
+
+
MOVE [ direction { FROM | IN } ]
cursorname
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] Some index entries
On Thu, Jun 17, 2004 at 08:41:14AM -0400, Bruce Momjian wrote: > > Patch applied. Thanks. Your documentation changes can be viewed in > five minutes using links at the bottom of the developer's page, > http://developer.postgresql.org/index.php. Huh, the index came out empty! And it's not called bookindex.html anymore, now it shows up as i66180.html. Is this normal? Thanks, -- Alvaro Herrera () "Amanece. (Ignacio Reyes) El Cerro San Cristóbal me mira, cínicamente, con ojos de virgen" ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] nested xacts and phantom Xids
On Sun, Jun 20, 2004 at 04:37:16PM -0400, Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > Here I present the nested transactions patch and the phantom Xids patch > > that goes with it. > > I looked at the phantom XIDs stuff a bit. I still have little confidence > that the concept is correct :-( but here are some comments on the code > level. Ok. I for one think this got much more complex than I had originally thought it would be. I agree the changes to Set/Get Xmin/Xmax are way beyond what one would want, but the alternative would be to spread the complexity into their callers and I think that would be much worse. I don't have a lot of confidence in this either. The patch will be available in archives if anybody wants to implement this in a cleaner and safer way; I'll continue working on the rest of the things you pointed out in the subtransactions patch. Sadly, something broke in a really strange way between my last cvs update and today's, because I can't get the patch to initdb. It compiles without warnings (and I did make distclean), but there's a weird bug I'll have to pursue. Regarding the invalidation messages, what I'm currently looking at is to add a TransactionId to each message, which will be CurrentTransactionId for each new message. When a subxact commits, all its messages are relabeled to its parent. When a subxact aborts, all messages labeled with its TransactionId are locally processed and discarded. This is tricky because chunks are prepended to the queue, but it also means we can stop processing as soon as a message belongs to another transaction. I think GUC vars are easier: when a variable is about to change value inside a subtransaction, save the previous value in a list from which it will be restored if the subtransaction later aborts. -- Alvaro Herrera () "Hay dos momentos en la vida de un hombre en los que no debería especular: cuando puede permitírselo y cuando no puede" (Mark Twain) ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] nested xacts and phantom Xids
On Mon, Jun 21, 2004 at 10:28:59PM -0400, Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > This is tricky because chunks are prepended to the queue, but it also > > means we can stop processing as soon as a message belongs to another > > transaction. > > AFAIR there isn't any essential semantics to the ordering of the queue > entries, so you can probably get away with reordering if that makes life > any easier. > > Also, rather than labeling each entry individually, it might be better > to keep a separate list for each level of transaction. Then instead of > relabeling, you'd just concat the subtrans list to its parent's. Seems > like this should be faster and less storage. Right, but it makes harder to detect when a duplicate relcache entry is going to be inserted. Judging from the commentary in the file this is an issue. Another idea I had was: 1. at subtransaction start, add a special "boundary" message carrying the new Xid. 2. at subtransaction abort, process the first chunk backwards until the boundary message with the corresponding Xid is found; if it's not, jump to the next and repeat. At subtransaction commit nothing special needs to be done. This avoids having to label each message and to change the message appending scheme. -- Alvaro Herrera () "The eagle never lost so much time, as when he submitted to learn of the crow." (William Blake) ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] nested xacts and phantom Xids
On Sun, Jun 20, 2004 at 08:49:22PM -0400, Tom Lane wrote:
> Of these the one that I think most urgently needs attention is inval.c;
> that is complicated code already and figuring out what should happen
> for subtrans commit/abort is not trivial. The others look relatively
> straightforward to fix, if tedious.
A patch for this is attached. It _seems_ to work ok; conceptually it
seems ok too. I have done some testing which tends to indicate that it
is right, but I'm not sure of all the implications this code has so I
don't know how to test it exhaustively. Of course, regression tests
pass, but this doesn't actually prove anything.
--
Alvaro Herrera ()
"¿Que diferencia tiene para los muertos, los huérfanos, y aquellos que han
perdido su hogar, si la loca destrucción ha sido realizada bajo el nombre
del totalitarismo o del santo nombre de la libertad y la democracia?" (Gandhi)
Index: src/include/storage/sinval.h
===
RCS file: /home/alvherre/cvs/pgsql-server/src/include/storage/sinval.h,v
retrieving revision 1.35
diff -c -w -b -B -c -r1.35 sinval.h
*** sinval.h2 Jun 2004 21:29:29 - 1.35
--- sinval.h22 Jun 2004 04:52:54 -
***
*** 20,32
/*
! * We currently support two types of shared-invalidation messages: one that
* invalidates an entry in a catcache, and one that invalidates a relcache
* entry. More types could be added if needed. The message type is
* identified by the first "int16" field of the message struct. Zero or
* positive means a catcache inval message (and also serves as the catcache
! * ID field). -1 means a relcache inval message. Other negative values
! * are available to identify other inval message types.
*
* Relcache invalidation messages usually also cause invalidation of entries
* in the smgr's relation cache. This means they must carry both logical
--- 20,33
/*
! * We currently support three types of shared-invalidation messages: one that
* invalidates an entry in a catcache, and one that invalidates a relcache
* entry. More types could be added if needed. The message type is
* identified by the first "int16" field of the message struct. Zero or
* positive means a catcache inval message (and also serves as the catcache
! * ID field). -1 means a relcache inval message. -2 means a subtransaction
! * boundary message. Other negative values are available to identify other
! * inval message types.
*
* Relcache invalidation messages usually also cause invalidation of entries
* in the smgr's relation cache. This means they must carry both logical
***
*** 53,58
--- 54,64
* and so that negative cache entries can be recognized with good accuracy.
* (Of course this assumes that all the backends are using identical hashing
* code, but that should be OK.)
+ *
+ * A subtransaction boundary is not really a cache invalidation message;
+ * rather it's an implementation artifact for nested transactions. The
+ * cleanup code for subtransaction abort looks for this message as a boundary
+ * to know when to stop processing messages.
*/
typedef struct
***
*** 79,89
--- 85,104
*/
} SharedInvalRelcacheMsg;
+ #define SUBXACTBOUNDARYMSG_ID (-2)
+
+ typedef struct
+ {
+ int16 id; /* type field --- must be
first */
+ TransactionId xid;/* transaction id */
+ } SubxactBoundaryMsg;
+
typedef union
{
int16 id; /* type field --- must be
first */
SharedInvalCatcacheMsg cc;
SharedInvalRelcacheMsg rc;
+ SubxactBoundaryMsg sb;
} SharedInvalidationMessage;
Index: src/backend/utils/cache/inval.c
===
RCS file: /home/alvherre/cvs/pgsql-server/src/backend/utils/cache/inval.c,v
retrieving revision 1.62
diff -c -w -b -B -c -r1.62 inval.c
*** inval.c 18 Jun 2004 06:13:52 - 1.62
--- inval.c 23 Jun 2004 00:04:35 -
***
*** 66,73
*manipulating the init file is in relcache.c, but we keep track of the
*need for it here.
*
! *All the request lists are kept in TopTransactionContext memory, since
*they need not live beyond the end of the current transaction.
*
*
* Portions Copyright (c) 1996-2003, PostgreSQL Global Development Group
--- 66,75
*manipulating the init file is in relcache.c, but we keep track of the
*need for it here.
*
! *All the request lists are kept in CommitContext memory, since
*they need not live beyond the end of the current transaction.
+ *Also, this makes it easy to free messages created in an aborting
+ *subtransaction.
*
*
Re: [PATCHES] nested xacts and phantom Xids
On Wed, Jun 23, 2004 at 08:58:15AM -0400, Bruce Momjian wrote: > If we add nested transactions for 7.5, are we going to need savepoints > too in the same release? If we don't, are we going to get a lot of > complaints? It'd be good to have savepoints right now. I'm not sure it'd be good to expose the nested transactions implementation if we are going to offer savepoints later, because it means we will have to keep nested transactions forever. Maybe it is a good idea to hide the implementation details and offer only the standard SAVEPOINT feature. I'm not sure how hard it is to change the syntax; I don't think it'd be a big deal. -- Alvaro Herrera () "La conclusión que podemos sacar de esos estudios es que no podemos sacar ninguna conclusión de ellos" (Tanenbaum) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] nested xacts and phantom Xids
On Wed, Jun 23, 2004 at 08:57:11AM -0400, Bruce Momjian wrote: > I am sorry to have given Alvaro another idea that didn't work. It allowed me to learn a lot of cool tricks, so it wasn't wasted work. The only think I'm sorry about is that I should have used the time for something more useful, like tackling the remaining problems in the nested xacts implementation proper. > However, thinking of options, I wonder if instead of phantom xids, we > should do phantom cids. Because only the local backend looks at the > command counter (cid). I think it might be alot cleaner. The phantom > cid would have a tuple bit set indicating that instead of being a cid, > it is an index into an array of cmin/cmax pairs. Yeah, maybe this can work. I'm not going to try however, at least not now. If somebody else wants to try, be my guest. -- Alvaro Herrera () "El conflicto es el camino real hacia la unión" ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] nested xacts and phantom Xids
On Sun, Jun 20, 2004 at 08:49:22PM -0400, Tom Lane wrote:
Regarding GUC, a WIP report:
> Given patches for inval.c and guc.c, I would say that the patch is
> functionally close enough to done that we could commit to including
> it in 7.5 --- the other stuff could be wrapped up post-feature-freeze.
I figured I could save the values whenever they are going to change, and
restore them if the subtransaction aborts. This seems to work fine
(lightly tested).
I still have to figure out how to handle allocation for string vars, but
I thought I'd post the patch for others to see. Please let me know if
it's too ugly. (This patch misses the pieces in xact.c and xact.h but
I'm sure the concept is clear.)
I'll post a full patch once the missing deferred trigger stuff works.
With the patches I posted to inval.c I think this fulfills the
requirements, barring the performance issues raised.
Comments?
--
Alvaro Herrera ()
"No single strategy is always right (Unless the boss says so)"
(Larry Wall)
Index: guc.c
===
RCS file: /home/alvherre/cvs/pgsql-server/src/backend/utils/misc/guc.c,v
retrieving revision 1.211
diff -c -w -b -B -c -r1.211 guc.c
*** guc.c 11 Jun 2004 03:54:54 - 1.211
--- guc.c 24 Jun 2004 23:41:42 -
***
*** 25,30
--- 25,31
#include "utils/guc.h"
#include "utils/guc_tables.h"
+ #include "access/xact.h"
#include "catalog/namespace.h"
#include "catalog/pg_type.h"
#include "commands/async.h"
***
*** 54,59
--- 55,61
#include "tcop/tcopprot.h"
#include "utils/array.h"
#include "utils/builtins.h"
+ #include "utils/memutils.h"
#include "utils/pg_locale.h"
#include "pgstat.h"
***
*** 76,81
--- 78,85
static const char *assign_log_destination(const char *value,
bool doit, GucSource source);
+ static void SaveGucVariable(struct config_generic *conf);
+
#ifdef HAVE_SYSLOG
extern char *Syslog_facility;
extern char *Syslog_ident;
***
*** 105,110
--- 109,115
GucSource source);
static bool assign_stage_log_stats(bool newval, bool doit, GucSource source);
static bool assign_log_stats(bool newval, bool doit, GucSource source);
+ static bool assign_transaction_read_only(bool newval, bool doit, GucSource source);
/*
***
*** 172,177
--- 177,183
static intmax_index_keys;
static intmax_identifier_length;
static intblock_size;
+ static intnesting_level;
static bool integer_datetimes;
/* Macros for freeing malloc'd pointers only if appropriate to do so */
***
*** 801,807
GUC_NO_RESET_ALL | GUC_NOT_IN_SAMPLE | GUC_DISALLOW_IN_FILE
},
&XactReadOnly,
! false, NULL, NULL
},
{
{"add_missing_from", PGC_USERSET, COMPAT_OPTIONS_PREVIOUS,
--- 807,813
GUC_NO_RESET_ALL | GUC_NOT_IN_SAMPLE | GUC_DISALLOW_IN_FILE
},
&XactReadOnly,
! false, assign_transaction_read_only, NULL
},
{
{"add_missing_from", PGC_USERSET, COMPAT_OPTIONS_PREVIOUS,
***
*** 1311,1316
--- 1317,1333
BLCKSZ, BLCKSZ, BLCKSZ, NULL, NULL
},
+ {
+ /* XXX probably it's a bad idea for this to be GUC_REPORT. */
+ {"nesting_level", PGC_INTERNAL, UNGROUPED,
+ gettext_noop("Shows the current transaction nesting level"),
+ NULL,
+ GUC_NOT_IN_SAMPLE | GUC_DISALLOW_IN_FILE | GUC_REPORT
+ },
+ &nesting_level,
+ 0, 0, INT_MAX, NULL, NULL
+ },
+
/* End-of-list marker */
{
{NULL, 0, 0, NULL, NULL}, NULL, 0, 0, 0, NULL, NULL
***
*** 2001,2014
return find_option(map_old_guc_names[i+1]);
}
! /* Check if the name is qualified, and if so, check if the qualifier
* maps to a custom variable class.
*/
dot = strchr(name, GUC_QUALIFIER_SEPARATOR);
if(dot != NULL && is_custom_class(name, dot - name))
! /*
!* Add a placeholder variable for this name
!*/
return (struct config_generic*)add_placeholder_variable(name);
/* Unknown name */
--- 2018,2030
return find_option(map_old_guc_names[i+1]);
}
! /*
!* Check if the name is qualified, and if so, check if
Re: [PATCHES] nested xacts and phantom Xids
On Sat, Jun 26, 2004 at 07:56:09PM -0400, Tom Lane wrote: > Do we really need SubtransCutoffXid? AFAICS the reason for having it is > only this claim in RecordTransactionCommit: > > * We can't mark committed subtransactions as fully committed, > * because concurrent transactions would see them as committed > * and not as in-progress. Leave them as "subcommitted" until > * the parent transaction is below OldestXmin, per VACUUM. Right, that's the only point where it's used. I don't know clearly if some kind of mechanism will be needed to handle SUBTRANS COMMIT states in pg_clog that were left behind by a crashed subtransaction though. > but I think this is dead wrong. As long as we mark the parent committed > first, there is no race condition. tqual tests that are using snapshots > will need to recognize that the subtransaction is a member of one of the > snapshotted main XIDs, and those that are not will think committed is > committed. So I want to mark subtransactions fully committed in > RecordTransactionCommit, and lose SubtransCutoffXid. Comments? Yes, sounds good. > BTW, it would help to know what parts of the patch you intend to work on > over the next couple of days. I'm reviewing and editorializing right > now with intent to commit soon, so it would be good if we can avoid > tromping on each others' feet. This is really excellent news. I'll work on adding the Xid-cache to PGPROC and using that in TransactionIdIsInProgress and the tqual routines. If you want to work on that let me know and I'll handle things like the password file, local bufmgr refcount, etc. -- Alvaro Herrera () FOO MANE PADME HUM ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] nested xacts and phantom Xids
On Sat, Jun 26, 2004 at 07:56:09PM -0400, Tom Lane wrote:
> BTW, it would help to know what parts of the patch you intend to work on
> over the next couple of days. I'm reviewing and editorializing right
> now with intent to commit soon, so it would be good if we can avoid
> tromping on each others' feet.
Oops, I forgot that I had inadvertently left a kludge in
commands/trigger.c. Please use this patch for this file instead.
--
Alvaro Herrera ()
Jude: I wish humans laid eggs
Ringlord: Why would you want humans to lay eggs?
Jude: So I can eat them
Index: include/commands/trigger.h
===
RCS file: /home/alvherre/cvs/pgsql-server/src/include/commands/trigger.h,v
retrieving revision 1.45
diff -c -r1.45 trigger.h
*** include/commands/trigger.h 29 Nov 2003 22:40:59 - 1.45
--- include/commands/trigger.h 25 Jun 2004 22:59:40 -
***
*** 151,198
ItemPointer tupleid,
HeapTuple newtuple);
-
- /*
- * Deferred trigger stuff
- */
- typedef struct DeferredTriggerStatusData
- {
- Oid dts_tgoid;
- booldts_tgisdeferred;
- } DeferredTriggerStatusData;
-
- typedef struct DeferredTriggerStatusData *DeferredTriggerStatus;
-
- typedef struct DeferredTriggerEventItem
- {
- Oid dti_tgoid;
- int32 dti_state;
- } DeferredTriggerEventItem;
-
- typedef struct DeferredTriggerEventData *DeferredTriggerEvent;
-
- typedef struct DeferredTriggerEventData
- {
- DeferredTriggerEvent dte_next; /* list link */
- int32 dte_event;
- Oid dte_relid;
- ItemPointerData dte_oldctid;
- ItemPointerData dte_newctid;
- int32 dte_n_items;
- /* dte_item is actually a variable-size array, of length dte_n_items */
- DeferredTriggerEventItem dte_item[1];
- } DeferredTriggerEventData;
-
-
extern void DeferredTriggerInit(void);
extern void DeferredTriggerBeginXact(void);
extern void DeferredTriggerEndQuery(void);
extern void DeferredTriggerEndXact(void);
extern void DeferredTriggerAbortXact(void);
!
extern void DeferredTriggerSetState(ConstraintsSetStmt *stmt);
-
/*
* in utils/adt/ri_triggers.c
*/
--- 151,165
ItemPointer tupleid,
HeapTuple newtuple);
extern void DeferredTriggerInit(void);
extern void DeferredTriggerBeginXact(void);
extern void DeferredTriggerEndQuery(void);
extern void DeferredTriggerEndXact(void);
extern void DeferredTriggerAbortXact(void);
! extern void DeferredTriggerBeginSubXact(void);
! extern void DeferredTriggerEndSubXact(bool isCommit);
extern void DeferredTriggerSetState(ConstraintsSetStmt *stmt);
/*
* in utils/adt/ri_triggers.c
*/
Index: backend/commands/trigger.c
===
RCS file: /home/alvherre/cvs/pgsql-server/src/backend/commands/trigger.c,v
retrieving revision 1.165
diff -c -r1.165 trigger.c
*** backend/commands/trigger.c 26 May 2004 04:41:12 - 1.165
--- backend/commands/trigger.c 26 Jun 2004 18:12:01 -
***
*** 50,58
MemoryContext per_tuple_context);
static void DeferredTriggerSaveEvent(ResultRelInfo *relinfo, int event,
bool row_trigger, HeapTuple oldtup, HeapTuple
newtup);
- static void DeferredTriggerExecute(DeferredTriggerEvent event, int itemno,
- Relation rel, TriggerDesc *trigdesc, FmgrInfo
*finfo,
- MemoryContext per_tuple_context);
/*
--- 50,55
***
*** 1639,1685
/* --
* Deferred trigger stuff
* --
*/
! typedef struct DeferredTriggersData
{
! /* Internal data is held in a per-transaction memory context */
! MemoryContext deftrig_cxt;
! /* ALL DEFERRED or ALL IMMEDIATE */
! booldeftrig_all_isset;
! booldeftrig_all_isdeferred;
! /* Per trigger state */
! List *deftrig_trigstates;
! /* List of pending deferred triggers. Previous comment below */
! DeferredTriggerEvent deftrig_events;
! DeferredTriggerEvent deftrig_events_imm;
! DeferredTriggerEvent deftrig_event_tail;
! } DeferredTriggersData;
! /* --
! * deftrig_events, deftrig_event_tail:
! * The list of pending deferred trigger events during the current transaction.
*
! * deftrig_events is the head, deftrig_event_tail is the last entry.
! * Because this can grow pretty large, we don't use separate List nodes,
! * but instead thread the list through the dte_next fields of the member
! * nodes. Saves just a few bytes
Re: [PATCHES] nested xacts and phantom Xids
On Sun, Jun 27, 2004 at 12:49:10AM -0400, Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > I'll work on adding the Xid-cache to PGPROC and using that in > > TransactionIdIsInProgress and the tqual routines. If you want to work > > on that let me know and I'll handle things like the password file, local > > bufmgr refcount, etc. > > Either one is okay, though doing the latter (ie modules you didn't touch > yet) would be probably a bit easier to merge. Will do. -- Alvaro Herrera () "Un poeta es un mundo encerrado en un hombre" (Victor Hugo) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[PATCHES] nested xacts: update password file
An untested patch to update the password file.
Something that bugged me a lot is that I tried to find the format of the
file for testing the patch, and I couldn't find anything anywhere in the
docs. Apparently the docs for the file were ripped with the docs for
the pg_passwd utility when it was ripped before the 7.3 release.
--
Alvaro Herrera ()
"Some men are heterosexual, and some are bisexual, and some
men don't think about sex at all... they become lawyers" (Woody Allen)
Index: src/backend/commands/user.c
===
RCS file: /home/alvherre/cvs/pgsql-server/src/backend/commands/user.c,v
retrieving revision 1.141
diff -c -r1.141 user.c
*** src/backend/commands/user.c 26 May 2004 04:41:12 - 1.141
--- src/backend/commands/user.c 27 Jun 2004 21:49:37 -
***
*** 44,51
extern bool Password_encryption;
! static bool user_file_update_needed = false;
! static bool group_file_update_needed = false;
static void CheckPgUserAclNotNull(void);
--- 44,63
extern bool Password_encryption;
! /*
! * The need-to-update-files flags are a pair of TransactionId that show what
! * level of the transaction tree requested the update. To register an update,
! * the transaction saves its own TransactionId in the flag, unless the value
! * was already set to a valid TransactionId. If it aborts and the value is its
! * TransactionId, it resets the value to InvalidTransactionId. If it commits,
! * it changes the value to its parent's TransactionId. This way the value is
! * propagated up to the topmost transaction, which will update the files if a
! * valid TransactionId is detected.
! *
! * This is the same logic used for RelcacheInitFileInval in inval.c.
! */
! static TransactionId user_file_update_needed = InvalidTransactionId;
! static TransactionId group_file_update_needed = InvalidTransactionId;
static void CheckPgUserAclNotNull(void);
***
*** 402,409
Datum
update_pg_pwd_and_pg_group(PG_FUNCTION_ARGS)
{
! user_file_update_needed = true;
! group_file_update_needed = true;
return PointerGetDatum(NULL);
}
--- 414,424
Datum
update_pg_pwd_and_pg_group(PG_FUNCTION_ARGS)
{
! if (user_file_update_needed == InvalidTransactionId)
! user_file_update_needed = GetCurrentTransactionId();
!
! if (group_file_update_needed == InvalidTransactionId)
! group_file_update_needed = GetCurrentTransactionId();
return PointerGetDatum(NULL);
}
***
*** 429,441
Relationurel = NULL;
Relationgrel = NULL;
! if (!(user_file_update_needed || group_file_update_needed))
return;
if (!isCommit)
{
! user_file_update_needed = false;
! group_file_update_needed = false;
return;
}
--- 444,457
Relationurel = NULL;
Relationgrel = NULL;
! if (user_file_update_needed == InvalidTransactionId &&
! group_file_update_needed == InvalidTransactionId)
return;
if (!isCommit)
{
! user_file_update_needed = InvalidTransactionId;
! group_file_update_needed = InvalidTransactionId;
return;
}
***
*** 447,468
* pg_shadow or pg_group, which likely won't have gotten a strong
* enough lock), so get the locks we need before writing anything.
*/
! if (user_file_update_needed)
urel = heap_openr(ShadowRelationName, ExclusiveLock);
! if (group_file_update_needed)
grel = heap_openr(GroupRelationName, ExclusiveLock);
/* Okay to write the files */
! if (user_file_update_needed)
{
! user_file_update_needed = false;
write_user_file(urel);
heap_close(urel, NoLock);
}
! if (group_file_update_needed)
{
! group_file_update_needed = false;
write_group_file(grel);
heap_close(grel, NoLock);
}
--- 463,484
* pg_shadow or pg_group, which likely won't have gotten a strong
* enough lock), so get the locks we need before writing anything.
*/
! if (user_file_update_needed != InvalidTransactionId)
urel = heap_openr(ShadowRelationName, ExclusiveLock);
! if (group_file_update_needed != InvalidTransactionId)
grel = heap_openr(GroupRelationName, ExclusiveLock);
/* Okay to write the files */
! if (user_file_update_needed != InvalidTransactionId)
{
! user_file_update_needed = InvalidTransactionId;
write_user_file(urel);
heap_close(urel, NoLock);
[PATCHES] typo in runtime.sgml
Corrects a wrong filename separation. Please apply. -- Alvaro Herrera () You liked Linux a lot when he was just the gawky kid from down the block mowing your lawn or shoveling the snow. But now that he wants to date your daughter, you're not so sure he measures up. (Larry Greenemeier) Index: doc/src/sgml/runtime.sgml === RCS file: /home/alvherre/cvs/pgsql-server/doc/src/sgml/runtime.sgml,v retrieving revision 1.267 diff -c -r1.267 runtime.sgml *** doc/src/sgml/runtime.sgml 24 Jun 2004 19:26:55 - 1.267 --- doc/src/sgml/runtime.sgml 27 Jun 2004 22:10:09 - *** *** 3560,3567 Other parameters are sufficiently sized for any application. If you want to see for yourself look in ! /usr/src/linux/include/asm-xxx/shmpara ! m.h and /usr/src/linux/include/linux/sem.h. --- 3560,3567 Other parameters are sufficiently sized for any application. If you want to see for yourself look in ! /usr/src/linux/include/asm-xxx/shmparam.h ! and /usr/src/linux/include/linux/sem.h. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] nested xacts and phantom Xids
On Tue, Jun 29, 2004 at 03:22:52PM -0400, Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > - GUC vars are rolled back on subxact abort > > This did not work very well, but here is a revised GUC patch that I think > does work. It requires xact.c to export a function to report the > current nesting depth, and requires AtEOXact_GUC to be called in all > four cleanup paths (main and subxact commit and abort). Very cool, thank you. I had thought about doing something like this but in the end I got scared away of changing too much code here. > BTW, why do you have assign_transaction_read_only() in your patch? It > seems to me to be useful to create a readonly subxact of a read-write > outer transaction. Or is that just not-done-yet? Nah, it's a leftover from back when there wasn't any way to roll back GUC vars. I thought it should be handled similarly to the way the isolation level should be handled. With your patch I think it can be ripped away entirely. -- Alvaro Herrera () Officer Krupke, what are we to do? Gee, officer Krupke, Krup you! (West Side Story, "Gee, Officer Krupke") ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] nested xacts and phantom Xids
On Sun, Jun 20, 2004 at 08:49:22PM -0400, Tom Lane wrote:
> There's a good deal more than that missing :-(. Here are the modules or
> actions that are called in CommitTransaction and/or AbortTransaction
> that have not yet been touched by the patch:
>
> localbuf.c (refcounts need fixed same as bufmgr)
Here is a patch against the original versions of these files; cleaned up
bufmgr.c somewhat. Adds the same logic to local buffers (moving the
BufferRefCount struct declaration to buf_internals.h so it's shared by
both bufmgr.c and localbuf.c). Needs xact.c and xact.h patched as in
the second patch.
As with the bufmgr.c original patch, I don't really know how to test
that this actually works. I fooled around with printing what it was
doing during a subtrans commit/abort, and it seems OK, but that's about
it. In what situations can a transaction roll back with a nonzero
reference count in a local buffer?
--
Alvaro Herrera ()
"I dream about dreams about dreams", sang the nightingale
under the pale moon (Sandman)
Index: src/include/storage/bufmgr.h
===
RCS file: /home/alvherre/cvs/pgsql-server/src/include/storage/bufmgr.h,v
retrieving revision 1.82
diff -c -r1.82 bufmgr.h
*** src/include/storage/bufmgr.h31 May 2004 19:24:05 - 1.82
--- src/include/storage/bufmgr.h21 Jun 2004 20:29:08 -
***
*** 148,153
--- 148,155
extern char *ShowBufferUsage(void);
extern void ResetBufferUsage(void);
extern void AtEOXact_Buffers(bool isCommit);
+ extern void AtSubStart_Buffers(void);
+ extern void AtEOSubXact_Buffers(bool commit);
extern void FlushBufferPool(void);
extern BlockNumber BufferGetBlockNumber(Buffer buffer);
extern BlockNumber RelationGetNumberOfBlocks(Relation relation);
Index: src/include/storage/buf_internals.h
===
RCS file: /home/alvherre/cvs/pgsql-server/src/include/storage/buf_internals.h,v
retrieving revision 1.71
diff -c -r1.71 buf_internals.h
*** src/include/storage/buf_internals.h 18 Jun 2004 06:14:13 - 1.71
--- src/include/storage/buf_internals.h 29 Jun 2004 13:21:23 -
***
*** 175,180
--- 175,189
extern long int BufferFlushCount;
extern long int LocalBufferFlushCount;
+ /*
+ * We use a list of this struct to keep track of buffer reference
+ * count checking at subtransaction boundaries.
+ */
+ typedef struct BufferRefCount
+ {
+ Buffer buffer;
+ int refcount;
+ } BufferRefCount;
/*
* Bufmgr Interface:
***
*** 211,215
--- 220,226
bool *foundPtr);
extern void WriteLocalBuffer(Buffer buffer, bool release);
extern void AtEOXact_LocalBuffers(bool isCommit);
+ extern void AtSubStart_LocalBuffers(void);
+ extern void AtSubEnd_LocalBuffers(bool isCommit);
#endif /* BUFMGR_INTERNALS_H */
Index: src/backend/storage/buffer/bufmgr.c
===
RCS file: /home/alvherre/cvs/pgsql-server/src/backend/storage/buffer/bufmgr.c,v
retrieving revision 1.171
diff -c -r1.171 bufmgr.c
*** src/backend/storage/buffer/bufmgr.c 18 Jun 2004 06:13:33 - 1.171
--- src/backend/storage/buffer/bufmgr.c 29 Jun 2004 20:26:09 -
***
*** 38,43
--- 38,44
#include
#include
+ #include "access/xact.h"
#include "lib/stringinfo.h"
#include "miscadmin.h"
#include "storage/buf_internals.h"
***
*** 46,51
--- 47,53
#include "storage/proc.h"
#include "storage/smgr.h"
#include "utils/relcache.h"
+ #include "utils/memutils.h"
#include "pgstat.h"
***
*** 67,72
--- 69,75
static void PinBuffer(BufferDesc *buf);
static void UnpinBuffer(BufferDesc *buf);
+ static inline void BufferFixLeak(Buffer buffer, int should, bool warn);
static void WaitIO(BufferDesc *buf);
static void StartBufferIO(BufferDesc *buf, bool forInput);
static void TerminateBufferIO(BufferDesc *buf, int err_flag);
***
*** 826,853
for (i = 0; i < NBuffers; i++)
{
if (PrivateRefCount[i] != 0)
! {
! BufferDesc *buf = &(BufferDescriptors[i]);
! if (isCommit)
! elog(WARNING,
!"buffer refcount leak: [%03d] "
!"(rel=%u/%u/%u, blockNum=%u, flags=0x%x,
refcount=%u %d)",
!i,
!buf->tag.rnode.spcNode, buf->tag.rnode.dbNode,
!buf->tag.rnode.relNode,
!buf
Re: [PATCHES] nested xacts and phantom Xids
On Tue, Jun 29, 2004 at 06:59:20PM -0400, Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > As with the bufmgr.c original patch, I don't really know how to test > > that this actually works. [...] > > I forgot to mention to you that that code didn't work at all, btw. Bad news, I guess. > The other theory we could adopt is that cursors stay open till main xact > commit; this would imply not releasing buffer refcounts at subxact > commit, plus any other resources needed by the cursor. We're already > holding locks that way and it probably wouldn't be a big change to make > bufmgr work the same. I'm not sure that there are any other resources > involved, other than the Portal memory which we already handle properly. Well, AFAIR originally I had thought that refcounts should be held at subtrans commit; you suggested that there was no reason for a subtrans to keep a buffer refcount and that was it. I think the open cursor is a good reason why the count should be kept; it appears less useful if you can't use the cursor anywhere out of the level that created it. > Oh, there's another point: what happens if an outer xact level declares > a cursor, which is then FETCHed from by a subtransaction? At minimum we > have the problem that this could change the set of buffer pins held, > which breaks the present bufmgr solution entirely. It gets even more > interesting if you are of the opinion that subtransaction failure should > cause the effects of the FETCH to be undone --- we have no way to do > that at all, because there's no mechanism for saving/restoring the state > of an entire execution plan tree. Hmm ... yes, this could be very ugly indeed, but I haven't even looked at the executor code so I can't comment. Are executor nodes copyable? Oh, and I've been playing with large objects and I've encountered bugs elsewhere. I'll look at it with the new patch you just posted. -- Alvaro Herrera () "Vivir y dejar de vivir son soluciones imaginarias. La existencia está en otra parte" (Andre Breton) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] latest plperl
On Thu, Jul 01, 2004 at 09:33:57AM -0700, Joe Conway wrote: > As a side note, I think it would be *really* helpful if there were a > more comprehensive test script, and an expected results file available. > Not sure though if it could be included in the standard regression tests > on a configure-conditional basis -- anyone know? Can't this stuff be tested somehow using Test::Simple, Test::Harness or something like that? I know this is not standard perl stuff but ... -- Alvaro Herrera () "I call it GNU/Linux. Except the GNU/ is silent." (Ben Reiter) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[PATCHES] [subxacts] Using a different syntax
Hackers, Here is a patch covering the syntax change. This changes the current subtransaction-initiating command to SUBBEGIN instead of BEGIN; similarly SUBCOMMIT and SUBABORT. I did not add a SUBROLLBACK command ... rather I want to use the standard syntax "SAVEPOINT " and "ROLLBACK TO " and keep our nonstandard syntax small. Note that with this patch it is possible to start a subtransaction when not in a transaction block. This makes the new commands to behave almost exactly like toplevel BEGIN/COMMIT (the difference is not visible to the user: the server is in nesting level 2 rather than 1, but the outer level will automatically commit or roll back). This also means that a single COMMIT will commit the whole transaction tree: BEGIN; create table foo (a int); SUBBEGIN; insert into foo values (1); SUBBEGIN; insert into foo values (2); COMMIT; Also a single ABORT/ROLLBACK aborts the whole thing. Included in this patch is the ability to "ignore errors" in a subcommit, so this works: begin; subbegin; drop table foo; -- error: table does not exist subcommit ignore errors; create table foo (...); commit; The point is that this can be executed in a dumb script without worrying about whether the subtransaction will cause an error or not. I'm not sure if the grammar modifications are good. I thought about using two Sconst and comparing them to "ignore errors" ... right now, "ignore" and "errors" are in the unreserved keywords list and I get no errors/warnings from bison, but please check this. I had to add a new transaction block state to support rolling back a whole transaction tree. Also I moved the TransactionState declaration to xact.c because it has no business being in the xact.h header file that I can see. I made some changes to SPI so that it forbids to close a subtransaction that the _SPI_connection did not open, by saving the nesting level at SPI_connect() time and checking when SPI_execute is called. I had thought that it would be easy to return to that nesting level if the function errored out, but I was quite wrong (because the SPI code stops executing immediately as soon as an error is encountered). Now I don't know how to do that at all. I also thought about adding something to the sigsetjmp() block but I don't have a clue how to handle this. Regression tests pass; I had to change the transaction test to adopt the new syntax. I also added a couple of tests to verify the new functionality. -- Alvaro Herrera () "La experiencia nos dice que el hombre peló millones de veces las patatas, pero era forzoso admitir la posibilidad de que en un caso entre millones, las patatas pelarían al hombre" (Ijon Tichy) Index: src/backend/access/transam/xact.c === RCS file: /home/alvherre/cvs/pgsql-server/src/backend/access/transam/xact.c,v retrieving revision 1.170 diff -c -r1.170 xact.c *** src/backend/access/transam/xact.c 1 Jul 2004 20:11:02 - 1.170 --- src/backend/access/transam/xact.c 5 Jul 2004 03:40:48 - *** *** 173,215 #include "pgstat.h" ! static void AbortTransaction(void); ! static void AtAbort_Cache(void); ! static void AtAbort_Locks(void); ! static void AtAbort_Memory(void); ! static void AtCleanup_Memory(void); ! static void AtCommit_Cache(void); ! static void AtCommit_LocalCache(void); ! static void AtCommit_Locks(void); ! static void AtCommit_Memory(void); ! static void AtStart_Cache(void); ! static void AtStart_Locks(void); ! static void AtStart_Memory(void); ! static void CallEOXactCallbacks(bool isCommit); ! static void CleanupTransaction(void); ! static void CommitTransaction(void); ! static void RecordTransactionAbort(void); ! static void StartTransaction(void); ! ! static void RecordSubTransactionCommit(void); ! static void StartSubTransaction(void); ! static void CommitSubTransaction(void); ! static void AbortSubTransaction(void); ! static void CleanupSubTransaction(void); ! static void StartAbortedSubTransaction(void); ! static void PushTransaction(void); ! static void PopTransaction(void); ! ! static void AtSubAbort_Locks(void); ! static void AtSubAbort_Memory(void); ! static void AtSubCleanup_Memory(void); ! static void AtSubCommit_Memory(void); ! static void AtSubStart_Memory(void); ! static void ShowTransactionState(const char *str); ! static void ShowTransactionStateRec(TransactionState state); ! static const char *BlockStateAsString(TBlockState blockState); ! static const char *TransStateAsString(TransState state); /* * CurrentTransactionState always points to the current transaction state --- 173,234 #include "pgstat.h" ! /* ! *transaction states - transaction state from server perspective
[PATCHES] value.h has no VALUE_H
The outer #define was forgotten. Attached patch adds it; please apply. -- Alvaro Herrera () "Sallah, I said NO camels! That's FIVE camels; can't you count?" (Indiana Jones) Index: src/include/nodes/value.h === RCS file: /home/alvherre/cvs/pgsql-server/src/include/nodes/value.h,v retrieving revision 1.1 diff -c -r1.1 value.h *** src/include/nodes/value.h 7 Jan 2004 18:43:36 - 1.1 --- src/include/nodes/value.h 10 Jul 2004 23:11:00 - *** *** 11,16 --- 11,19 *- */ + #ifndef VALUE_H + #define VALUE_H + #include "nodes/nodes.h" /*-- *** *** 54,56 --- 57,61 extern Value *makeFloat(char *numericStr); extern Value *makeString(char *str); extern Value *makeBitString(char *str); + + #endif/* VALUE_H */ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] nested xacts: update password file
On Mon, Jul 12, 2004 at 12:05:40PM -0400, Bruce Momjian wrote: > > Alvaro, you call GetParentTransactionId(), but I see not definition for > it in the code. Let me include this patch in the next patch I'll submit shortly. -- Alvaro Herrera () "I suspect most samba developers are already technically insane... Of course, since many of them are Australians, you can't tell." (L. Torvalds) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] nested xacts: update password file
On Mon, Jul 12, 2004 at 02:18:40PM -0400, Bruce Momjian wrote: > > >> Something that bugged me a lot is that I tried to find the format of the > > >> file for testing the patch, and I couldn't find anything anywhere in the > > >> docs. Apparently the docs for the file were ripped with the docs for > > >> the pg_passwd utility when it was ripped before the 7.3 release. > > I was confused by this. What docs for the password file did we have? I see this in 7.2 docs. This is not mentioned anywhere in current docs. Does it work with other auth mechanisms (md5, crypt)? The format of a text password file is one entry per line; the fields of each entry are separated by colons. The first field is the user name, the second field is the encrypted password. Other fields are ignored (to allow password files to be shared between applications that use similar formats). pg_passwd enables users to interactively add entries to such a file, to alter passwords of existing entries, and to encrypt such passwords. [...] To make use of this password file, put a line like the following in pg_hba.conf: host mydb 133.65.96.250 255.255.255.255 password passwords which would allow access to database mydb from host 133.65.96.250 using the passwords listed in the passwords file (and only to the users listed in that file). It is also useful to have entries in a password file with empty password fields. (This is different from an empty password.) Such entries allow you to restrict users who can access the system. These entries cannot be managed by pg_passwd, but you can edit password files manually. -- Alvaro Herrera () "La primera ley de las demostraciones en vivo es: no trate de usar el sistema. Escriba un guión que no toque nada para no causar daños." (Jakob Nielsen) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] nested xacts: update password file
On Mon, Jul 12, 2004 at 02:31:37PM -0400, Bruce Momjian wrote: > OK, but why would we document the contents of a file that are not to be > modified by the user? But how is the file used? Where do I put the file, what do I put in pg_hba.conf to use the file? Can I have several files, one per pg_hba.conf entry? Can I use multiple files with a single pg_hba.conf entry? What happens if I have a username that has the separator in it? -- Alvaro Herrera () "Los dioses no protegen a los insensatos. Éstos reciben protección de otros insensatos mejor dotados" (Luis Wu, Mundo Anillo) ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] nested xacts: update password file
On Mon, Jul 12, 2004 at 03:19:43PM -0400, Bruce Momjian wrote: > Alvaro Herrera wrote: > > On Mon, Jul 12, 2004 at 02:31:37PM -0400, Bruce Momjian wrote: > > > > > OK, but why would we document the contents of a file that are not to be > > > modified by the user? > > > > But how is the file used? Where do I put the file, what do I put in > > pg_hba.conf to use the file? Can I have several files, one per > > pg_hba.conf entry? Can I use multiple files with a single pg_hba.conf > > entry? What happens if I have a username that has the separator in it? > > We no longer have the capability for external password files, which is > what the 7.2 docs were talking about. We removed it when we went to > encrypted MD5 password and pg_hba.conf entries where you can reference > external lists of users and groups. > > The file you were touching is a cache of usernames written by backends > modifing the pg_shadow table and read by the postmaster. Oh, I see! Thanks for the clarification. -- Alvaro Herrera () "XML!" Exclaimed C++. "What are you doing here? You're not a programming language." "Tell that to the people who use me," said XML. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] initdb authentication
On Thu, Jul 15, 2004 at 11:20:46PM +0200, Peter Eisentraut wrote: > Magnus Hagander wrote: > > This one makes it mandatory to pick some kind of authentication. If > > that's not wanted, it's easy to change it to default to trust (which > > I think is wrong, but we've been through that already..) > > I don't think I like any of this. Sooner rather than later, people need > to look at pg_hba.conf and think about it. I don't like switches that > induce them to skip that step. And I certainly don't like forcing > extra switches on users that just try out an installation locally. I agree with this sentiment. On the spanish list is common to see people trying to do things on an RPM-installed server, which is configured to use IDENT by default, and asking why they cannot connect. The answer is always to look at pg_hba.conf and the relevant documentation. If it were my choice, I'd disallow connections by default completely, and spit a reject message along the lines of "you should have a look at pg_hba.conf". -- Alvaro Herrera () "Uno combate cuando es necesario... ¡no cuando está de humor! El humor es para el ganado, o para hacer el amor, o para tocar el baliset. No para combatir." (Gurney Halleck) ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] [subxacts] Savepoint syntax
On Wed, Jul 14, 2004 at 03:03:02PM -0400, Alvaro Herrera wrote: > Please test, review and apply. If anyone is able to crash the server > using this I'll be most interested. I just noticed that the "misc" regression test is generated, and so it needs to be patched ... interdiff output attached. -- Alvaro Herrera () "Entristecido, Wutra (canción de Las Barreras) echa a Freyr a rodar y a nosotros al mar" only in patch2: unchanged: --- src/test/regress/output/misc.source 10 May 2004 22:44:49 - 1.42 +++ src/test/regress/output/misc.source 16 Jul 2004 05:08:18 - @@ -644,6 +644,7 @@ real_city reltime_tbl road + savepoints shighway slow_emp4000 street @@ -661,7 +662,7 @@ toyemp varchar_tbl xacttest -(97 rows) +(98 rows) SELECT name(equipment(hobby_construct(text 'skywalking', text 'mer'))); name ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[PATCHES] [subxact] Proof-of-concept: report nest level to client
Hackers,
I tried to implement the reporting of the current transaction level to
the client using an ad-hoc ParameterStatus message. Seems it works.
To see it working I added a %d escape to psql prompt processing:
alvherre=# \set PROMPT1 '[EMAIL PROTECTED]/%R[%d]%x '
[EMAIL PROTECTED] begin;
BEGIN
[EMAIL PROTECTED] savepoint foo;
SAVEPOINT
[EMAIL PROTECTED] savepoint bar;
SAVEPOINT
[EMAIL PROTECTED] release foo;
RELEASE
[EMAIL PROTECTED] savepoint another;
SAVEPOINT
[EMAIL PROTECTED] commit;
COMMIT
[EMAIL PROTECTED]
(The nesting level, obviously, is the number between [ ]; the * is the
"in transaction" mark, which existed previously. Yes, it works if it's
> 9.)
Patch attached (surprinsingly small), though it only applies with the
savepoint patch applied(*). If any driver writer wants to play, however,
it's easy to see what's going on -- a ParameterStatus message will be
received from the backend whenever the nesting level changes.
I added a function PQnestingLevel() to libpq, and a corresponding field
in pg_conn. We have to decide if we like the name, and whether we want
to have it at all.
(This is different from the previous idea in that the nesting level is
not a GUC variable -- the message is sent directly from xact.c. If this
is a bad idea, just moving the SendTransactionNestingLevel() function
can be moved somewhere else, though I couldn't figure out where.)
(*) Even then, this is hand-edited output of interdiff, so maybe it
doesn't apply at all ... if this is the case I'll submit a better patch
tomorrow.
--
Alvaro Herrera ()
"No hay hombre que no aspire a la plenitud, es decir,
la suma de experiencias de que un hombre es capaz"
diff -u src/backend/access/transam/xact.c src/backend/access/transam/xact.c
--- src/backend/access/transam/xact.c 16 Jul 2004 05:40:09 -
+++ src/backend/access/transam/xact.c 16 Jul 2004 07:04:35 -
@@ -159,6 +159,8 @@
#include "commands/user.h"
#include "executor/spi.h"
#include "libpq/be-fsstubs.h"
+#include "lib/stringinfo.h"
+#include "libpq/pqformat.h"
#include "miscadmin.h"
#include "storage/fd.h"
#include "storage/proc.h"
@@ -341,6 +343,7 @@
static void ShowTransactionStateRec(TransactionState state);
static const char *BlockStateAsString(TBlockState blockState);
static const char *TransStateAsString(TransState state);
+static void SendTransactionNestingLevel(void);
/*
* transaction state accessors
@@ -1360,6 +1369,8 @@
*/
s->state = TRANS_INPROGRESS;
+ SendTransactionNestingLevel();
+
ShowTransactionState("StartTransaction");
}
@@ -1486,6 +1508,8 @@
*/
s->state = TRANS_DEFAULT;
+ SendTransactionNestingLevel();
+
RESUME_INTERRUPTS();
}
@@ -1627,6 +1651,8 @@
s->nestingLevel = 0;
s->childXids = NIL;
+ SendTransactionNestingLevel();
+
/*
* done with abort processing, set current transaction state back to
* default
@@ -2741,6 +2767,8 @@
s->blockState != TBLOCK_SUBENDABORT_ALL)
AbortSubTransaction();
s->blockState = TBLOCK_SUBABORT;
+
+ SendTransactionNestingLevel();
}
/*
@@ -2762,6 +2790,8 @@
PopTransaction();
s = CurrentTransactionState;/* changed by
pop */
}
+
+ SendTransactionNestingLevel();
}
/*
@@ -2893,15 +2930,17 @@
/* Initialize the various transaction subsystems */
AtSubStart_Memory();
AtSubStart_Inval();
AtSubStart_RelationCache();
AtSubStart_CatCache();
AtSubStart_Buffers();
AtSubStart_smgr();
AtSubStart_Notify();
DeferredTriggerBeginSubXact();
s->state = TRANS_INPROGRESS;
+ SendTransactionNestingLevel();
+
ShowTransactionState("StartSubTransaction");
}
@@ -2942,11 +2981,13 @@
AtEOSubXact_on_commit_actions(true, s->transactionIdData,
s->parent->transactionIdData);
AtEOSubXact_CatCache(true);
AtEOSubXact_RelationCache(true);
AtEOSubXact_Buffers(true);
AtSubCommit_Memory();
+ SendTransactionNestingLevel();
+
s->state = TRANS_DEFAULT;
}
@@ -3045,6 +3087,8 @@
AtSubCleanup_Portals();
AtSubCleanup_Memory();
+ SendTransactionNestingLevel();
+
s->state = TRANS_DEFAULT;
}
@@ -3160,6 +3204,22 @@
pfree(s);
}
+static void
+SendTransactionNestingLevel(void)
+{
+ char*val = (char *)palloc(12);
+ StringInfoData msgbuf;
+
+ snprintf(val, 12, "%d", CurrentTransactionState->nestingLevel);
+
+ pq_beginmessag
Re: [PATCHES] [subxacts] Savepoint syntax
On Sun, Jul 25, 2004 at 04:58:01PM -0400, Alvaro Herrera wrote: > Attached is the savepoints syntax patch, hopefully last try. > Essentially the same as the last patch, with the following differences: Brown paper bag patch. Please disregard. I'll post a good patch tomorrow morning. Sorry for the noise, -- Alvaro Herrera () "Having your biases confirmed independently is how scientific progress is made, and hence made our great society what it is today" (Mary Gardiner) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[PATCHES] [subxacts] Some docs
Hackers, Here is a doc patch that includes pages for savepoint commands. It would be cool if they can be applied as starting points for savepoint documentation. Poeple who can do better, please feel free to improve in any way. -- Alvaro Herrera () "Cómo ponemos nuestros dedos en la arcilla del otro. Eso es la amistad; jugar al alfarero y ver qué formas se pueden sacar del otro" (C. Halloway en La Feria de las Tinieblas, R. Bradbury) diff -Ncr --exclude-from=diff-ignore 00orig/doc/src/sgml/advanced.sgml 03pgproc/doc/src/sgml/advanced.sgml *** 00orig/doc/src/sgml/advanced.sgml 2004-04-14 16:45:53.0 -0400 --- 03pgproc/doc/src/sgml/advanced.sgml 2004-07-26 22:39:01.689881464 -0400 *** *** 257,262 --- 257,310 you are using. + + + It's possible to control the statements in a transaction in a more + granular fashion through the use of savepoints. Savepoints + allow you to selectively discard parts of the transaction, while + committing the rest. This is done be defining a savepoint with + SAVEPOINT, to which you can later roll back using + ROLLBACK TO. All statements between defining the savepoint + and rolling back to it will have no effect on the final transaction. + + + + After rolling back to a savepoint, it continues to be defined, so you can + roll back to it several times. Conversely, if you are sure you won't need + to roll back to a particular savepoint again, it can be released, so the + system can free some resources. Keep in mind that releasing a savepoint + will automatically release all savepoints that were defined after it. + + + + Remembering the bank database, suppose we debit $100.00 from Alice's + account, and credit Bob's account, only to find later that we wanted to + credit Wally's account. We could do it using savepoints like + + + BEGIN; + UPDATE accounts SET balance = balance - 100.00 + WHERE name = 'Alice'; + SAVEPOINT my_savepoint; + UPDATE accounts SET balance = balance + 100.00 + WHERE name = 'Bob'; + -- oops ... forget that and use Wally's account + ROLLBACK TO my_savepoint; + UPDATE accounts SET balance = balance + 100.00 + WHERE name = 'Wally'; + COMMIT; + + + + + This example is, of course, oversimplified, but there's a lot of control + to be had over a transaction block through the use of savepoints. + Moreover, ROLLBACK TO is the only way to regain control of a + transaction block that was automatically put on aborted state by the + system for some reason, short of rolling it back completely and starting + again. + + diff -Ncr --exclude-from=diff-ignore 00orig/doc/src/sgml/ref/allfiles.sgml 03pgproc/doc/src/sgml/ref/allfiles.sgml *** 00orig/doc/src/sgml/ref/allfiles.sgml 2004-06-26 00:28:45.0 -0400 --- 03pgproc/doc/src/sgml/ref/allfiles.sgml 2004-07-26 18:27:47.0 -0400 *** *** 88,96 --- 88,99 + + + diff -Ncr --exclude-from=diff-ignore 00orig/doc/src/sgml/ref/begin.sgml 03pgproc/doc/src/sgml/ref/begin.sgml *** 00orig/doc/src/sgml/ref/begin.sgml 2004-01-11 06:24:17.0 -0300 --- 03pgproc/doc/src/sgml/ref/begin.sgml2004-07-26 18:49:53.0 -0400 *** *** 145,150 --- 145,151 + diff -Ncr --exclude-from=diff-ignore 00orig/doc/src/sgml/ref/release.sgml 03pgproc/doc/src/sgml/ref/release.sgml *** 00orig/doc/src/sgml/ref/release.sgml1969-12-31 21:00:00.0 -0300 --- 03pgproc/doc/src/sgml/ref/release.sgml 2004-07-26 19:07:17.0 -0400 *** *** 0 --- 1,138 + + + + + RELEASE + SQL - Language Statements + + + + RELEASE + destroy a previously defined savepoint + + + + RELEASE + + + + savepoints + releasing + + + + + RELEASE savepoint_name + + + + + Description + + +RELEASE destroys a previously defined savepoint +in the current transaction. + + + +Destroying a savepoint makes it—and all savepoints established after +it was established—unavailable as rollback points, +but it has no other user visible behavior. It does not undo the +effects of command executed after the savepoint was established. +To do that, see . + + + +RELEASE also destroys all savepoints that were established +after the named savepoint was established. + + + + Parameters + + + + savepoint_name + + + The name of the savepoint to destroy. + + + + + + + + Notes + + +Specifying a savepoint name that was not previously defined raises +an exception. + + + +It is not possible to release a savepoint when the transaction is in +aborted state. + + +
Re: [HACKERS] [PATCHES] DOC: catalog.sgml
Tom Lane wrote: > Zdenek Kotala <[EMAIL PROTECTED]> writes: > > I little bit enhanced overview catalog tables. I added two new columns. > > First one is OID of catalog table and second one contains attributes > > which determine if the table is bootstrap, with oid and global. > > Why is this a good idea? It seems like mere clutter. What's "global"? A maybe-useful flag would be telling that a table is shared. Is that it? Mind you, it's not useful to me because I know which tables are shared, but I guess for someone not so familiar with the catalogs it could have some use. The OIDs may be useful to people inspecting pg_depend, for example; but then, it's foolish not to be using regclass in that case. Whether a table is "bootstrap" or not doesn't seem useful to me. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] Patch for UUID datatype (beta)
[EMAIL PROTECTED] wrote: > On Tue, Sep 19, 2006 at 08:20:13AM -0500, Jim C. Nasby wrote: > > On Mon, Sep 18, 2006 at 07:45:07PM -0400, [EMAIL PROTECTED] wrote: > > > I would not use a 100% random number generator for a UUID value as was > > > suggested. I prefer inserting the MAC address and the time, to at > > > least allow me to control if a collision is possible. This is not easy > > > to do using a few lines of C code. I'd rather have a UUID type in core > > > with no generation routine, than no UUID type in core because the code > > > is too complicated to maintain, or not portable enough. > > As others have mentioned, using MAC address doesn't remove the > > possibility of a collision. > > It does, as I control the MAC address. What happens if you have two postmaster running on the same machine? -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Too many messages from Autovacuum
Simon Riggs wrote: > No server settings seem appropriate to remove these... > > So, patch enclosed to change LOG -> DEBUG1 Applied, thanks. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES] test: please ignore
Tom Lane wrote: > "Magnus Hagander" <[EMAIL PROTECTED]> writes: > >> I've posted a 6.5kB patch (as an attachment) three times over the > >> past few days but haven't seen it hit the lists. Checking to see if > >> this goes through. > > > Did you by any chance gzip it? IIRC, mails with gzipped attachments are > > silently dropped on- patches for some reason. > > Hm? They've always worked fine for me, and for a lot of other people. > You should ask Marc to look into this. It depends on the MIME type IIRC. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] WAL logging freezing
Heikki Linnakangas wrote: > Here's a patch for WAL logging tuple freezes in vacuum, per discussion > on pgsql-bugs. > > This patch is against CVS head. Should this be backported to stable > branches? I think it should. Keep in mind that previous releases do not use the same method for determining the pg_clog cutoff point. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] [HACKERS] COPY does not work with regproc and aclitem
Zdenek Kotala wrote: > Tom Lane napsal(a): > >Zdenek Kotala <[EMAIL PROTECTED]> writes: > >>I prepared patch which use oid output function instead regproc output. > >>This change works only for COPY TO command. > > > >This is not a bug and we're not going to fix it, most especially not > >like that. > > OK, The behavior of regproc type is described in the documentation, but > if we don't fix it, than Some error message like "Regproc data type is > not supported by COPY TO command" could be useful. Because you find that > something is wrong when you want to restore data back and it should be > too late. But it works as "expected". If the approach you suggest would be one we would take, then it should emit the same error on SELECT as well, shouldn't we? I think the problem is that regproc COPY is not useful to you for your particular use case. But there are workarounds, like the one I suggested and you promptly ignored. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] WAL logging freezing
Heikki Linnakangas wrote: > We just discussed this in detail with Simon, and it looks like we have > 5 (!) different but related problems: Wow, four of them are mine :-( > 2) vactuple_get_minxid doesn't take into account xmax's of tuples that > have HEAP_XMAX_INVALID set. That's a problem: > > transaction 1001 - BEGIN; DELETE FROM foo where key = 1; > transaction 1001 - ROLLBACK; > transaction 1002 - VACUUM foo; > crash > > VACUUM foo will set relminxid to 1002, because HEAP_XMAX_INVALID was set > on the tuple (possibly by vacuum itself) that the deletion that rolled > back touched. However, that hint-bit update hasn't hit the disk yet, so > after recovery, the tuple will have an xmax of 1001 with no hint-bit, > and relminxid is 1002. > > The simplest fix for this issue is to ignore the HEAP_XMAX_INVALID hint > bit, and take any xmax other than InvalidXid into account when > calculating the relminxid. Ugh. Is there another solution to this? Say, sync the buffer so that the hint bits are written to disk? The bug (4) below is problematic if you take this approach; basically it removes all the optimization won by the relminxid patch. > Simon volunteered to make the clog changes for 3 because it's a PITR > related issue. I can write a patch/patches for the other changes if it > helps. I'm swamped at the moment, so I'd appreciate it. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PATCHES] WAL logging freezing
Simon Riggs wrote: > On Mon, 2006-10-30 at 12:05 -0500, Tom Lane wrote: > > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > > Ugh. Is there another solution to this? Say, sync the buffer so that > > > the hint bits are written to disk? > > > > Yeah. The original design for all this is explained by the notes for > > TruncateCLOG: > > > > * When this is called, we know that the database logically contains no > > * reference to transaction IDs older than oldestXact. However, we must > > * not truncate the CLOG until we have performed a checkpoint, to ensure > > * that no such references remain on disk either; else a crash just after > > * the truncation might leave us with a problem. > > > > The pre-8.2 coding is actually perfectly safe within a single database, > > because TruncateCLOG is only called at the end of a database-wide > > vacuum, and so the checkpoint is guaranteed to have flushed valid hint > > bits for all tuples to disk. There is a risk in other databases though. > > I think that in the 8.2 structure the equivalent notion must be that > > VACUUM has to flush and fsync a table before it can advance the table's > > relminxid. > > Ouch! We did discuss that also. Flushing the buffercache is nasty with > very large caches, so this makes autovacuum much less friendly - and > could take a seriously long time if you enforce the vacuum delay > costings. > > ISTM we only need to flush iff the clog would be truncated when we > update relminxid. Otherwise we are safe to update even if we crash, > since the clog will not have been truncated. I don't understand. When clog is actually going to be truncated, if it's determined that there's any page that can be truncated, then a checkpoint is forced. If no page is going to be removed then there's no checkpoint, which makes a lot of sense and of course avoids the problem of useless flushes. In fact I don't understand what's the point about multiple databases vs. a single database. Surely a checkpoint would flush all buffers in all databases, no? This would flush all hint bits, everywhere. So this bug does not really exist. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
