Tom Lane wrote:
hmm... That's true. I don't think autovacuum doesn't anything to account
for the concept of rolledback inserts.
I think this is the fault of the stats system design. AFAICT from a
quick look at the code, inserted/updated/deleted tuples are reported
to the collector in the
On Fri, 2006-01-27 at 14:08 -0500, Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > On Fri, 2006-01-27 at 13:43 -0500, Tom Lane wrote:
> >> That line of argument leads to the suggestion that pg_dump should just
> >> use something else (I'd vote for "|"), all the time, in order to pr
Tom Lane <[EMAIL PROTECTED]> writes:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > On Fri, 2006-01-27 at 13:43 -0500, Tom Lane wrote:
> >> That line of argument leads to the suggestion that pg_dump should just
> >> use something else (I'd vote for "|"), all the time, in order to produce
> >> m
On Jan 27, 2006, at 10:21 AM, Jason Essington wrote:
Has there been any movement on this? as of 8.1.2 psql still whines
on OS X tiger when you exit.
I realize it is not significant, but I'd still rather not see it.
In the interim, I've done:
errno = 0;
write_h
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> On Fri, 2006-01-27 at 13:43 -0500, Tom Lane wrote:
>> That line of argument leads to the suggestion that pg_dump should just
>> use something else (I'd vote for "|"), all the time, in order to produce
>> more robust dump files. I still don't see the arg
On Fri, 2006-01-27 at 13:43 -0500, Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > I could not disagree more. The invisibility of tabs makes their use as a
> > delimiter wholly evil. I have lost count of the number of corrupted
> > makefiles etc. I have seen because a tab got conve
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I could not disagree more. The invisibility of tabs makes their use as a
> delimiter wholly evil. I have lost count of the number of corrupted
> makefiles etc. I have seen because a tab got converted to a space and it
> was impossible to tell.
> More te
On Fri, 2006-01-27 at 13:12 -0500, Greg Stark wrote:
>
> Personally I find anything that would encourage people to use anything other
> than tabs evil anyways. All those people who think | is somehow a reasonable
> choice or want to use commas and then get all confused trying to escape them
> and
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> David I don't get this... what are you copying from/to that would
> wouldn't just script? If you throw into a script you can change
> the delimiter on the fly using translation.
I think what he's getting at is for things like, say, a contrib packag
to
creating directory /home/postgres/v82/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
...
Less is more :)
I like it.
Joshua D. Drake
regards, tom lane
---(end of broadcast)-
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> My question was at a higher level, actually: *what* should we be
> >> counting?
>
> > Oh, I see. Do you think small incremental improvements to the stat
> > system will buy us much? I think we should be thinkin
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> My question was at a higher level, actually: *what* should we be
>> counting?
> Oh, I see. Do you think small incremental improvements to the stat
> system will buy us much? I think we should be thinking big here, i.e.
> rewrite mos
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> I think this is unquestionably
> >> a bug, at least for autovacuum's purposes --- though it might be OK
> >> for the original intent of the stats system, which was simply to track
> >> activity levels.
> >>
> >>
Has there been any movement on this? as of 8.1.2 psql still whines on
OS X tiger when you exit.
I realize it is not significant, but I'd still rather not see it.
In the interim, I've done:
errno = 0;
write_history(fname); /* return value is not standardized */
I wrote:
>> While we can probably all agree that it's not very interesting to
>> mention every single directory that initdb creates, I find it ...
I took a quick look at the source and see that it would be trivial
to reduce the current output from
creating directory /home/postgres/v82/data ... ok
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I think this is unquestionably
>> a bug, at least for autovacuum's purposes --- though it might be OK
>> for the original intent of the stats system, which was simply to track
>> activity levels.
>>
>> Any thoughts about how it ought
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > This warning was added because of security considerations AFAIR. If the
> > intent is to make initdb super-quiet, we still have to have security in
> > mind. So if you want it to not say anything by default, instead of
> > throwing
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> This warning was added because of security considerations AFAIR. If the
> intent is to make initdb super-quiet, we still have to have security in
> mind. So if you want it to not say anything by default, instead of
> throwing a warning it should throw
Tom Lane wrote:
> I think this is the fault of the stats system design. AFAICT from a
> quick look at the code, inserted/updated/deleted tuples are reported
> to the collector in the same way regardless of whether the sending
> transaction committed or rolled back. I think this is unquestionably
Thomas Hallgren wrote:
> Tom Lane wrote:
> >
> >>I get a "WARNING: enabling "trust" authentication for local connections".
> >>Now this information *is* important. Unfortunately it's mixed in with
> >>all the rest unless I use a special redirect of stdout.
> >While we can probably all agree that
Tom Lane wrote:
I get a "WARNING: enabling "trust" authentication for local connections".
Now this information *is* important. Unfortunately it's mixed in with
all the rest unless I use a special redirect of stdout.
To apply your own argument, why is that important? Anyone with an
int
Those who don't use it will never see it.
It does however add more maintenance to the code.
Furthermore, it's quite unclear why you'd use pg_dump at all to
generate a data file that you intend to feed to some other program.
In my case, it's about being copy/paste friendly.
Davi
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> This is how I perceive the output from initdb:
> - The output lists settings for locale, encoding and buffer usage. Why
> are these specific settings be of special interest? Anyone with an
> interest in them knows where to find them anyway. This info
"Matthew T. O'Connor" writes:
>> Also, somebody made a real good point about rolled-back insertions.
>> Even if the only command you ever apply to the table is INSERT, you
>> could still have dead rows in the table if some of those transactions
>> occasionally roll back.
> hmm... That's true. I
David Fetter <[EMAIL PROTECTED]> writes:
> On Thu, Jan 26, 2006 at 10:17:05PM -0500, Tom Lane wrote:
>> Seems to me that "psql -c 'COPY ...'" is a more likely front-end for
>> such a process.
> Actually, it's not. I'm attaching my preliminary patch, as I see I
> haven't explained it well enough.
unsubscribe
Jim C. Nasby wrote:
On Thu, Jan 26, 2006 at 11:36:15AM +0100, Peter Eisentraut wrote:
James William Pye wrote:
Why should initdb give it [processing
information] to the user if the user didn't request it in the first
place?
Because it shows important information that we want the
27 matches
Mail list logo
