[PATCHES] -HEAD pg_dumpall broken against older backends
Hi! looks like somebody forgot to test some changes to the pg_dumpall code in Revision 1.70 against <8.1 installations - resulting in the following syntax error: -- -- PostgreSQL database cluster dump -- \connect postgres pg_dumpall: query failed: ERROR: syntax error at or near "null" LINE 1: ... passwd as rolpassword, valuntil as rolvaliduntil null as ro... ^ pg_dumpall: query was: SELECT usename as rolname, usesuper as rolsuper, true as rolinherit, usesuper as rolcreaterole, usecreatedb as rolcreatedb, usecatupd as rolcatupdate, true as rolcanlogin, -1 as rolconnlimit, passwd as rolpassword, valuntil as rolvaliduntil null as rolcomment FROM pg_shadow UNION ALL SELECT groname as rolname, false as rolsuper, true as rolinherit, false as rolcreaterole, false as rolcreatedb, false as rolcatupdate, false as rolcanlogin, -1 as rolconnlimit, null::text as rolpassword, null::abstime as rolvaliduntil null FROM pg_group proposed patch to fix problem is attached. Stefan Index: src/bin/pg_dump/pg_dumpall.c === RCS file: /projects/cvsroot/pgsql/src/bin/pg_dump/pg_dumpall.c,v retrieving revision 1.72 diff -u -r1.72 pg_dumpall.c --- src/bin/pg_dump/pg_dumpall.c5 Mar 2006 15:58:51 - 1.72 +++ src/bin/pg_dump/pg_dumpall.c29 Mar 2006 13:29:01 - @@ -444,7 +444,7 @@ "true as rolcanlogin, " "-1 as rolconnlimit, " "passwd as rolpassword, " - "valuntil as rolvaliduntil " + "valuntil as rolvaliduntil, " "null as rolcomment " "FROM pg_shadow " "UNION ALL " @@ -457,8 +457,8 @@ "false as rolcanlogin, " "-1 as rolconnlimit, " "null::text as rolpassword, " - "null::abstime as rolvaliduntil " - "null " + "null::abstime as rolvaliduntil, " + "null as rolcomment " "FROM pg_group"); res = executeQuery(conn, buf->data); ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] -HEAD pg_dumpall broken against older backends
Stefan Kaltenbrunner wrote: > looks like somebody forgot to test some changes to the pg_dumpall > code in Revision 1.70 against <8.1 installations - resulting in the > following syntax error: Dump output is never expected to be backward compatible. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] -HEAD pg_dumpall broken against older backends
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Stefan Kaltenbrunner wrote: >> looks like somebody forgot to test some changes to the pg_dumpall >> code in Revision 1.70 against <8.1 installations - resulting in the >> following syntax error: > Dump output is never expected to be backward compatible. But pg_dumpall should be able to extract a dump from an older server. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] -HEAD pg_dumpall broken against older backends
Peter Eisentraut wrote: Stefan Kaltenbrunner wrote: looks like somebody forgot to test some changes to the pg_dumpall code in Revision 1.70 against <8.1 installations - resulting in the following syntax error: Dump output is never expected to be backward compatible. We don't expect pg_dumpall to be issuing invalid SQL at any time, though. That's what Stefan has uncovered. The code in question is only called when it's run against an older server. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] -HEAD pg_dumpall broken against older backends
Peter Eisentraut wrote: > Stefan Kaltenbrunner wrote: > >>looks like somebody forgot to test some changes to the pg_dumpall >>code in Revision 1.70 against <8.1 installations - resulting in the >>following syntax error: > > > Dump output is never expected to be backward compatible. yeah - but if you take a look at the code/patch you will see that the problem in this case is that pg_dumpall generates invalid SQL if it is operating against an older backend which is an obvious typo/thinko in this case. It has nothing to do with generating backwards compatible dumps - and using the pg_dumpall from the (newer) target version for upgrades has been recommended for a while (or rather is documented to work in the manual) I think. Stefan ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[PATCHES] restore to defaults values when commenting of variables in postgresql.conf
Hi all,
with this patch, you can now restore default value with SIGHUP when commenting
an variable in postgresql.conf
Emmanuel BERTHOULE
Index: src/backend/utils/misc/guc-file.l
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/misc/guc-file.l,v
retrieving revision 1.37
diff -c -r1.37 guc-file.l
*** src/backend/utils/misc/guc-file.l 7 Mar 2006 01:03:12 - 1.37
--- src/backend/utils/misc/guc-file.l 27 Mar 2006 20:30:55 -
***
*** 18,23
--- 18,24
#include "storage/fd.h"
#include "utils/guc.h"
+ extern void ResetOptionsSIGHUP(void);
/* Avoid exit() on fatal scanner errors (a bit ugly -- see yy_fatal_error) */
#undef fprintf
***
*** 124,129
--- 125,132
* about problems with the config file.
*/
elevel = IsUnderPostmaster ? DEBUG2 : LOG;
+ /* SIGHUP initialize default value at first */
+ ResetOptionsSIGHUP();
}
else
elevel = ERROR;
***
*** 154,160
free_name_value_list(head);
}
!
/*
* Read and parse a single configuration file. This function recurses
* to handle "include" directives.
--- 157,163
free_name_value_list(head);
}
!
/*
* Read and parse a single configuration file. This function recurses
* to handle "include" directives.
Index: src/backend/utils/misc/guc.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/misc/guc.c,v
retrieving revision 1.314
diff -c -r1.314 guc.c
*** src/backend/utils/misc/guc.c 7 Mar 2006 02:54:23 - 1.314
--- src/backend/utils/misc/guc.c 27 Mar 2006 20:30:56 -
***
*** 3021,3026
--- 3021,3127
/*
+ * Reset all options ( with context = SIGHUP ) to their saved default values
+ */
+ void
+ ResetOptionsSIGHUP(void)
+ {
+ int i;
+ bool retour;
+
+ for (i = 0; i < num_guc_variables; i++)
+ {
+ struct config_generic *gconf = guc_variables[i];
+
+ if ( gconf->context == PGC_SIGHUP )
+ {
+ elog(LOG,"option = %s",gconf->name);
+ switch (gconf->vartype)
+ {
+ case PGC_BOOL:
+ {
+ struct config_bool *conf = (struct config_bool *) gconf;
+
+
+ if (conf->assign_hook)
+ if (!(*conf->assign_hook) (conf->reset_val, true,
+ PGC_S_SESSION))
+ elog(ERROR, "failed to reset %s", conf->gen.name);
+ if ( !strcmp(GetConfigOptionResetString((const char*)conf->gen.name),"on") ) *conf->variable=true;
+ else *conf->variable=false;
+ conf->gen.reset_source=PGC_S_SIGHUP;
+ break;
+ }
+ case PGC_INT:
+ {
+ struct config_int *conf = (struct config_int *) gconf;
+
+ if (conf->assign_hook)
+ if (!(*conf->assign_hook) (conf->reset_val, true,
+ PGC_S_SESSION))
+ elog(ERROR, "failed to reset %s", conf->gen.name);
+ *conf->variable = atoi(GetConfigOptionResetString(conf->gen.name));
+ conf->gen.reset_source=PGC_S_SIGHUP;
+ break;
+ }
+ case PGC_REAL:
+ {
+ struct config_real *conf = (struct config_real *) gconf;
+
+ if (conf->assign_hook)
+ if (!(*conf->assign_hook) (conf->reset_val, true,
+ PGC_S_SESSION))
+ elog(ERROR, "failed to reset %s", conf->gen.name);
+ *conf->variable = atol(GetConfigOptionResetString(conf->gen.name));
+ conf->gen.reset_source=PGC_S_SIGHUP;
+ break;
+ }
+ case PGC_STRING:
+ {
+ struct config_string *conf = (struct config_string *) gconf;
+ char *str;
+
+ if (conf->reset_val == NULL)
+ {
+ /* Nothing to reset to, as yet; so do nothing */
+ break;
+ }
+
+ /* We need not strdup here */
+ str = guc_strdup(LOG, conf->reset_val);
+
+ if (conf->assign_hook)
+ {
+ const char *newstr;
+
+ newstr = (*conf->assign_hook) (str, true,
+ PGC_S_SESSION);
+ if (newstr == NULL)
+ elog(ERROR, "failed to reset %s", conf->gen.name);
+ else if (newstr != str)
+ {
+ /*
+ * See notes in set_config_option about casting
+ */
+ str = (char *) newstr;
+ }
+ }
+
+ set_string_field(conf, conf->variable, str);
+ conf->gen.reset_source=PGC_S_SIGHUP;
+ break;
+ }
+
+ }
+ }
+ }
+ }
+
+
+
+
+
+ /*
* push_old_value
* Push previous state during first assignment to a GUC variable
* within a particular transaction.
***
*** 3124,3130
GucStack *stack = gconf->stack;
bool useTentative;
bool changed;
!
/*
* Skip if nothing's happened to this var in this transaction
*/
--- 3225,3231
GucStack *stack = gconf->stack;
bool useTentative;
bool changed;
!
/*
* Skip if nothing's happened to this var in this transaction
*/
***
*** 3711,3717
* trans
Re: [PATCHES] Improve psql's handling of multi-line queries
On 21/03/06, Bruce Momjian wrote: > Steve, we have already applied a patch by Sergey E. Koposov to do this. > Would you review CVS HEAD and see that everything works as you would > like. Thanks. Yeah it's good; stores multiline queries in .psql_history which is an improvement over my patch. Cheers, Steve ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] restore to defaults values when commenting of variables in postgresql.conf
BERTHOULE Emmanuel <[EMAIL PROTECTED]> writes: > with this patch, you can now restore default value with SIGHUP when > commenting an variable in postgresql.conf This seems pretty poorly thought out, in particular making PGC_S_SIGHUP >= PGC_S_OVERRIDE seems to me likely to break the interaction with other sources. Doesn't that cause postgresql.conf to override per-user and per-database settings? Why do you need the extra value at all --- isn't the correct logic just to reset entries with source PGC_S_FILE? Another problem is that if there's something wrong with the config file, this will cause all values previously read from the config file to revert to defaults, which seems less than robust to me. You really shouldn't apply the reset until after the file has been parsed. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[PATCHES] Show tablespace for databases with psql's \l+
Following discussion
(http://archives.postgresql.org/pgsql-hackers/2006-03/msg01208.php) here's a
patch to add tablespace to the output of psql's \l+. New output (with psql
-E) looks like this:
pyarra=# \l+
* QUERY **
SELECT d.datname as "Name",
r.rolname as "Owner",
pg_catalog.pg_encoding_to_char(d.encoding) as "Encoding",
pg_catalog.shobj_description(d.oid, 'pg_database') as "Description",
t.spcname as "Tablespace"
FROM pg_catalog.pg_database d
JOIN pg_catalog.pg_roles r ON d.datdba = r.oid
JOIN pg_catalog.pg_tablespace t on d.dattablespace = t.oid
ORDER BY 1;
**
List of databases
Name| Owner | Encoding |Description| Tablespace
---++--+---+
postgres | pyarra | LATIN1 | | pg_default
pyarra| pyarra | LATIN1 | | pg_default
spctest | pyarra | LATIN1 | | spctable
template0 | pyarra | LATIN1 | | pg_default
template1 | pyarra | LATIN1 | Default template database | pg_default
(5 rows)
Please let me know if this patch needs any changes for acceptance. I would
prefer the tablespace row to the left of Description, but opted for minimal
change to get patch accepted. Will re-order them if others are in favour.
Regards, Philip.
-
Utiba Pty Ltd
This message has been scanned for viruses and
dangerous content by Utiba mail server and is
believed to be clean.
Index: src/bin/psql/describe.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/psql/describe.c,v
retrieving revision 1.133
diff -c -r1.133 describe.c
*** src/bin/psql/describe.c 5 Mar 2006 15:58:51 - 1.133
--- src/bin/psql/describe.c 30 Mar 2006 00:23:57 -
***
*** 362,375
",\n pg_catalog.pg_encoding_to_char(d.encoding) as \"%s\"",
_("Encoding"));
if (verbose)
appendPQExpBuffer(&buf,
",\n pg_catalog.shobj_description(d.oid, 'pg_database') as \"%s\"",
_("Description"));
appendPQExpBuffer(&buf,
"\nFROM pg_catalog.pg_database d"
! "\n JOIN pg_catalog.pg_roles r ON d.datdba = r.oid\n"
! "ORDER BY 1;");
!
res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
--- 362,382
",\n pg_catalog.pg_encoding_to_char(d.encoding) as \"%s\"",
_("Encoding"));
if (verbose)
+ {
appendPQExpBuffer(&buf,
",\n pg_catalog.shobj_description(d.oid, 'pg_database') as \"%s\"",
_("Description"));
+ appendPQExpBuffer(&buf,
+ ",\n t.spcname as \"%s\"",
+ _("Tablespace"));
+ }
appendPQExpBuffer(&buf,
"\nFROM pg_catalog.pg_database d"
! "\n JOIN pg_catalog.pg_roles r ON d.datdba = r.oid\n");
! if (verbose)
! appendPQExpBuffer(&buf,
! " JOIN pg_catalog.pg_tablespace t on d.dattablespace = t.oid\n");
! appendPQExpBuffer(&buf,"ORDER BY 1;");
res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
---(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] -HEAD pg_dumpall broken against older backends
Stefan Kaltenbrunner wrote: Hi! looks like somebody forgot to test some changes to the pg_dumpall code in Revision 1.70 against <8.1 installations - resulting in the following syntax error: patch applied, thanks andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Show tablespace for databases with psql's \l+
Philip Yarra <[EMAIL PROTECTED]> writes: > Please let me know if this patch needs any changes for acceptance. I would > prefer the tablespace row to the left of Description, Me too --- that looks pretty weird as-is. regards, tom lane ---(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] Show tablespace for databases with psql's \l+
On Thu, 30 Mar 2006 01:13 pm, Tom Lane wrote:
> Philip Yarra <[EMAIL PROTECTED]> writes:
> > Please let me know if this patch needs any changes for acceptance. I
> > would prefer the tablespace row to the left of Description,
>
> Me too --- that looks pretty weird as-is.
OK, revised patch attached. Less-weird output now looks like this:
List of databases
Name| Owner | Encoding | Tablespace |Description
---++--++---
postgres | pyarra | LATIN1 | pg_default |
pyarra| pyarra | LATIN1 | pg_default |
spctest | pyarra | LATIN1 | spctable |
template0 | pyarra | LATIN1 | pg_default |
template1 | pyarra | LATIN1 | pg_default | Default template database
(5 rows)
Much nicer, I think.
Regards, Philip.
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
-
Utiba Pty Ltd
This message has been scanned for viruses and
dangerous content by Utiba mail server and is
believed to be clean.
Index: src/bin/psql/describe.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/psql/describe.c,v
retrieving revision 1.133
diff -c -r1.133 describe.c
*** src/bin/psql/describe.c 5 Mar 2006 15:58:51 - 1.133
--- src/bin/psql/describe.c 30 Mar 2006 03:28:34 -
***
*** 362,375
",\n pg_catalog.pg_encoding_to_char(d.encoding) as \"%s\"",
_("Encoding"));
if (verbose)
appendPQExpBuffer(&buf,
",\n pg_catalog.shobj_description(d.oid, 'pg_database') as \"%s\"",
_("Description"));
appendPQExpBuffer(&buf,
"\nFROM pg_catalog.pg_database d"
! "\n JOIN pg_catalog.pg_roles r ON d.datdba = r.oid\n"
! "ORDER BY 1;");
!
res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
--- 362,382
",\n pg_catalog.pg_encoding_to_char(d.encoding) as \"%s\"",
_("Encoding"));
if (verbose)
+ {
+ appendPQExpBuffer(&buf,
+ ",\n t.spcname as \"%s\"",
+ _("Tablespace"));
appendPQExpBuffer(&buf,
",\n pg_catalog.shobj_description(d.oid, 'pg_database') as \"%s\"",
_("Description"));
+ }
appendPQExpBuffer(&buf,
"\nFROM pg_catalog.pg_database d"
! "\n JOIN pg_catalog.pg_roles r ON d.datdba = r.oid\n");
! if (verbose)
! appendPQExpBuffer(&buf,
! " JOIN pg_catalog.pg_tablespace t on d.dattablespace = t.oid\n");
! appendPQExpBuffer(&buf,"ORDER BY 1;");
res = PSQLexec(buf.data, false);
termPQExpBuffer(&buf);
if (!res)
---(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
