Re: [PATCHES] Allow commenting of variables in postgresql.conf to
Zdenek, On Wed, May 24, 2006 at 04:27:01PM +0200, Zdenek Kotala wrote: General config structure is extend with default_val attribute to keep really default value. (There is small conflict - for string boot_val has same meaning). During reconfiguration all values which has reset source equal with PGC_S_FILE are revert back to really default values. New values from configuration files are set after this step and commented variables stay with default value. Three points after a quick test: - please compile with --enable-cassert, there are wrong assertions in your code (you might just have to move some lines, there is an Assert() and an assignment thereafter) - changing a PGC_POSTMASTER should show a message: = parameter \%s\ cannot be changed after server start; configuration file change ignored This seems to not show up anymore with your patch. - with the same reasoning, I think it's a good idea to display a message about which option falls back to its default value. Joachim ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Allow commenting of variables in postgresql.conf to
Joachim, thanks for your comments. I am working on them. Zdenek Joachim Wieland wrote: Zdenek, Three points after a quick test: - please compile with --enable-cassert, there are wrong assertions in your code (you might just have to move some lines, there is an Assert() and an assignment thereafter) - changing a PGC_POSTMASTER should show a message: = parameter \%s\ cannot be changed after server start; configuration file change ignored This seems to not show up anymore with your patch. - with the same reasoning, I think it's a good idea to display a message about which option falls back to its default value. Joachim ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] plperl - put schema-name in $_TD
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Adam Sjøgren wrote: Enclosed is a tiny patch for plperl that puts the schema-name of the current table in $_TD, so triggers can access tables using schemaname.tablename, for instance like so: This seems like a good idea, but we should probably make analogous changes for plpgsql, pltcl and plpython. Having different trigger data available in some of these doesn't seem like a good idea. Yeah. I'm also a little disturbed by using nspname which is an entirely internal name; plus it's a bit unclear *which* schema it's supposed to be. (One might think it's the schema the trigger function is in, for instance.) Somebody established a bad precedent by using relname for the table name. Maybe we should use field names like table_name and table_schema. relname could be kept around for awhile but deprecated as a duplicate of table_name. Or if that seems too messy, keep relname but use relschema as the new field. regards, tom lane Here are the various bits of trigger data our languages get: plpgsql (function variables) : NEW OLD TG_NAME TG_WHEN TG_LEVEL TG_OP TG_RELID TG_RELNAME TH_NARGS TG_ARGV[] plperl (keys in %$_TD): new old name event when level relid relname argc args plpython (keys of TD): new old name event when level relid args pltcl: (function variables) $TG_name $TG_relid $TG_relatts $TG_when $TG_level $TG_op $NEW $OLD $args plpython and pltcl don't have relname, while only pltcl has relatts. Is relatts useful? should we provide it everywhere? I propose to add relname to plpython and pltcl, and relschema to all (mutatis mutandis w.r.t. names). cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] Binary COPY for psql
The attached patch enables psql to copy binary data in and out.
Regards,
Andreas
Index: src/bin/psql/copy.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/psql/copy.c,v
retrieving revision 1.60
diff -u -r1.60 copy.c
--- src/bin/psql/copy.c 5 Mar 2006 15:58:51 - 1.60
+++ src/bin/psql/copy.c 25 May 2006 15:17:58 -
@@ -284,9 +284,10 @@
fetch_next = true;
- /* someday allow BINARY here */
if (pg_strcasecmp(token, oids) == 0)
result-oids = true;
+ else if (pg_strcasecmp(token, binary) == 0)
+ result-binary = true;
else if (pg_strcasecmp(token, csv) == 0)
result-csv_mode = true;
else if (pg_strcasecmp(token, header) == 0)
@@ -442,8 +443,6 @@
initPQExpBuffer(query);
printfPQExpBuffer(query, COPY );
- if (options-binary)
- appendPQExpBuffer(query, BINARY );
appendPQExpBuffer(query, %s , options-table);
@@ -480,6 +479,9 @@
appendPQExpBuffer(query, WITH NULL AS '%s',
options-null);
}
+ if (options-binary)
+ appendPQExpBuffer(query, BINARY);
+
if (options-csv_mode)
appendPQExpBuffer(query, CSV);
@@ -622,7 +624,7 @@
if (buf)
{
- fputs(buf, copystream);
+ fwrite(buf, 1, ret, copystream);
PQfreemem(buf);
}
}
@@ -686,6 +688,21 @@
else
prompt = NULL;
+ if (!prompt)
+ {
+ int buflen;
+
+ while ((buflen = fread(buf, 1, COPYBUFSIZ, copystream)) 0)
+ {
+ if (PQputCopyData(conn, buf, buflen) = 0)
+ {
+ OK = false;
+ copydone = true;
+ break;
+ }
+ }
+ }
+ else
while (!copydone)
{ /* for each
input line ... */
if (prompt)
---(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] plperl - put schema-name in $_TD
Andrew Dunstan [EMAIL PROTECTED] writes: plpython and pltcl don't have relname, while only pltcl has relatts. Is relatts useful? should we provide it everywhere? Hm. It is not particularly useful in plpgsql at the moment, because of the lack of any way to reference columns dynamically. So that's probably why it's not there in plpgsql, and then the other languages copied that decision even though they can do dynamic references. You'd have to work out appropriate datastructure idioms for the other languages, which might not be obvious at first glance. It doesn't seem very high priority to me, because no one's yet asked for it ... I propose to add relname to plpython and pltcl, and relschema to all (mutatis mutandis w.r.t. names). Works for me. regards, tom lane ---(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] plperl - put schema-name in $_TD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 plpython and pltcl don't have relname, while only pltcl has relatts. Is relatts useful? should we provide it everywhere? Might as well - does no harm to add it in. I propose to add relname to plpython and pltcl, and relschema to all (mutatis mutandis w.r.t. names). +1 for table_schema and table_name, especially if in the future we provide things like trigger_schema. - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200605251203 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iD8DBQFEddWlvJuQZxSWSsgRApwyAKCyzFMxO4mnW+1CFVugi4K09rLLdwCcDAgx A5sn8irFjBwTa4kNLEITjec= =YcSr -END PGP SIGNATURE- ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] Cleanup for new escape handling
This patch cleans up the use of E'' strings in 8.2. 8.2 is the first
release where standard_conforming_strings can be 'on', and when 'on',
escape_string_warning is disabled.
In 8.1, the behavior was to use E'' strings for any case where
backslashes exist. For 8.2, per suggestion from Tom, we should use E''
strings only for standard_conforming_strings = 'off'. This would allow
pg_dump output with standard_conforming_strings = 'on' to generate
proper strings that can be loaded into other databases without the
backslash doubling we typically do. I have added the dumping of the
standard_conforming_strings to pg_dump, like we do now for
client_encoding. The only risk of the patch is that someone will use
one of the adt/ruleutils.c functions like pg_get_constraintdef() with
one setting of standard_conforming_strings and then try to load it into
a database with a different standard_conforming_strings setting.
I also added standard backslash handling for plpgsql.
I also checked ecpg and that uses E'' for all strings that have \
because it doesn't know if the target database is going to have
standard_conforming_strings on or off. That seems best, and no one
expects the _output_ of ecpg to be portable.
The macros we use for escape processing really makes these changes easy.
--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: src/backend/utils/adt/quote.c
===
RCS file: /cvsroot/pgsql/src/backend/utils/adt/quote.c,v
retrieving revision 1.18
diff -c -c -r1.18 quote.c
*** src/backend/utils/adt/quote.c 5 Mar 2006 15:58:43 - 1.18
--- src/backend/utils/adt/quote.c 25 May 2006 22:15:36 -
***
*** 14,19
--- 14,20
#include postgres.h
#include utils/builtins.h
+ #include parser/gramparse.h
/*
***
*** 65,83
cp1 = VARDATA(t);
cp2 = VARDATA(result);
! for (; len-- 0; cp1++)
! if (*cp1 == '\\')
! {
! *cp2++ = ESCAPE_STRING_SYNTAX;
! break;
! }
len = VARSIZE(t) - VARHDRSZ;
cp1 = VARDATA(t);
*cp2++ = '\'';
while (len-- 0)
{
! if (SQL_STR_DOUBLE(*cp1))
*cp2++ = *cp1;
*cp2++ = *cp1++;
}
--- 66,85
cp1 = VARDATA(t);
cp2 = VARDATA(result);
! if (!standard_conforming_strings)
! for (; len-- 0; cp1++)
! if (*cp1 == '\\')
! {
! *cp2++ = ESCAPE_STRING_SYNTAX;
! break;
! }
len = VARSIZE(t) - VARHDRSZ;
cp1 = VARDATA(t);
*cp2++ = '\'';
while (len-- 0)
{
! if (SQL_STR_DOUBLE(*cp1, !standard_conforming_strings))
*cp2++ = *cp1;
*cp2++ = *cp1++;
}
Index: src/backend/utils/adt/ruleutils.c
===
RCS file: /cvsroot/pgsql/src/backend/utils/adt/ruleutils.c,v
retrieving revision 1.221
diff -c -c -r1.221 ruleutils.c
*** src/backend/utils/adt/ruleutils.c 30 Apr 2006 18:30:40 - 1.221
--- src/backend/utils/adt/ruleutils.c 25 May 2006 22:15:41 -
***
*** 31,36
--- 31,37
#include nodes/makefuncs.h
#include optimizer/clauses.h
#include optimizer/tlist.h
+ #include parser/gramparse.h
#include parser/keywords.h
#include parser/parse_expr.h
#include parser/parse_func.h
***
*** 533,545
{
if (i 0)
appendStringInfo(buf, , );
! if (strchr(p, '\\') != NULL)
appendStringInfoChar(buf,
ESCAPE_STRING_SYNTAX);
appendStringInfoChar(buf, '\'');
while (*p)
{
! if (SQL_STR_DOUBLE(*p))
appendStringInfoChar(buf, *p);
appendStringInfoChar(buf, *p++);
}
--- 534,546
{
if (i 0)
appendStringInfo(buf, , );
! if (!standard_conforming_strings strchr(p, '\\') !=
NULL)
appendStringInfoChar(buf,
ESCAPE_STRING_SYNTAX);
appendStringInfoChar(buf, '\'');
while (*p)
{
! if (SQL_STR_DOUBLE(*p,
!standard_conforming_strings))
appendStringInfoChar(buf, *p);
appendStringInfoChar(buf, *p++);
[PATCHES] plpgsql documentation
An article at WebProNews quoted from the PG docs as to the merits of stored procedures. I have added a bit more material on their merits, as well as making a few changes to improve the introductions to PL/Perl and PL/Tcl. Index: plperl.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/plperl.sgml,v retrieving revision 2.52 diff -c -u -r2.52 plperl.sgml --- plperl.sgml 10 Mar 2006 19:10:48 - 2.52 +++ plperl.sgml 25 May 2006 22:38:45 - @@ -17,6 +17,12 @@ ulink url=http://www.perl.com;Perl programming language/ulink. /para + para The usual advantage to using PL/Perl is that this allows use, + within stored functions, of the manyfold quotestring +munging/quote operators and functions available for Perl. Parsing + complex strings may be be easier using Perl than it is with the + string functions and control structures provided in PL/pgsql./para + para To install PL/Perl in a particular database, use literalcreatelang plperl replaceabledbname//literal. Index: plpgsql.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/plpgsql.sgml,v retrieving revision 1.88 diff -c -u -r1.88 plpgsql.sgml --- plpgsql.sgml10 Mar 2006 19:10:48 - 1.88 +++ plpgsql.sgml25 May 2006 22:38:46 - @@ -155,21 +155,36 @@ para That means that your client application must send each query to - the database server, wait for it to be processed, receive the - results, do some computation, then send other queries to the - server. All this incurs interprocess communication and may also - incur network overhead if your client is on a different machine - than the database server. + the database server, wait for it to be processed, receive and + process the results, do some computation, then send further + queries to the server. All this incurs interprocess + communication and will also incur network overhead if your client + is on a different machine than the database server. /para para - With applicationPL/pgSQL/application you can group a block of computation and a - series of queries emphasisinside/emphasis the - database server, thus having the power of a procedural - language and the ease of use of SQL, but saving lots of - time because you don't have the whole client/server - communication overhead. This can make for a - considerable performance increase. + With applicationPL/pgSQL/application you can group a block of + computation and a series of queries emphasisinside/emphasis + the database server, thus having the power of a procedural + language and the ease of use of SQL, but with considerable + savings because you don't have the whole client/server + communication overhead. +/para +itemizedlist + + listitempara Elimination of additional round trips between + client and server /para/listitem + + listitempara Intermediate results that the client does not + need do not need to be marshalled or transferred between server + and client /para/listitem + + listitempara There is no need for additional rounds of query + parsing /para/listitem + +/itemizedlist +para This can allow for a considerable performance increase as +compared to an application that does not use stored functions. /para para Index: pltcl.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/pltcl.sgml,v retrieving revision 2.39 diff -c -u -r2.39 pltcl.sgml --- pltcl.sgml 10 Mar 2006 19:10:48 - 2.39 +++ pltcl.sgml 25 May 2006 22:38:46 - @@ -25,22 +25,27 @@ titleOverview/title para -PL/Tcl offers most of the capabilities a function -writer has in the C language, except for some restrictions. +PL/Tcl offers most of the capabilities a function writer has in +the C language, with a few restrictions, and with the addition of +the powerful string processing libraries that are available for +Tcl. /para para -The good restriction is that everything is executed in a safe -Tcl interpreter. In addition to the limited command set of safe Tcl, only -a few commands are available to access the database via SPI and to raise -messages via functionelog()/. There is no way to access internals of the -database server or to gain OS-level access under the permissions of the -productnamePostgreSQL/productname server process, as a C function can do. -Thus, any unprivileged database user may be -permitted to use this language. +One compelling emphasisgood/emphasis restriction is that +everything is executed from within the safety of the context of a +Tcl interpreter. In addition to the limited command set of safe +Tcl, only a few commands are
Re: [PATCHES] plperl - put schema-name in $_TD
On Wed, 24 May 2006 10:12:17 -0400, Andrew wrote:
Patches should be made against the HEAD branch in CVS, not against a
distro source.
Ok; I'll do that. (The patch did apply cleanly to CVS, though, but
anyway).
On Wed, 24 May 2006 15:41:07 -0400, Tom wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
This seems like a good idea, but we should probably make analogous
changes for plpgsql, pltcl and plpython. Having different trigger data
available in some of these doesn't seem like a good idea.
Yeah. I'm also a little disturbed by using nspname which is an
entirely internal name; plus it's a bit unclear *which* schema it's
supposed to be. (One might think it's the schema the trigger function
is in, for instance.) Somebody established a bad precedent by using
relname for the table name.
I wasn't sure what to call it, so I modelled my change after relname ~
SPI_getrelname and arrived at the questionable nspname ~ SPI_getnspname.
Maybe we should use field names like table_name and table_schema.
relname could be kept around for awhile but deprecated as a duplicate
of table_name.
On Thu, 25 May 2006 16:06:12 -, Greg wrote:
+1 for table_schema and table_name, especially if in the future we provide
things like trigger_schema.
I've attached a new patch, against CVS, that adds table_name and
table_schema instead, and updates the doc accordingly.
I haven't looked at the other languages as I do not use them; let me
know if I should take a stab at providing patches for them as well.
Thanks for your comments.
Best regards,
Adam
--
Our hero regains consciousness at the feet of a Adam Sjøgren
sarcastic alien...[EMAIL PROTECTED]
? patch
Index: doc/src/sgml/plperl.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/plperl.sgml,v
retrieving revision 2.52
diff -c -r2.52 plperl.sgml
*** doc/src/sgml/plperl.sgml 10 Mar 2006 19:10:48 - 2.52
--- doc/src/sgml/plperl.sgml 25 May 2006 18:49:34 -
***
*** 728,734
/varlistentry
varlistentry
! termliteral$_TD-gt;{relname}/literal/term
listitem
para
Name of the table on which the trigger fired
--- 728,734
/varlistentry
varlistentry
! termliteral$_TD-gt;{table_name}/literal/term
listitem
para
Name of the table on which the trigger fired
***
*** 737,742
--- 737,760
/varlistentry
varlistentry
+ termliteral$_TD-gt;{relname}/literal/term
+ listitem
+ para
+Name of the table on which the trigger fired. This has been deprecated. Please use $_TD-gt;{table_name} instead.
+ /para
+ /listitem
+ /varlistentry
+
+ varlistentry
+ termliteral$_TD-gt;{table_schema}/literal/term
+ listitem
+ para
+Name of the schema in which the table on which the trigger fired, is
+ /para
+ /listitem
+ /varlistentry
+
+ varlistentry
termliteral$_TD-gt;{argc}/literal/term
listitem
para
Index: src/pl/plperl/plperl.c
===
RCS file: /projects/cvsroot/pgsql/src/pl/plperl/plperl.c,v
retrieving revision 1.108
diff -c -r1.108 plperl.c
*** src/pl/plperl/plperl.c 4 Apr 2006 19:35:37 - 1.108
--- src/pl/plperl/plperl.c 25 May 2006 18:49:37 -
***
*** 525,530
--- 525,536
hv_store(hv, relname, 7,
newSVpv(SPI_getrelname(tdata-tg_relation), 0), 0);
+ hv_store(hv, table_name, 10,
+ newSVpv(SPI_getrelname(tdata-tg_relation), 0), 0);
+
+ hv_store(hv, table_schema, 12,
+ newSVpv(SPI_getnspname(tdata-tg_relation), 0), 0);
+
if (TRIGGER_FIRED_BEFORE(tdata-tg_event))
when = BEFORE;
else if (TRIGGER_FIRED_AFTER(tdata-tg_event))
---(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: [PATCHES] [WIP] The relminxid addition, try 3
Alvaro Herrera [EMAIL PROTECTED] writes: CREATE TABLE foo (a int); for some unknown reason, an inval message involving relation foo seems to be emitted. heap_unfreeze(pg_class) CommandCounterIncrement() heap_unfreeze(pg_attribute) CommandCounterIncrement() ... insert the pg_attribute rows ... Where did all these CommandCounterIncrement calls come from? I don't think it's going to work if you are throwing in CCIs at random places; this problem with the relcache will be the least of your worries. Why do you think you need that anyway? regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [WIP] The relminxid addition, try 3
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: CREATE TABLE foo (a int); for some unknown reason, an inval message involving relation foo seems to be emitted. heap_unfreeze(pg_class) CommandCounterIncrement() heap_unfreeze(pg_attribute) CommandCounterIncrement() ... insert the pg_attribute rows ... Where did all these CommandCounterIncrement calls come from? I don't think it's going to work if you are throwing in CCIs at random places; this problem with the relcache will be the least of your worries. Why do you think you need that anyway? I added them in heap_unfreeze precisely because I want the relation to be frozen exactly once, and this doesn't seem to happen if I don't CCI there -- I was seeing multiple occurences of the NOTICE I put in heap_unfreeze for the same relation for a single CREATE TABLE (multiple unfreezes of pg_class and pg_attribute, for example). Maybe the problem is elsewhere. I'll investigate more. -- 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] [WIP] The relminxid addition, try 3
Alvaro Herrera [EMAIL PROTECTED] writes: Tom Lane wrote: Where did all these CommandCounterIncrement calls come from? I added them in heap_unfreeze precisely because I want the relation to be frozen exactly once, and this doesn't seem to happen if I don't CCI there -- I was seeing multiple occurences of the NOTICE I put in heap_unfreeze for the same relation for a single CREATE TABLE (multiple unfreezes of pg_class and pg_attribute, for example). Well, that needs rethinking. The unfreeze has to be a non-transactional update (if our transaction rolls back, the unfreeze still has to stick, because we may have put dead tuples into the rel). Therefore, a CCI is neither necessary nor useful. I didn't look at your patch in any detail ... didn't you modify it to use the non-transactional update code I put in heapam.c recently? It might be that we need to broadcast an sinval message for the tuple when we update it this way ... although sinval believes updates are transactional, so that's not going to work all that well. Maybe we have to legislate that catcache/syscache entries shouldn't be trusted to have up-to-date values of these fields. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] plperl - put schema-name in $_TD
Adam Sjøgren said: I haven't looked at the other languages as I do not use them; let me know if I should take a stab at providing patches for them as well. I will take it from here. Thanks. andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [WIP] The relminxid addition, try 3
I wrote: Well, that needs rethinking. The unfreeze has to be a non-transactional update (if our transaction rolls back, the unfreeze still has to stick, because we may have put dead tuples into the rel). Actually, this seems even messier than I thought. Consider a transaction that does something transactional to a table's schema, thereby generating a new pg_class row (but not touching any data within the table), and then alters the table contents, requiring an unfreeze. An update to the apparently-current pg_class tuple is not good because that tuple might be rolled back. An update to the last committed version doesn't work either. This seems real close to the recent discussions about how to put sequence data into a single one-row-per-sequence system catalog, specifically about how there were some parts of the sequence catalog data that should be transactional and some that should not be. I'm wondering if we need a second pg_class-derived catalog that carries just the nontransactional columns. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [WIP] The relminxid addition, try 3
Tom Lane wrote: I wrote: Well, that needs rethinking. The unfreeze has to be a non-transactional update (if our transaction rolls back, the unfreeze still has to stick, because we may have put dead tuples into the rel). Actually, this seems even messier than I thought. Consider a transaction that does something transactional to a table's schema, thereby generating a new pg_class row (but not touching any data within the table), and then alters the table contents, requiring an unfreeze. An update to the apparently-current pg_class tuple is not good because that tuple might be rolled back. An update to the last committed version doesn't work either. Well, if a transaction modifies a table in some way, even without changing the data, should generate an unfreeze event, because it will need to lock the table; for example AlterTable locks the affected relation with AccessExclusiveLock. It's important for the non-transactional change to the pg_class tuple be the very first in the transaction, because otherwise the change could be lost; but other than this, I don't think there's any problem. Not that I had actually considered this problem, to be frank; but it seems a nice side effect of how the unfreezing works. This seems real close to the recent discussions about how to put sequence data into a single one-row-per-sequence system catalog, specifically about how there were some parts of the sequence catalog data that should be transactional and some that should not be. I'm wondering if we need a second pg_class-derived catalog that carries just the nontransactional columns. I hope we don't need to do this because ISTM it will be a very big change. -- 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] [WIP] The relminxid addition, try 3
Alvaro Herrera [EMAIL PROTECTED] writes: Well, if a transaction modifies a table in some way, even without changing the data, should generate an unfreeze event, because it will need to lock the table; for example AlterTable locks the affected relation with AccessExclusiveLock. It's important for the non-transactional change to the pg_class tuple be the very first in the transaction, because otherwise the change could be lost; but other than this, I don't think there's any problem. You can't guarantee that. Consider for instance manual updates to pg_class: BEGIN; UPDATE pg_class SET reltriggers = 0 WHERE relname = ... ... alter table contents ... COMMIT or ROLLBACK; I believe there are actually patterns like this in some pg_dump output. Will you hack every UPDATE operation to test whether it's changing pg_class and if so force an unfreeze operation before changing any row? No thanks :-( I'm wondering if we need a second pg_class-derived catalog that carries just the nontransactional columns. I hope we don't need to do this because ISTM it will be a very big change. (Yawn...) We've made far bigger changes than that. The important thing is to get it right. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [WIP] The relminxid addition, try 3
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Well, if a transaction modifies a table in some way, even without changing the data, should generate an unfreeze event, because it will need to lock the table; for example AlterTable locks the affected relation with AccessExclusiveLock. It's important for the non-transactional change to the pg_class tuple be the very first in the transaction, because otherwise the change could be lost; but other than this, I don't think there's any problem. You can't guarantee that. Consider for instance manual updates to pg_class: BEGIN; UPDATE pg_class SET reltriggers = 0 WHERE relname = ... ... alter table contents ... COMMIT or ROLLBACK; I believe there are actually patterns like this in some pg_dump output. Will you hack every UPDATE operation to test whether it's changing pg_class and if so force an unfreeze operation before changing any row? No thanks :-( Oh, true, I hadn't thought of direct updates to pg_class. I'm wondering if we need a second pg_class-derived catalog that carries just the nontransactional columns. I hope we don't need to do this because ISTM it will be a very big change. (Yawn...) We've made far bigger changes than that. The important thing is to get it right. Yeah, I know -- I've been involved in some of them. I hereby volunteer to do it for 8.2 because I'd really like to see this patch in. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
