Tom Lane wrote:
Give me a use case that requires that, and is sufficiently interesting
to justify even a marginal decrease in the reliability of the log
process.
Frankly, I do not believe that database users should have anything to do
with the log rotation process.
The (super)user will sometimes pu
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Tom, you didn't like Andreas' idea of allowing the user to rotate the
log files on demand.
Give me a use case that requires that, and is sufficiently interesting
to justify even a marginal decrease in the reliability of the log
process.
- D
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I thought rotatelogs supported it so we should in cases where someone
> > wanted to make a new log file to delete an unusually large one, like a 1
> > gig log file caused by some runaway process.
>
> Hm? We have a rotate-on-size para
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I thought rotatelogs supported it so we should in cases where someone
> wanted to make a new log file to delete an unusually large one, like a 1
> gig log file caused by some runaway process.
Hm? We have a rotate-on-size parameter, so that's not going t
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom, you didn't like Andreas' idea of allowing the user to rotate the
> > log files on demand.
>
> Give me a use case that requires that, and is sufficiently interesting
> to justify even a marginal decrease in the reliability of the
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom, you didn't like Andreas' idea of allowing the user to rotate the
> log files on demand.
Give me a use case that requires that, and is sufficiently interesting
to justify even a marginal decrease in the reliability of the log
process.
Frankly, I do
