Re: [PATCHES] [SQL] array_in: '{}}'::text[]
Joe Conway <[EMAIL PROTECTED]> writes:
> /* Make a modifiable copy of the input */
> ! string_save = (char *) palloc0(strlen(string) + 1);
> strcpy(string_save, string);
palloc0, instead of palloc, is clearly a waste of cycles here ...
actually, why isn't this just a pstrdup?
> /* special case for an empty array */
> ! if (strlen(str) == 2 && strncmp(str, "{}", 2) == 0)
> return 0;
Why not just if (strcmp(str, "{}") == 0)
Looks reasonable otherwise.
regards, tom lane
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [PATCHES] log_filename_prefix --> log_filename + strftime()
On Friday August 27 2004 4:34, Ed L. wrote: > > One other thing I've been thinking of suggesting is that the > > next-rotation-target-time be rounded to an exact multiple of > > log_rotation_age. So for example if you set log_rotation_age = 60 > > minutes then rotations will happen at the top of the hour no matter > > when the postmaster was started. The simplistic approach of doing > > this on the time_t value would mean that, say, age = 24*60 would give > > you rotations occurring at GMT midnight not local midnight, which isn't > > perfect but I'd say good enough. Again though, the interaction with > > size-driven rotation might need more thought. > > Apache's rotatelogs works this way, and includes a UTC offset option, to > allow rotations at local midnight. I see struct pg_tm has tm_gmtoff, but it seems to be zero on my MST7MDT 2.4 kernel linux box here. Is there a standard way of retrieving the offset within the PG source code? Ed ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[PATCHES] Show full path name when saving in psql
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message
This patch shows the full path name when doing a \s in psql,
if you have previously issued a \cd command.
--
Greg Sabino Mullane [EMAIL PROTECTED]
PGP Key: 0x14964AC8 200408271849
Index: command.c
===
RCS file: /projects/cvsroot/pgsql-server/src/bin/psql/command.c,v
retrieving revision 1.123
diff -c -r1.123 command.c
*** command.c 13 Aug 2004 14:47:23 - 1.123
--- command.c 27 Aug 2004 19:15:41 -
***
*** 258,263
--- 258,266
success = false;
}
+ pset.dirname = pg_strdup(dir);
+ canonicalize_path(pset.dirname);
+
if (opt)
free(opt);
}
***
*** 643,649
success = saveHistory(fname ? fname : "/dev/tty");
if (success && !quiet && fname)
! printf(gettext("Wrote history to file \"%s\".\n"), fname);
free(fname);
}
--- 646,653
success = saveHistory(fname ? fname : "/dev/tty");
if (success && !quiet && fname)
! printf(gettext("Wrote history to file \"%s/%s\".\n"),
!pset.dirname ? pset.dirname : ".",
fname);
free(fname);
}
-BEGIN PGP SIGNATURE-
iD8DBQFBL7rcvJuQZxSWSsgRArEzAJ46xxARaVVfeVmx/Ivjzr0+2iIsTACdHFgz
vFutaRJp5l/+Plmc4Q7CM9o=
=ibcl
-END PGP SIGNATURE-
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] log_filename_prefix --> log_filename + strftime()
On Friday August 27 2004 3:49, Tom Lane wrote: > > A potential problem is what about size-driven rotation? If the hourly > output exceeds log_rotation_size then you'd truncate and rewrite the > current file, which is just exactly not what you want :-(. You could > say that truncation occurs only at time-driven, not size-driven > rotations, but that would effectively amount to saying that size-driven > rotation is disabled, which I don't think I like ... > One other thing I've been thinking of suggesting is that the > next-rotation-target-time be rounded to an exact multiple of > log_rotation_age. So for example if you set log_rotation_age = 60 > minutes then rotations will happen at the top of the hour no matter > when the postmaster was started. The simplistic approach of doing > this on the time_t value would mean that, say, age = 24*60 would give > you rotations occurring at GMT midnight not local midnight, which isn't > perfect but I'd say good enough. Again though, the interaction with > size-driven rotation might need more thought. Apache's rotatelogs works this way, and includes a UTC offset option, to allow rotations at local midnight. > Possibly you could fix the first issue if you did all this to the code > and then used, say, log_filename "postgresql_%H:%M.log" with 60-minute > rotation. You'd normally get only logfiles named after the top of the > hour, but in an hour with unusually heavy log output you might get some > additional files with intermediate %M values. Course that puts you back > to needing a cron daemon to clean those up ... Not that elegant, but pretty reasonable, I think. In the normal case of logfiles under the maximum size, everything is cleaned up. If you bloat, you have some clean-up to do, but easy enough with a cron job. We have been operating ~40 clusters this way for a couple years now with a modified Apache rotatelogs (w/truncate option) and a cron to clean-up too-old logfiles. It has pretty much eliminated our disk-full crises from DB logs. Ed ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] log_filename_prefix --> log_filename + strftime()
"Ed L." <[EMAIL PROTECTED]> writes: > On Friday August 27 2004 1:15, Tom Lane wrote: >> Yeah, and it would also prevent a risk I now see with your initial >> patch: if no %, it'll write the same filename each time, which >> is almost certainly not desired. Works for me. > I think this turns out to be no big deal either way here as it is for Apache > either way. Consider if I set my rotation time to 1 hour and my > log_filename = 'server_log.%a' (server_log.Fri). But that avoids the problem because you *do* have an escape, and thus more than one possible logfilename. If we treat no-escape as meaning a constant filename, there is no rotation possible, other than rotation through truncation which doesn't seem likely to be useful to anyone. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] log_filename_prefix --> log_filename + strftime()
"Ed L." <[EMAIL PROTECTED]> writes:
> One addition I'd like to include with the revised patch: a boolean
> postgresql.conf option ('log_truncate_on_rotation', default false) to
> truncate any existing log file by the same name. Default behavior here and
> with Apache is to always append, but it's a useful feature for us because
> it largely eliminates the issue of logs filling up the disk. You don't
> want the log clobbered on restarts, so the idea is to only truncate during
> time/size-based rotation, not on the initial open. Thoughts?
Hmm, so if you use e.g. "postgresql_%H.log", you always have 24 logfiles
of one hour each, and you don't need any explicit code at all to remove
old logs. Not a bad idea. It's definitely creeping featurism ... but
I can see the value of not needing any cron daemon to remove old logs.
A potential problem is what about size-driven rotation? If the hourly
output exceeds log_rotation_size then you'd truncate and rewrite the
current file, which is just exactly not what you want :-(. You could
say that truncation occurs only at time-driven, not size-driven
rotations, but that would effectively amount to saying that size-driven
rotation is disabled, which I don't think I like ...
One other thing I've been thinking of suggesting is that the
next-rotation-target-time be rounded to an exact multiple of
log_rotation_age. So for example if you set log_rotation_age = 60
minutes then rotations will happen at the top of the hour no matter
when the postmaster was started. The simplistic approach of doing
this on the time_t value would mean that, say, age = 24*60 would give
you rotations occurring at GMT midnight not local midnight, which isn't
perfect but I'd say good enough. Again though, the interaction with
size-driven rotation might need more thought.
Possibly you could fix the first issue if you did all this to the code
and then used, say, log_filename "postgresql_%H:%M.log" with 60-minute
rotation. You'd normally get only logfiles named after the top of the
hour, but in an hour with unusually heavy log output you might get some
additional files with intermediate %M values. Course that puts you back
to needing a cron daemon to clean those up ...
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] log_filename_prefix --> log_filename + strftime()
On Friday August 27 2004 1:15, Tom Lane wrote: > "Ed L." <[EMAIL PROTECTED]> writes: > > On Friday August 27 2004 1:03, Tom Lane wrote: > >> Hmm ... there isn't any way to emulate that with strftime escapes, > >> unless I missed the right one. > > > > If you supply an escape, Apache will override that default epoch. So I > > could see setting the default to "server_log" or "postgresql_log" or > > whatever, and making the default (with no escapes supplied) be the > > epoch. That would be easy tweak, and be much closer to Apache style. > > Yeah, and it would also prevent a risk I now see with your initial > patch: if no %, it'll write the same filename each time, which > is almost certainly not desired. Works for me. I think this turns out to be no big deal either way here as it is for Apache either way. Consider if I set my rotation time to 1 hour and my log_filename = 'server_log.%a' (server_log.Fri). Then each of the first 22 rotations for the day will simply reopen and append to the same file. IIRC, Apache's rotatelogs works the same way. In both cases, you just have to be careful to coordinate your filename and rotation time/size limits to get the desired effect. Ed ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] log_filename_prefix --> log_filename + strftime()
On Friday August 27 2004 2:15, Tom Lane wrote:
> "Ed L." <[EMAIL PROTECTED]> writes:
> > If log_filename = 'xxx', rotate with strftime() to
> > 'xxx-%Y-%m-%d_%H%M%S'
>
> No, I was thinking that if no %'s in the log_filename, then use xxx.EPOCH
> to provide Apache compatibility.
OK, that works for me.
One addition I'd like to include with the revised patch: a boolean
postgresql.conf option ('log_truncate_on_rotation', default false) to
truncate any existing log file by the same name. Default behavior here and
with Apache is to always append, but it's a useful feature for us because
it largely eliminates the issue of logs filling up the disk. You don't
want the log clobbered on restarts, so the idea is to only truncate during
time/size-based rotation, not on the initial open. Thoughts?
Ed
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] [SQL] array_in: '{}}'::text[]
Joe Conway wrote:
Markus Bertheau wrote:
Is there a reason the array_in parser accepts additional closing braces
at the end?
oocms=# SELECT '{}}'::text[];
text
--
{}
(1 ÑÑ)
Hmmm, I was *about* to say that this is fixed in cvs (and indeed, the
array_in parser is significantly tightened up compared to previous
releases), but unfortunately, there is still work to be done :(
The attached patch takes care of the above issue:
regression=# SELECT '{}}'::text[];
ERROR: malformed array literal: "{}}"
If there are no objections, I'll apply in about 24 hours.
Joe
Index: src/backend/utils/adt/arrayfuncs.c
===
RCS file: /cvsroot/pgsql-server/src/backend/utils/adt/arrayfuncs.c,v
retrieving revision 1.107
diff -c -r1.107 arrayfuncs.c
*** src/backend/utils/adt/arrayfuncs.c 8 Aug 2004 05:01:55 - 1.107
--- src/backend/utils/adt/arrayfuncs.c 27 Aug 2004 20:31:46 -
***
*** 183,190
typioparam = my_extra->typioparam;
/* Make a modifiable copy of the input */
! /* XXX why are we allocating an extra 2 bytes here? */
! string_save = (char *) palloc(strlen(string) + 3);
strcpy(string_save, string);
/*
--- 183,189
typioparam = my_extra->typioparam;
/* Make a modifiable copy of the input */
! string_save = (char *) palloc0(strlen(string) + 1);
strcpy(string_save, string);
/*
***
*** 375,380
--- 374,380
nelems_last[MAXDIM];
bool scanning_string = false;
bool eoArray = false;
+ bool empty_array = true;
char *ptr;
ArrayParseState parse_state = ARRAY_NO_LEVEL;
***
*** 385,391
}
/* special case for an empty array */
! if (strncmp(str, "{}", 2) == 0)
return 0;
ptr = str;
--- 385,391
}
/* special case for an empty array */
! if (strlen(str) == 2 && strncmp(str, "{}", 2) == 0)
return 0;
ptr = str;
***
*** 395,400
--- 395,404
while (!itemdone)
{
+ if (parse_state == ARRAY_ELEM_STARTED ||
+ parse_state == ARRAY_QUOTED_ELEM_STARTED)
+ empty_array = false;
+
switch (*ptr)
{
case '\0':
***
*** 481,487
if (parse_state != ARRAY_ELEM_STARTED &&
parse_state != ARRAY_ELEM_COMPLETED &&
parse_state != ARRAY_QUOTED_ELEM_COMPLETED &&
! parse_state != ARRAY_LEVEL_COMPLETED)
ereport(ERROR,
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
errmsg("malformed array literal: \"%s\"", str)));
--- 485,492
if (parse_state != ARRAY_ELEM_STARTED &&
parse_state != ARRAY_ELEM_COMPLETED &&
parse_state != ARRAY_QUOTED_ELEM_COMPLETED &&
! parse_state != ARRAY_LEVEL_COMPLETED &&
! !(nest_level == 1 && parse_state == ARRAY_LEVEL_STARTED))
ereport(ERROR,
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
errmsg("malformed array literal: \"%s\"", str)));
***
*** 562,567
--- 567,586
temp[ndim - 1]++;
ptr++;
}
+
+ /* only whitespace is allowed after the closing brace */
+ while (*ptr)
+ {
+ if (!isspace(*ptr++))
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
+ errmsg("malformed array literal: \"%s\"", str)));
+ }
+
+ /* special case for an empty array */
+ if (empty_array)
+ return 0;
+
for (i = 0; i < ndim; ++i)
dim[i] = temp[i];
Index: src/test/regress/expected/arrays.out
===
RCS file: /cvsroot/pgsql-server/src/test/regress/expected/arrays.out,v
retrieving revision 1.22
diff -c -r1.22 arrays.out
*** src/test/regress/expected/arrays.out 5 Aug 2004 03:30:03 - 1.22
--- src/test/regress/expected/arrays.out 27 Aug 2004 20:31:46 -
***
*** 425,427
--- 425,485
t
(1 row)
+ --
+ -- General array parser tests
+ --
+ -- none of the following should be accepted
+ select '{{1,{2}},{2,3}}'::text[];
+ ERROR: malformed array literal: "{{1,{2}},{2,3}}"
+ select '{{},{}}'::text[];
+ ERROR: malformed array literal: "{{},{}}"
+ select '{{1,2},\\{2,3}}'::text[];
+ ERROR: malformed array literal: "{{1,2},\{2,3}}"
+ select '{{"1 2" x},{3}}'::text[];
+ ERROR: malformed array literal: "{{"1 2" x},{3}}"
+ select '{}}'::text[];
+ ERROR: malformed array literal: "{}}"
+ select '{ }}'::text[];
+ ERROR: malformed array literal: "{ }}"
+ -- none of the above should be accepted
+ -- all of the following should be accepted
+ select '{}'::text[];
+ text
+ --
+ {}
+ (1 row)
+
+ select '{{{1,2,3,4},{2,3,4,5}},{{3,4,5,6},{4,5,6,7}}}'::text[];
+ text
+ ---
+ {{{1,2,3,4},{2,3,4,5}},{{3,4,5,6},{4,5,6,7}}}
+ (1 row)
+
+ select '{0 second ,0 second}'::interval[];
+interval
+ ---
+ {"@ 0","@ 0"}
+ (1 row)
+
+ select '{ { "," } , { 3 } }'::t
Re: [PATCHES] log_filename_prefix --> log_filename + strftime()
"Ed L." <[EMAIL PROTECTED]> writes: > If log_filename = 'xxx', rotate with strftime() to 'xxx-%Y-%m-%d_%H%M%S' No, I was thinking that if no %'s in the log_filename, then use xxx.EPOCH to provide Apache compatibility. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] log_filename_prefix --> log_filename + strftime()
On Friday August 27 2004 1:39, Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Ah, so we keep the existing format but drop the pid, and just make it > > changable by the user, and we rename it. Doesn't sound as drastic as > > it first did. > > Yeah, the only change in default behavior would be to drop the PID part > of the log filename, which doesn't seem too bad, since people aren't yet > depending on that. > > regards, tom lane OK, if I read you correctly... Default remains "postgresql-%Y-%m-%d_%H%M%S.log" (Apache style: access_log.%s) If log_filename = 'xxx', rotate with strftime() to 'xxx-%Y-%m-%d_%H%M%S' (Apache style: xxx.%s) If log_filename = 'xxx.%a', rotate with strftime() to 'xxx.%a' (Apache style: xxx.%a) Not a big fan of the verbose 32-character default name, 'server_log.%s' would be my pick, but easy enough to override it. Ed ---(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] log_filename_prefix --> log_filename + strftime()
Bruce Momjian <[EMAIL PROTECTED]> writes: > Ah, so we keep the existing format but drop the pid, and just make it > changable by the user, and we rename it. Doesn't sound as drastic as it > first did. Yeah, the only change in default behavior would be to drop the PID part of the log filename, which doesn't seem too bad, since people aren't yet depending on that. regards, tom lane ---(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] log_filename_prefix --> log_filename + strftime()
Tom Lane wrote: > Andreas Pflug <[EMAIL PROTECTED]> writes: > > I don't have the time now to review the impact, but this might make > > interpreting the log filename difficult or impossible, effectively > > corrupting pg_logdir_ls. > > So if you want to use that, you use a format that it can cope with. > I don't see a problem. > > (This is probably an OK reason to keep the default log_filename in > Y/M/D/H/M/S style, though, rather than ".epoch" style.) Ah, so we keep the existing format but drop the pid, and just make it changable by the user, and we rename it. Doesn't sound as drastic as it first did. -- 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 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] log_filename_prefix --> log_filename + strftime()
Andreas Pflug <[EMAIL PROTECTED]> writes: > I don't have the time now to review the impact, but this might make > interpreting the log filename difficult or impossible, effectively > corrupting pg_logdir_ls. So if you want to use that, you use a format that it can cope with. I don't see a problem. (This is probably an OK reason to keep the default log_filename in Y/M/D/H/M/S style, though, rather than ".epoch" style.) regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] log_filename_prefix --> log_filename + strftime()
Tom Lane wrote: "Ed L." <[EMAIL PROTECTED]> writes: On Friday August 27 2004 12:41, Tom Lane wrote: BTW, as long as we are taking Apache as the de facto standard --- does the default of "postgresql-%Y-%m-%d_%H%M%S.log" actually make sense, or would something different be closer to the common practice with Apache? I should say, Apache rotatelogs takes a configurable filename and then appends ".N" where N is the logfile start time epoch. In one case, its access_log.N, in another its error_log.N. Hmm ... there isn't any way to emulate that with strftime escapes, unless I missed the right one. According to my Linux man page, the Olsen library has %s for that. I don't see it in src/timezone/strftime.c, though cheers andrew ---(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] log_filename_prefix --> log_filename + strftime()
"Ed L." <[EMAIL PROTECTED]> writes: > On Friday August 27 2004 1:03, Tom Lane wrote: >> Hmm ... there isn't any way to emulate that with strftime escapes, >> unless I missed the right one. > If you supply an escape, Apache will override that default epoch. So I > could see setting the default to "server_log" or "postgresql_log" or > whatever, and making the default (with no escapes supplied) be the epoch. > That would be easy tweak, and be much closer to Apache style. Yeah, and it would also prevent a risk I now see with your initial patch: if no %, it'll write the same filename each time, which is almost certainly not desired. Works for me. 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] log_filename_prefix --> log_filename + strftime()
Tom Lane wrote: "Ed L." <[EMAIL PROTECTED]> writes: Attached is a patch which replaces the 'log_filename_prefix' configuration directive with a similar 'log_filename' directive. + changes the default log filename to exclude the PID; This would be better stated as "makes it impossible to use the PID in the file name". While I'm prepared to grant that it may not be necessary to do so in many scenarios, I'm not very happy with arbitrarily removing the ability ... especially without giving any justification. I don't have the time now to review the impact, but this might make interpreting the log filename difficult or impossible, effectively corrupting pg_logdir_ls. I don't object against adjusting the timestamp format in a reasonable way, but it should stay fixed; same about PID. Regards, Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] log_filename_prefix --> log_filename + strftime()
On Friday August 27 2004 1:03, Tom Lane wrote:
> "Ed L." <[EMAIL PROTECTED]> writes:
> > On Friday August 27 2004 12:41, Tom Lane wrote:
> >> BTW, as long as we are taking Apache as the de facto standard --- does
> >> the default of "postgresql-%Y-%m-%d_%H%M%S.log" actually make sense,
> >> or would something different be closer to the common practice with
> >> Apache?
> >
> > I should say, Apache rotatelogs takes a configurable filename and then
> > appends ".N" where N is the logfile start time epoch. In one case, its
> > access_log.N, in another its error_log.N.
>
> Hmm ... there isn't any way to emulate that with strftime escapes,
> unless I missed the right one.
If you supply an escape, Apache will override that default epoch. So I
could see setting the default to "server_log" or "postgresql_log" or
whatever, and making the default (with no escapes supplied) be the epoch.
That would be easy tweak, and be much closer to Apache style.
Ed
Apache 1.3.31:
if (use_strftime) {
struct tm *tm_now;
tm_now = gmtime(&tLogStart);
strftime(buf2, sizeof(buf2), szLogRoot, tm_now);
}
else {
sprintf(buf2, "%s.%010d", szLogRoot, (int) tLogStart);
}
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [PATCHES] log_filename_prefix --> log_filename + strftime()
"Ed L." <[EMAIL PROTECTED]> writes: > On Friday August 27 2004 12:41, Tom Lane wrote: >> BTW, as long as we are taking Apache as the de facto standard --- does >> the default of "postgresql-%Y-%m-%d_%H%M%S.log" actually make sense, or >> would something different be closer to the common practice with Apache? > I should say, Apache rotatelogs takes a configurable filename and then > appends ".N" where N is the logfile start time epoch. In one case, its > access_log.N, in another its error_log.N. Hmm ... there isn't any way to emulate that with strftime escapes, unless I missed the right one. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] log_filename_prefix --> log_filename + strftime()
Andrew Dunstan <[EMAIL PROTECTED]> writes: > If the PID isn't there is there a danger of different postmasters > clobbering each other's logs? Only if they're logging into the same directory with the same filename pattern. This isn't the default (the default log_directory is under $PGDATA), and so I'm not that worried now that I think about it carefully. I'm coming around to agree with Ed's position that it's not worth the trouble to provide more than the strftime escapes. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] log_filename_prefix --> log_filename + strftime()
Tom Lane wrote: "Ed L." <[EMAIL PROTECTED]> writes: On Friday August 27 2004 12:08, Tom Lane wrote: [ justification please ] Yes, should have said more on that item. First, I didn't see how to easily make it configurable in combination with strftime() without doing more work, and it didn't appear to be worth the effort. By its addition, hard-coding the PID into the filename deviates from what I would argue is the de facto standard of Apache's rotatelogs and forces a naming convention where none existed before. That creates work for us as we have a considerable infrastructure setup to deal with logs; I suspect that may be the case with others. I looked, but did not find, justification for why it was introduced; I would assume it was added to allow for multiple postmasters sharing the same log directory. I had difficulty fathoming the usefulness of this being hard-coded, as it seems one could compensate easily through the configurable 'log_filename' if one chose to share a log directory among postmasters. Not by including the PID, but by some other postmaster-unique naming approach. Given its a new 'feature', I'm hoping it can be altered to return the freedom of filenaming to the administrator. Or you could use different log_directory settings for different PMs. Fair enough. Anyone else have an opinion pro or con about this change? IMHO it's in the gray area between bug fix and feature addition. If we want to do it, though, doing it now is certainly better than holding it for 8.1, since by then people would have gotten used to the present behavior. BTW, as long as we are taking Apache as the de facto standard --- does the default of "postgresql-%Y-%m-%d_%H%M%S.log" actually make sense, or would something different be closer to the common practice with Apache? If the PID isn't there is there a danger of different postmasters clobbering each other's logs? ISTM having the PID there gives some sort of guarantee that that won't happen. I don't have any strong opinion one way or another, but I wondered if a configurable strings with % escapes like we use for log_line_prefix might be better. It could be argued to be overkill, I guess. Alternatively, we could have a different boolean option 'log_filename_use_pid' or some such. cheers andrew ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] log_filename_prefix --> log_filename + strftime()
On Friday August 27 2004 12:51, Ed L. wrote: > On Friday August 27 2004 12:41, Tom Lane wrote: > > BTW, as long as we are taking Apache as the de facto standard --- does > > the default of "postgresql-%Y-%m-%d_%H%M%S.log" actually make sense, or > > would something different be closer to the common practice with Apache? > > Apache defaults to access_log.N where N is the epoch of the logfile start > time. I should say, Apache rotatelogs takes a configurable filename and then appends ".N" where N is the logfile start time epoch. In one case, its access_log.N, in another its error_log.N. Ed ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] log_filename_prefix --> log_filename + strftime()
On Friday August 27 2004 12:41, Tom Lane wrote: > > BTW, as long as we are taking Apache as the de facto standard --- does > the default of "postgresql-%Y-%m-%d_%H%M%S.log" actually make sense, or > would something different be closer to the common practice with Apache? Apache defaults to access_log.N where N is the epoch of the logfile start time. Ed ---(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] log_filename_prefix --> log_filename + strftime()
"Ed L." <[EMAIL PROTECTED]> writes: > On Friday August 27 2004 12:08, Tom Lane wrote: >> [ justification please ] > Yes, should have said more on that item. First, I didn't see how to easily > make it configurable in combination with strftime() without doing more > work, and it didn't appear to be worth the effort. By its addition, > hard-coding the PID into the filename deviates from what I would argue is > the de facto standard of Apache's rotatelogs and forces a naming convention > where none existed before. That creates work for us as we have a > considerable infrastructure setup to deal with logs; I suspect that may be > the case with others. I looked, but did not find, justification for why it > was introduced; I would assume it was added to allow for multiple > postmasters sharing the same log directory. I had difficulty fathoming the > usefulness of this being hard-coded, as it seems one could compensate > easily through the configurable 'log_filename' if one chose to share a log > directory among postmasters. Not by including the PID, but by some other > postmaster-unique naming approach. Given its a new 'feature', I'm hoping > it can be altered to return the freedom of filenaming to the administrator. Or you could use different log_directory settings for different PMs. Fair enough. Anyone else have an opinion pro or con about this change? IMHO it's in the gray area between bug fix and feature addition. If we want to do it, though, doing it now is certainly better than holding it for 8.1, since by then people would have gotten used to the present behavior. BTW, as long as we are taking Apache as the de facto standard --- does the default of "postgresql-%Y-%m-%d_%H%M%S.log" actually make sense, or would something different be closer to the common practice with Apache? 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] log_filename_prefix --> log_filename + strftime()
On Friday August 27 2004 12:08, Tom Lane wrote: > "Ed L." <[EMAIL PROTECTED]> writes: > > Attached is a patch which replaces the 'log_filename_prefix' > > configuration directive with a similar 'log_filename' directive. > > + changes the default log filename to exclude the PID; > > This would be better stated as "makes it impossible to use the PID > in the file name". While I'm prepared to grant that it may not be > necessary to do so in many scenarios, I'm not very happy with > arbitrarily removing the ability ... especially without giving any > justification. Yes, should have said more on that item. First, I didn't see how to easily make it configurable in combination with strftime() without doing more work, and it didn't appear to be worth the effort. By its addition, hard-coding the PID into the filename deviates from what I would argue is the de facto standard of Apache's rotatelogs and forces a naming convention where none existed before. That creates work for us as we have a considerable infrastructure setup to deal with logs; I suspect that may be the case with others. I looked, but did not find, justification for why it was introduced; I would assume it was added to allow for multiple postmasters sharing the same log directory. I had difficulty fathoming the usefulness of this being hard-coded, as it seems one could compensate easily through the configurable 'log_filename' if one chose to share a log directory among postmasters. Not by including the PID, but by some other postmaster-unique naming approach. Given its a new 'feature', I'm hoping it can be altered to return the freedom of filenaming to the administrator. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] log_filename_prefix --> log_filename + strftime()
"Ed L." <[EMAIL PROTECTED]> writes: > Attached is a patch which replaces the 'log_filename_prefix' configuration > directive with a similar 'log_filename' directive. > + changes the default log filename to exclude the PID; This would be better stated as "makes it impossible to use the PID in the file name". While I'm prepared to grant that it may not be necessary to do so in many scenarios, I'm not very happy with arbitrarily removing the ability ... especially without giving any justification. 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] log_filename_prefix --> log_filename + strftime()
The patch is intended for 8.0.0 or later, and was generated and tested with the cvs trunk as of 26-Aug-2004. On Friday August 27 2004 11:50, Ed L. wrote: > Attached is a patch which replaces the 'log_filename_prefix' > configuration directive with a similar 'log_filename' directive. It > differs from the former in the following ways: > > + allows embedded strftime() escapes ala Apache's rotatelogs; > + eliminates hard-coded embedding of the postmaster pid; > + makes the current hard-coded timestamp configurable; > + changes the default log filename to exclude the PID; > > This patch enables us to continue using our existing log-handling > utilities and filenaming conventions which we now use with Apache's > rotatelogs. ---(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] log_filename_prefix --> log_filename + strftime()
Attached is a patch which replaces the 'log_filename_prefix' configuration
directive with a similar 'log_filename' directive. It differs from the
former in the following ways:
+ allows embedded strftime() escapes ala Apache's rotatelogs;
+ eliminates hard-coded embedding of the postmaster pid;
+ makes the current hard-coded timestamp configurable;
+ changes the default log filename to exclude the PID;
This patch enables us to continue using our existing log-handling utilities
and filenaming conventions which we now use with Apache's rotatelogs.
Index: doc/src/sgml/runtime.sgml
===
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/runtime.sgml,v
retrieving revision 1.279
diff -C1 -r1.279 runtime.sgml
*** doc/src/sgml/runtime.sgml 24 Aug 2004 00:06:50 - 1.279
--- doc/src/sgml/runtime.sgml 27 Aug 2004 17:37:09 -
***
*** 1927,1930
!
! log_filename_prefix (string)
--- 1927,1930
!
! log_filename (string)
***
*** 1932,1936
When redirect_stderr is enabled, this option
! sets the prefix of the file names of the created log files.
! The postmaster PID and the current time are appended to this
! prefix to form an exact log file name.
This option can only be set at server start or in the
--- 1932,1935
When redirect_stderr is enabled, this option
! sets the name of the created log files. Any embedded
! strftime escapes sequences are interpolated per strftime().
This option can only be set at server start or in the
Index: src/backend/postmaster/syslogger.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/postmaster/syslogger.c,v
retrieving revision 1.5
diff -C1 -r1.5 syslogger.c
*** src/backend/postmaster/syslogger.c 9 Aug 2004 20:28:48 - 1.5
--- src/backend/postmaster/syslogger.c 27 Aug 2004 17:37:11 -
***
*** 64,66
char * Log_directory = "pg_log";
! char * Log_filename_prefix = "postgresql-";
--- 64,66
char * Log_directory = "pg_log";
! char * Log_filename = "postgresql-%Y-%m-%d_%H%M%S.log";
***
*** 122,123
--- 122,124
char currentLogDir[MAXPGPATH];
+ char currentLogFilename[MAXPGPATH];
***
*** 219,222
last_rotation_time = time(NULL);
! /* remember active logfile directory */
strncpy(currentLogDir, Log_directory, MAXPGPATH);
--- 220,224
last_rotation_time = time(NULL);
! /* remember active logfile directory and filename */
strncpy(currentLogDir, Log_directory, MAXPGPATH);
+ strncpy(currentLogFilename, Log_filename, MAXPGPATH);
***
*** 240,247
/*
! * Check if the log directory changed in postgresql.conf. If so,
! * force rotation to make sure we're writing the logfiles in the
! * right place.
! *
! * XXX is it worth responding similarly to a change of
! * Log_filename_prefix?
*/
--- 242,246
/*
! * Check if the log directory or filename prefix changed in
! * postgresql.conf. If so, force rotation to make sure we're
! * writing the logfiles in the right place.
*/
***
*** 252,253
--- 251,257
}
+ if (strncmp(Log_filename, currentLogFilename, MAXPGPATH) != 0)
+ {
+ strncpy(currentLogFilename, Log_filename, MAXPGPATH);
+ rotation_requested = true;
+ }
}
***
*** 791,796
char *filename;
! char stamptext[128];
!
! pg_strftime(stamptext, sizeof(stamptext), "%Y-%m-%d_%H%M%S",
! pg_localtime(×tamp));
--- 795,797
char *filename;
! int len;
***
*** 799,807
if (is_absolute_path(Log_directory))
! snprintf(filename, MAXPGPATH, "%s/%s%05u_%s.log",
! Log_directory, Log_filename_prefix,
! (unsigned int) PostmasterPid, stamptext);
else
! snprintf(filename, MAXPGPATH, "%s/%s/%s%05u_%s.log",
! DataDir, Log_directory, Log_filename_prefix,
! (unsigned int) PostmasterPid, stamptext);
--- 800,815
if (is_absolute_path(Log_directory))
! snprintf(filename, MAXPGPATH, "%s/", Log_directory);
else
! snprintf(filename, MAXPGPATH, "%s/%s/", DataDir, Log_directory);
!
! len = strnlen(filename, MAXPGPATH);
!
! /* use strftime() if there are embedded % escape sequences */
! if ( strstr(Log_filename, "%") != NULL ) {
! struct pg_tm *now;
! now = pg_gmtime(×tamp);
! pg_strftime((char*) (filename + len), MAXPGPATH - len, Log_filename, now);
! }
! else
! snprintf((char*) (filename + len), MAXPGPATH - len, "%s", Log_filename);
Index: src/backend/utils/misc/guc.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/utils/misc/
