Re: [PATCHES] [COMMITTERS] pgsql-server: Have \dn+ show permissions and description
Christopher Kings-Lynne wrote:
> > With \dp having a schema column, how would we display permissions there?
> >
> >Access privileges for database "test"
> > Schema | Name | Type | Access privileges
> > +--+---+---
> > public | test | table |
> > (1 row)
> >
> > I don't think it makes sense to add schema to \dp if it would not
> > normally appear in the \dp display.
> >
> > I figured schema permissions were different enough from table that is
> > belonged under schema, no? Also, to me view/table/sequence are data
> > storage objects, while schemas seem different.
>
> Don't forget \db for tablespaces as well - that should work the same as
> \dn wrt permissions display.
OK, done and applied:
test=> \db
List of tablespaces
Name| Owner | Location
+--+--
pg_default | postgres |
pg_global | postgres |
temp | postgres | /bjm/tmp
(3 rows)
test=> \db+
List of tablespaces
Name| Owner | Location | Access privileges
+--+--+---
pg_default | postgres | |
pg_global | postgres | |
Tablespaces, being global, don't have comments so I didn't do that part.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: doc/src/sgml/ref/psql-ref.sgml
===
RCS file: /cvsroot/pgsql-server/doc/src/sgml/ref/psql-ref.sgml,v
retrieving revision 1.118
diff -c -c -r1.118 psql-ref.sgml
*** doc/src/sgml/ref/psql-ref.sgml 13 Jul 2004 16:48:15 - 1.118
--- doc/src/sgml/ref/psql-ref.sgml 15 Jul 2004 03:53:16 -
***
*** 832,837
--- 832,839
Lists all available tablespaces. If pattern
is specified, only tablespaces whose names match the pattern are shown.
+ If + is appended to the command name, each object
+ is listed with its associated permissions.
Index: src/bin/psql/command.c
===
RCS file: /cvsroot/pgsql-server/src/bin/psql/command.c,v
retrieving revision 1.121
diff -c -c -r1.121 command.c
*** src/bin/psql/command.c 13 Jul 2004 16:48:16 - 1.121
--- src/bin/psql/command.c 15 Jul 2004 03:53:26 -
***
*** 302,308
success = describeAggregates(pattern, show_verbose);
break;
case 'b':
! success = describeTablespaces(pattern);
break;
case 'c':
success = listConversions(pattern);
--- 302,308
success = describeAggregates(pattern, show_verbose);
break;
case 'b':
! success = describeTablespaces(pattern, show_verbose);
break;
case 'c':
success = listConversions(pattern);
Index: src/bin/psql/describe.c
===
RCS file: /cvsroot/pgsql-server/src/bin/psql/describe.c,v
retrieving revision 1.102
diff -c -c -r1.102 describe.c
*** src/bin/psql/describe.c 13 Jul 2004 16:48:16 - 1.102
--- src/bin/psql/describe.c 15 Jul 2004 03:53:26 -
***
*** 106,112
* Takes an optional regexp to select particular tablespaces
*/
bool
! describeTablespaces(const char *pattern)
{
PQExpBufferData buf;
PGresult *res;
--- 106,112
* Takes an optional regexp to select particular tablespaces
*/
bool
! describeTablespaces(const char *pattern, bool verbose)
{
PQExpBufferData buf;
PGresult *res;
***
*** 117,126
printfPQExpBuffer(&buf,
"SELECT spcname AS \"%s\",\n"
" pg_catalog.pg_get_userbyid(spcowner) AS
\"%s\",\n"
! " spclocation AS \"%s\"\n"
! "FROM pg_catalog.pg_tablespace\n",
_("Name"), _("Owner"), _("Location"));
processNamePattern(&buf, pattern, false, false,
NULL, "spcname", NULL,
NULL);
--- 117,133
printfPQExpBuffer(&buf,
Re: [PATCHES] Better fixes for pg_dump bugs
Hehe - actually, don't commit this either, I keep finding more and more bugs in pg_dump... Chris Christopher Kings-Lynne wrote: OK, This dump is a proper fix for the three bugs mentioned in the first email. It now just outputs an ALTER USER command for the cluster owner and has nothing to do with the '-S' switch. It also fixes the other two issues. Chris ---(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 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] add missing options to pg_dumpall
Hmmm, and I need to resurrect the -X use-set-session-authorization flag
for pg_dumpall as well...patch coming soon...
Chris
Stefan Kaltenbrunner wrote:
Bruce Momjian wrote:
Patch applied. Thanks.
thanks - that's wonderful news :-)
However the patch as it went in has a minor cosmetic issues with the
display of the --help output.
Maybe something like the attached patch should be applied to restore the
alphabetical option ordering and make the output more like the pg_dump
output.
Stefan
Index: src/bin/pg_dump/pg_dumpall.c
===
RCS file: /projects/cvsroot/pgsql-server/src/bin/pg_dump/pg_dumpall.c,v
retrieving revision 1.44
diff -u -r1.44 pg_dumpall.c
--- src/bin/pg_dump/pg_dumpall.c 12 Jul 2004 14:35:45 - 1.44
+++ src/bin/pg_dump/pg_dumpall.c 14 Jul 2004 17:56:04 -
@@ -310,26 +310,26 @@
printf(_("Usage:\n"));
printf(_(" %s [OPTION]...\n"), progname);
- printf(_("\nOptions:\n"));
+ printf(_("\nGeneral options:\n"));
+ printf(_(" -i, --ignore-version proceed even when server version mismatches\n"
+ " pg_dumpall version\n"));
+ printf(_(" --help show this help, then exit\n"));
+ printf(_(" --versionoutput version information, then exit\n"));
+ printf(_("\nOptions controlling the output content:\n"));
printf(_(" -a, --data-only dump only the data, not the schema\n"));
printf(_(" -c, --clean clean (drop) databases prior to create\n"));
printf(_(" -d, --insertsdump data as INSERT, rather than COPY, commands\n"));
printf(_(" -D, --column-inserts dump data as INSERT commands with column names\n"));
printf(_(" -g, --globals-only dump only global objects, no databases\n"));
- printf(_(" -i, --ignore-version proceed even when server version mismatches\n"
- " pg_dumpall version\n"));
- printf(_(" -s, --schema-onlydump only the schema, no data\n"));
- printf(_(" -S, --superuser=NAME specify the superuser user name to use in the dump\n"));
printf(_(" -o, --oids include OIDs in dump\n"));
printf(_(" -O, --no-owner do not output commands to set object ownership\n"));
- printf(_(" -v, --verboseverbose mode\n"));
+ printf(_(" -s, --schema-onlydump only the schema, no data\n"));
+ printf(_(" -S, --superuser=NAME specify the superuser user name to use in the dump\n"));
printf(_(" -x, --no-privileges do not dump privileges (grant/revoke)\n"));
printf(_(" -X disable-dollar-quoting, --disable-dollar-quoting\n"
" disable dollar quoting, use SQL standard quoting\n"));
printf(_(" -X disable-triggers, --disable-triggers\n"
- " disable triggers during data-only restore\n"));
- printf(_(" --help show this help, then exit\n"));
- printf(_(" --versionoutput version information, then exit\n"));
+ " disable triggers during data-only restore\n"));
printf(_("\nConnection options:\n"));
printf(_(" -h, --host=HOSTNAME database server host or socket directory\n"));
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
[PATCHES] Patch for pg_dump: Multiple -t options and new -T option
Attached is a patch against pg_dump version 7.4.3 that permits
multiple "-t" switches so that you can select more than one table (but
less than all) to dump.
It also adds a "-T" switch (long name "--exclude-table") that says
*not* to dump a specific table. So:
pg_dump -t table1 -t table2 db
will dump table1 and table2 only, whereas:
pg_dump -T table1 -T table2 db
will dump all the tables *except* table1 and table2.
Tested briefly on my system; doesn't seem to break anything.
Regards,
David.
--
David F. Skoll <[EMAIL PROTECTED]>Roaring Penguin Software Inc.
+1 (613) 231-6599 ext. 100 http://www.roaringpenguin.com/
For CanIt technical support, please mail: [EMAIL PROTECTED]diff -u -r -N postgresql-7.4.3.ORIG/src/bin/pg_dump/Makefile
postgresql-7.4.3/src/bin/pg_dump/Makefile
--- postgresql-7.4.3.ORIG/src/bin/pg_dump/Makefile 2003-08-08 00:52:21.0
-0400
+++ postgresql-7.4.3/src/bin/pg_dump/Makefile 2004-07-06 21:58:02.0 -0400
@@ -15,7 +15,7 @@
OBJS= pg_backup_archiver.o pg_backup_db.o pg_backup_custom.o \
pg_backup_files.o pg_backup_null.o pg_backup_tar.o \
- dumputils.o
+ dumputils.o should_dump.o
EXTRA_OBJS = $(top_builddir)/src/backend/parser/keywords.o
diff -u -r -N postgresql-7.4.3.ORIG/src/bin/pg_dump/pg_dump.c
postgresql-7.4.3/src/bin/pg_dump/pg_dump.c
--- postgresql-7.4.3.ORIG/src/bin/pg_dump/pg_dump.c 2004-05-26 14:27:23.0
-0400
+++ postgresql-7.4.3/src/bin/pg_dump/pg_dump.c 2004-07-06 21:58:02.0 -0400
@@ -139,7 +139,7 @@
/* obsolete as of 7.3: */
static Oid g_last_builtin_oid; /* value of the last builtin oid */
-static char *selectTableName = NULL; /* name of a single table to dump */
+static int partial_dump = 0; /* True if -t or -T is used */
static char *selectSchemaName = NULL; /* name of a single schema to dump */
char g_opaque_type[10]; /* name for the opaque type */
@@ -201,6 +201,7 @@
{"schema-only", no_argument, NULL, 's'},
{"superuser", required_argument, NULL, 'S'},
{"table", required_argument, NULL, 't'},
+ {"exclude-table", required_argument, NULL, 'T'},
{"password", no_argument, NULL, 'W'},
{"username", required_argument, NULL, 'U'},
{"verbose", no_argument, NULL, 'v'},
@@ -258,7 +259,7 @@
}
}
- while ((c = getopt_long(argc, argv, "abcCdDf:F:h:in:oOp:RsS:t:uU:vWxX:Z:",
+ while ((c = getopt_long(argc, argv, "abcCdDf:F:h:in:oOp:RsS:t:T:uU:vWxX:Z:",
long_options, &optindex)) !=
-1)
{
switch (c)
@@ -335,8 +336,14 @@
outputSuperuser = strdup(optarg);
break;
- case 't': /* Dump data for this table
only */
- selectTableName = strdup(optarg);
+ case 't': /* Dump data for this table */
+ add_table_to_include_list(optarg);
+ partial_dump = 1;
+ break;
+
+ case 'T': /* Do NOT dump data for this
table */
+ add_table_to_exclude_list(optarg);
+ partial_dump = 1;
break;
case 'u':
@@ -421,9 +428,9 @@
exit(1);
}
- if (outputBlobs && selectTableName != NULL)
+ if (outputBlobs && partial_dump)
{
- write_msg(NULL, "large-object output not supported for a single
table\n");
+ write_msg(NULL, "large-object output not supported for a partial
dump\n");
write_msg(NULL, "use a full dump instead\n");
exit(1);
}
@@ -639,7 +646,8 @@
printf(_(" -s, --schema-onlydump only the schema, no data\n"));
printf(_(" -S, --superuser=NAME specify the superuser user name to use
in\n"
" plain text format\n"));
- printf(_(" -t, --table=TABLEdump the named table only\n"));
+ printf(_(" -t, --table=TABLEdump the named table only (multiple -t
allowed)\n"));
+ printf(_(" -T, --exclude-table=TABLE do not dump the named table (multiple -T
allowed)\n"));
printf(_(" -x, --no-privileges do not dump privileges
(grant/revoke)\n"));
printf(_(" -X disable-triggers, --disable-triggers\n"
" disable triggers during data-only
restore\n"));
@@ -672,11 +680,11 @@
selectDumpableNamespace(NamespaceInfo *nsinfo)
{
/*
-* If a specific table is being dumped, do not dump any complete
+* If a specific table
Re: [PATCHES] [subxacts] Savepoint syntax
On Wed, 2004-07-14 at 20:03, Alvaro Herrera wrote: > So I have dropped the idea of the propietary syntax. This patch > implements proper savepoint syntax. Includes regression tests but no > documentation is provided yet. Excellent. Thank you very much for your efforts. Many thanks, Simon Riggs ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] PITR Archive Recovery plus WIP PITR
On Wed, 2004-07-14 at 16:00, Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> I think it's really important to get this right the first time, both for > >> reliability's sake and because we are expecting people to write their > >> own archiving scripts. If we change the xlog segment naming convention > >> later on, then we will break all those scripts. > > > We don't have anything hardcoded based on those file names, at last in > > PostgreSQL. > Well, I think we do. There's two places where the filename format and length matters and there are numerous calls to calculate filenames from log,seg pairs. ...and much of the current patch would need reworking thoroughly to make sure all differences were changed. Which is why I was striving for a solution that retained the filename make-up, by adding a very large number to the log value (we just aren't gonna run out...I did the math in another post). > That's because we've punted the whole problem of archive-segment > management off to the users. > > If we did implement this functionality ourselves then I'd be less > worried, since we'd know that future changes would affect only our > own code. But as things stand, we will have very unhappy PITR users > if we change the naming convention later. > Yes, if we are going to change the xlog filename format, we must do it now. The change must be in effect whether or not you use archive_mode. ...Is there agreement with my previous posts on thismarked "Point in Time Recovery" over the last few days? Is that what we should implement? Overall, the timeline concept is only worth implementing if: - we archive xlogs - we recover them - we recover them to a point in time/txnid We agreed that the last part wasn't the priority for beta freeze. I'm willing to spend more time on the timeline idea as long as I've got some idea that we will be committing what has been developed so far. It takes effort to keep the patch viable against changes because new commits update the catalog version, which invalidates all my test databases, as well as any changes I have to track down. ...and I've been doing that for a month now - getting much better though, thanks. If we can review what we have now, I would be most pleased. Until we commit at least some of it, I'm the only developer and I would like to open this up to allow others to contribute more easily. Best Regards, Simon Riggs ---(end of broadcast)--- TIP 8: explain analyze is your friend
[PATCHES] plperl win32
Here is a patch required to build plperl with win32. The issues were: * perl_useshrplib gets set to "yes" and not to "true". I assume it's set to "true" on unix, so I left both. * Need to translate backslashes into slashes * The linker config coming out of perl was for MSVC and not for mingw Some of this is pretty ugly stuff - the reassigning into a second variable etc. If somebody with a little better "makefile knowledge" would clean that up (if it can be, but it should be possible), please do! //Magnus <> plperl_win32.patch Description: plperl_win32.patch ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] serverlog rotation/functions
Bruce Momjian wrote: Also there are no documenttion changes. Here are the missing docs, freshly created against cvs. Regards, Andreas Index: func.sgml === RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/func.sgml,v retrieving revision 1.214 diff -u -r1.214 func.sgml --- func.sgml 12 Jul 2004 20:23:47 - 1.214 +++ func.sgml 14 Jul 2004 19:08:16 - @@ -7455,6 +7455,80 @@ + pg_logfile_get + + + pg_logfile_length + + + pg_logfile_name + + + pg_logfile_rotate + + +The functions shown in + deal with the server log file if configured with log_destination + file. + + + +Server Logfile Functions + + + Name Return Type Description + + + + + pg_logfile_get(size_int4, + offset_int4,filename_text) + cstring + get a part of the current server log file + + + pg_logfile_length(filename_text) + int4 + return the current length of the server log file + + + pg_logfile_rotate() + cstring + rotates the server log file and returns the new log file + name + + + pg_logfile_name() + cstring + returns the current server log file name + + + pg_logfile_rotate() + cstring + rotates the server log file and returns the previous log file + name + + + + + +The pg_logfile_get function will return the + contents of the current server log file, limited by the size + parameter. If size is NULL, a server internal limit (currently + 5) is applied. The position parameter specifies the + starting position of the server log chunk to be returned. A + positive number or 0 will be counted from the start of the file, + a negative number from the end; if NULL, -size is assumed + (i.e. the tail of the log file). + + +Both pg_logfile_get and + pg_logfile_length have a filename + parameter which may specify the logfile to examine or the + current logfile if NULL. + + + pg_cancel_backend Index: runtime.sgml === RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v retrieving revision 1.269 diff -u -r1.269 runtime.sgml --- runtime.sgml 11 Jul 2004 00:18:40 - 1.269 +++ runtime.sgml 14 Jul 2004 19:08:26 - @@ -1769,9 +1769,9 @@ PostgreSQL supports several methods - for loggning, including stderr and - syslog. On Windows, - eventlog is also supported. Set this + for logging, including stderr, + file> and syslog. + On Windows, eventlog is also supported. Set this option to a list of desired log destinations separated by a comma. The default is to log to stderr only. This option must be set at server start. @@ -1779,6 +1779,17 @@ + + log_filename (string) + + + This option sets the target filename for the log destination + file option. It may be specified as absolute + path or relative to the cluster directory. + + + + syslog_facility (string) ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] add missing options to pg_dumpall
Bruce Momjian wrote:
Patch applied. Thanks.
thanks - that's wonderful news :-)
However the patch as it went in has a minor cosmetic issues with the
display of the --help output.
Maybe something like the attached patch should be applied to restore
the alphabetical option ordering and make the output more like the
pg_dump output.
Stefan
Index: src/bin/pg_dump/pg_dumpall.c
===
RCS file: /projects/cvsroot/pgsql-server/src/bin/pg_dump/pg_dumpall.c,v
retrieving revision 1.44
diff -u -r1.44 pg_dumpall.c
--- src/bin/pg_dump/pg_dumpall.c12 Jul 2004 14:35:45 - 1.44
+++ src/bin/pg_dump/pg_dumpall.c14 Jul 2004 17:56:04 -
@@ -310,26 +310,26 @@
printf(_("Usage:\n"));
printf(_(" %s [OPTION]...\n"), progname);
- printf(_("\nOptions:\n"));
+ printf(_("\nGeneral options:\n"));
+ printf(_(" -i, --ignore-version proceed even when server version
mismatches\n"
+" pg_dumpall version\n"));
+ printf(_(" --help show this help, then exit\n"));
+ printf(_(" --versionoutput version information, then
exit\n"));
+ printf(_("\nOptions controlling the output content:\n"));
printf(_(" -a, --data-only dump only the data, not the schema\n"));
printf(_(" -c, --clean clean (drop) databases prior to
create\n"));
printf(_(" -d, --insertsdump data as INSERT, rather than COPY,
commands\n"));
printf(_(" -D, --column-inserts dump data as INSERT commands with column
names\n"));
printf(_(" -g, --globals-only dump only global objects, no
databases\n"));
- printf(_(" -i, --ignore-version proceed even when server version
mismatches\n"
-" pg_dumpall version\n"));
- printf(_(" -s, --schema-onlydump only the schema, no data\n"));
- printf(_(" -S, --superuser=NAME specify the superuser user name to use in
the dump\n"));
printf(_(" -o, --oids include OIDs in dump\n"));
printf(_(" -O, --no-owner do not output commands to set object
ownership\n"));
- printf(_(" -v, --verboseverbose mode\n"));
+ printf(_(" -s, --schema-onlydump only the schema, no data\n"));
+ printf(_(" -S, --superuser=NAME specify the superuser user name to use in
the dump\n"));
printf(_(" -x, --no-privileges do not dump privileges
(grant/revoke)\n"));
printf(_(" -X disable-dollar-quoting, --disable-dollar-quoting\n"
" disable dollar quoting, use SQL
standard quoting\n"));
printf(_(" -X disable-triggers, --disable-triggers\n"
-" disable triggers during data-only
restore\n"));
- printf(_(" --help show this help, then exit\n"));
- printf(_(" --versionoutput version information, then
exit\n"));
+" disable triggers during data-only
restore\n"));
printf(_("\nConnection options:\n"));
printf(_(" -h, --host=HOSTNAME database server host or socket
directory\n"));
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] build infrastructure for extensions v3
Fabien COELHO wrote: > Dear patchers, > > Please find attached version number 3 for a patch to enable > extensions such as contribs or external add-ons to be installed > simply with an already installed postgresql. OK, I think we're getting somewhere. I am still opposed to adding more targets of the form "light-install", "client-only install", etc. Please discuss this on -hackers. It can be done as a separate patch later on if need be. While I now understand what you are doing in contrib, I ask who is going to want to maintain two parallel sets of makefiles, one for PGXS and one for in-tree builds? One who is going to want to use the PGXS ones anyway? I realize they're good examples, but examples should be put into the documentation, so people can find them. Paste your documentation (pgxs.sgml) somewhere into xfunc.sgml, where it discusses writing user-defined functions. This material isn't long enough to warrant a chapter of its own. + ifdef PGXS + LDFLAGS += -L$(pkglibdir) + endif needs to disappear. There is nothing to link with in there. (If there is, that's a bug.) libpgport should be installed in the normal libdir. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] serverlog rotation/functions
Tom Lane wrote: That struck me as not only useless but the deliberately hard way to do it. To use that in the real world, you'd have to set up a cron job to trigger the rotation, Still on my radar... which means a lot of infrastructure and privilege; whereas ISTM the point of this feature was to avoid both. ... I was thinking about putting this into the pg_autovacuum process. The log capture process should just do its own rotation on a pre-configured time-interval basis, and/or maximum-file-size basis. Yup. I see zero value added in having it respond to external signals. I see >0 value. I like to truncate my logfile before doing some complicated stuff, to have a handy file for debugging purposes. Regards, Andreas ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] PITR Archive Recovery plus WIP PITR
Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> I think it's really important to get this right the first time, both for >> reliability's sake and because we are expecting people to write their >> own archiving scripts. If we change the xlog segment naming convention >> later on, then we will break all those scripts. > We don't have anything hardcoded based on those file names, at last in > PostgreSQL. That's because we've punted the whole problem of archive-segment management off to the users. If we did implement this functionality ourselves then I'd be less worried, since we'd know that future changes would affect only our own code. But as things stand, we will have very unhappy PITR users if we change the naming convention later. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] PITR Archive Recovery plus WIP PITR
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> I think that judgment is exactly backward. *Not* having timelines is > >> what will cause serious and possibly fatal mistakes during restore: > >> people will hand the wrong xlog files to restore and the software will > >> be unable to recognize the inconsistency. > > > I assume they could just restore from backup and try again. > > Sure, if they don't mind losing whatever transactions they processed > before realizing how broken their database was. That's not going to be > an acceptable answer for the sort of installations that need PITR in the > first place. > > I think it's really important to get this right the first time, both for > reliability's sake and because we are expecting people to write their > own archiving scripts. If we change the xlog segment naming convention > later on, then we will break all those scripts. We don't have anything hardcoded based on those file names, at last in PostgreSQL. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] serverlog rotation/functions
We could make the same adjustments when opening a new log file rather than pipe, no? --- Tom Lane wrote: > I wrote: > > close(2); > > d = dup(p[0]); > > Assert(d == 2); > > Having re-read the pipe(2) man page, of course that should be > d = dup(p[1]); > since it's the writing end of the pipe you want to plug stderr into. > > BTW, if it wasn't clear: I'd do the same pushup for stdout too, > just in case. I'm not sure there is any output to stdout left in the > backend, but I wouldn't swear there is not, either. > > regards, tom lane > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[PATCHES] Better fixes for pg_dump bugs
OK, This dump is a proper fix for the three bugs mentioned in the first email. It now just outputs an ALTER USER command for the cluster owner and has nothing to do with the '-S' switch. It also fixes the other two issues. Chris pg_dump_fixes2.txt.gz Description: application/gunzip ---(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] serverlog rotation/functions
I wrote: > close(2); > d = dup(p[0]); > Assert(d == 2); Having re-read the pipe(2) man page, of course that should be d = dup(p[1]); since it's the writing end of the pipe you want to plug stderr into. BTW, if it wasn't clear: I'd do the same pushup for stdout too, just in case. I'm not sure there is any output to stdout left in the backend, but I wouldn't swear there is not, either. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] serverlog rotation/functions
"Magnus Hagander" <[EMAIL PROTECTED]> writes: >> You'd need the postmaster to create the pipe and then >> re-point its own stdout and stderr at it, but that's doable >> on Unixen at least (I'm less sure about Windows). > Given the issues we've had with stdout/stderr on mingw, I'm not > convinced it will work there. But I'm not convinced it won't work either > :-) What would be the portable way to do it on *nix - I could always run > some tests on w32. Just "stderr = mynewpipe;" is a bit too simplistic, > right? Given that you have a pipe, I'd do something like fclose(stderr); stderr = fdopen(dup(p[0]), "a"); or possibly just close(2); d = dup(p[0]); Assert(d == 2); which would substitute the pipe into descriptor 2 without touching the state of the user-level stderr file. This has the advantage that you don't have to assume you can assign to the stderr macro. (If you do do it the first way, you'd probably need an additional call to force the buffering mode back to linebuffered or unbuffered.) I don't have a problem with #ifdef'ing this part if something slightly different is needed on Windows, though. >> The fundamentally unfixable problem with his method is that >> it can only capture elog output, not stderr output from >> libraries that we don't control (the dynamic linker being the >> biggest case, but there are others). > How common are these issues really? Exceedingly. I've lost count of the number of times we've needed to look at the stderr output of someone's dynamic linker because we had no other way to debug a problem with loading a shared library. I'm really not going to accept a "logging" solution that can't handle it. (And yes, this is one of the big complaints against our syslog implementation.) regards, tom lane ---(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] [HACKERS] Is "trust" really a good default?
On Wed, 2004-07-14 at 05:08, Tom Lane wrote: > Oliver Elphick <[EMAIL PROTECTED]> writes: > > ... > > The point of this explanation is that as Debian maintainer I would have > > to disable any procedures that attempt to edit these conffiles, or at > > least ensure that their operation is under package control and produce > > only the effects that I desire. > > Uh, is this relevant at all? There has been no suggestion that initdb > should try any harder or less hard than it does now to write > $PGDATA/pg_hba.conf. All that's been discussed is what it should write > there. If you are going to hack on it to enforce your opinion of what > it should do, then you'll be making the same hack either way. It's just that if people are going to do things to initdb to accommodate the distributions, they need to understand the constraints. -- Oliver Elphick [EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver GPG: 1024D/A54310EA 92C8 39E7 280E 3631 3F0E 1EC0 5664 7A2F A543 10EA "God is faithful, by whom ye were called unto the fellowship of his Son Jesus Christ our Lord." I Corinthians 1:9 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] serverlog rotation/functions
> > Probably the big thing this program was trying to solve was for the > > server to know the output file name, even with log file > rotation, and > > I don't see a pipe and 'rotatelogs' process really addressing this. > > It could be done. Given the infrastructure we have now, it's > possible to imagine the log capture process being a child of > the postmaster that can respond to GUC SIGHUPs (or forget > that and just freeze the file name pattern at PGC_POSTMASTER > time, which isn't really that big a drawback). > You'd need the postmaster to create the pipe and then > re-point its own stdout and stderr at it, but that's doable > on Unixen at least (I'm less sure about Windows). Given the issues we've had with stdout/stderr on mingw, I'm not convinced it will work there. But I'm not convinced it won't work either :-) What would be the portable way to do it on *nix - I could always run some tests on w32. Just "stderr = mynewpipe;" is a bit too simplistic, right? The other option would be to go with a syslog-style implementation, which you write explicitly to over a socket. But that won't address your concern below (from other mail). > The fundamentally unfixable problem with his method is that > it can only capture elog output, not stderr output from > libraries that we don't control (the dynamic linker being the > biggest case, but there are others). How common are these issues really? Just getting to the normal backend output would probably be a big win in most sitations, wouldn't it? In the case these libraries put out information, we get an elog() call *as well*, don't we? Then you could easily redirect stderr somewhere on the server, while still processing "ordinary elog output" through the log manager. //Magnus ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] PITR Archive Recovery plus WIP PITR
On Wed, 2004-07-14 at 05:45, Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> I think that judgment is exactly backward. *Not* having timelines is > >> what will cause serious and possibly fatal mistakes during restore: > >> people will hand the wrong xlog files to restore and the software will > >> be unable to recognize the inconsistency. > > > I assume they could just restore from backup and try again. > > Sure, if they don't mind losing whatever transactions they processed > before realizing how broken their database was. That's not going to be > an acceptable answer for the sort of installations that need PITR in the > first place. > > I think it's really important to get this right the first time, both for > reliability's sake and because we are expecting people to write their > own archiving scripts. If we change the xlog segment naming convention > later on, then we will break all those scripts. > I agree, but I'm going to have a rest day while people test what is already there in case there are further code changeswhich nods towards both of your concerns. BTW, one test last night broke because of the lack of timelines... Best Regards, Simon Riggs ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] Fixes for 3 bugs in pg_dump
Actually, i'm not sure that making it respect -S is the right way to go. What we really need is an option that specifies the cluster owner on the new installation. I will revert that part of this patch and resubmit shortly... Chris Christopher Kings-Lynne wrote: This patch fixes the following bugs: * pg_dump --clean against a pre-7.3 server output drop commands in the form: DROP "".foo; . These will now all be output as: DROP public.foo; * If you use ALTER USER to set user params on the cluster owner user, these would not be dumped. This patch will now dump ALTER USER commands for the cluster owner. If the -S command line switch is used to specify a superuser, then the cluster owner ALTER USER commands will be dumped for that user instead. * The DateStyle and search_path GUC variables must not be quoted when dumped. Chris ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
