Jignesh K. Shah wrote:
Since its really writes that I am having trouble.. the auto vacuum
message tells me 11 pages were removed and so many tuples were
removed.. I am guessing its writes.
Do you keep track of I/O to WAL and data separately? WAL bandwidth will
spike up when a checkpoint
Tom Lane wrote:
Looking at the autovacuum log output,
2007-11-13 09:21:19.830 PST 9458 LOG: automatic vacuum of table
specdb.public.txn_log_table: index scans: 1
pages: 11 removed, 105 remain
tuples: 3147 removed, 40 remain
system usage: CPU 0.11s/0.09u sec elapsed
Martijn van Oosterhout napsal(a):
On Wed, Nov 14, 2007 at 09:33:17PM +0100, Zdenek Kotala wrote:
Sure, why not. To be honest I think that psql shouldn't be ignoring the
EISDIR error the kernel is returning.
But it works when you open directory in read-only mode. See posix
definition:
Am Mittwoch, 14. November 2007 schrieb Martijn van Oosterhout:
It's not the fopen that fails, it's the fgets that returns NULL. We
don't subsequently check if that's due to an I/O error or EISDIR or if
it's an end-of-file.
Here is a patch for this.
--
Peter Eisentraut
Am Mittwoch, 14. November 2007 schrieb Trevor Talbot:
But that coversion itself is fundamentally flawed, is the problem.
I know it's incorrect, but with a different parser and/or dictionary you could
make it work.
In practice, the search pattern will mostly be provided dynamically from some
Yes I separate out as follows:
PGDATA + 1 TABLE which needs to be cached (also workaround CLOG read
problem)
LOGS
DATABASE TABLES
DATABASE INDEX
to get a good view of IOs out
I have full_page_writes=off in my settings
I dont see spikes of increase on WAL during checkpoints (maybe due to my
On 11/15/07, Peter Eisentraut [EMAIL PROTECTED] wrote:
In practice, the search pattern will mostly be provided dynamically from some
user input, so you could conceivably be able to modify the search patterns
more readily than the entire queries in your application. Anyway, it's just
an idea
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Mittwoch, 14. November 2007 schrieb Trevor Talbot:
But that coversion itself is fundamentally flawed, is the problem.
I know it's incorrect, but with a different parser and/or dictionary you
could
make it work.
No, I don't think so. Trevor's
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Mittwoch, 14. November 2007 schrieb Martijn van Oosterhout:
It's not the fopen that fails, it's the fgets that returns NULL. We
don't subsequently check if that's due to an I/O error or EISDIR or if
it's an end-of-file.
Here is a patch for this.
Am Donnerstag, 15. November 2007 schrieb Tom Lane:
This seems too far removed from the scene of the crime
Yeah, my zeroth attempt was to place this in gets_fromFile(), but there you
don't have any opportunity to report failure to the main loop. We'd need to
change the function signature to be
Tom Lane wrote:
2007-11-13 09:21:19.830 PST 9458 LOG: automatic vacuum of table
specdb.public.txn_log_table: index scans: 1
pages: 11 removed, 105 remain
tuples: 3147 removed, 40 remain
system usage: CPU 0.11s/0.09u sec elapsed 6.02 sec
it seems like a
Any last-minute fixes out there?
With luck this will be the last beta --- we are thinking RC1 in about
two weeks and final in early December, if no showstopper bugs are
reported. So get out there and test it ...
I will not have time to fix the default TS parser before then. There's a
Jignesh K. Shah [EMAIL PROTECTED] writes:
I will turn on checkpoint_logging to get more idea as Heikki suggested
Did you find out anything?
Did this happen on every checkpoint, or only some of them? The bug
Itagaki-san pointed out today in IsCheckpointOnSchedule might account
for some
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
it seems like a serious omission that this gives you no hint how many
pages were scanned.
Hmm, right. I'm not sure how to fix it; the simplest idea is to count
the number of heap page accesses in lazy_scan_heap, but this wouldn't
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
it seems like a serious omission that this gives you no hint how many
pages were scanned.
Too complex for my taste, anyway. I would be satisfied if the log
entries just indicated how big the table and indexes
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Donnerstag, 15. November 2007 schrieb Tom Lane:
This seems too far removed from the scene of the crime
Yeah, my zeroth attempt was to place this in gets_fromFile(), but there you
don't have any opportunity to report failure to the main loop.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 15 Nov 2007 21:58:28 +0100
Peter Eisentraut [EMAIL PROTECTED] wrote:
Do we care to maintain a maximum width for programs' --help output
(and psql's \?)? I think 79 characters was once a recommendation (or
perhaps 72), but we have a couple
Peter Eisentraut wrote:
Do we care to maintain a maximum width for programs' --help output (and
psql's
\?)? I think 79 characters was once a recommendation (or perhaps 72), but we
have a couple of violations either way, which I'd like to fix, but what to?
Yea, I went over with the pg_ctl
Do we care to maintain a maximum width for programs' --help output (and psql's
\?)? I think 79 characters was once a recommendation (or perhaps 72), but we
have a couple of violations either way, which I'd like to fix, but what to?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 15 Nov 2007 16:04:46 -0500
Tom Lane [EMAIL PROTECTED] wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Do we care to maintain a maximum width for programs' --help output
(and psql's \?)? I think 79 characters was once a recommendation
Dave Page [EMAIL PROTECTED] writes:
hold the presses...
Narwhal just broke :-(
Grumble ... looks like we have to use ftruncate to keep Windows
happy. Will fix.
regards, tom lane
---(end of broadcast)---
TIP 4: Have you
Alvaro Herrera [EMAIL PROTECTED] writes:
Also it would rock if translation kept the alignment in various output.
Theoretically the translators are supposed to do that already ...
regards, tom lane
---(end of broadcast)---
Tom Lane wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
Let me know when ready to proceed ...
I just fixed a second bug in that patch :-(
But I think we're good to go now.
Note that none of the version-stamping has been done yet.
Right, I believe only Marc does that. I have never
Joshua D. Drake [EMAIL PROTECTED] writes:
Since we are waiting anyway, something I brought up to Dave about this
exact problem was the idea of a freeze :). E.g; All animals must go
green and stay green with zero additional commits for 24 hours before
we wrap.
Is that something that sounds
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
'k, then I'd say let's wait ... I'll aim for 00:00 AST to do the build, which
gives ~2.25hrs from now, which should be loads of time, right?
- --On Thursday, November 15, 2007 17:35:32 -0800 Devrim GÜNDÜZ
[EMAIL PROTECTED] wrote:
Hi,
On Thu,
Bruce Momjian wrote:
Peter Eisentraut wrote:
Do we care to maintain a maximum width for programs' --help output (and psql's
\?)? I think 79 characters was once a recommendation (or perhaps 72), but we
have a couple of violations either way, which I'd like to fix, but what to?
Yea,
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= [EMAIL PROTECTED] writes:
On Thu, 2007-11-15 at 21:26 -0400, Marc G. Fournier wrote:
Any idea on how often narwhal will do a build?
It looks that it builds -HEAD every 6 hours:
http://pgbuildfarm.org/cgi-bin/show_history.pl?nm=narwhalbr=HEAD
and the next
Hi,
On Thu, 2007-11-15 at 21:26 -0400, Marc G. Fournier wrote:
Any idea on how often narwhal will do a build?
It looks that it builds -HEAD every 6 hours:
http://pgbuildfarm.org/cgi-bin/show_history.pl?nm=narwhalbr=HEAD
and the next build is 2 hours later.
Regards,
--
Devrim GÜNDÜZ ,
Tom Lane wrote:
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= [EMAIL PROTECTED] writes:
On Thu, 2007-11-15 at 21:26 -0400, Marc G. Fournier wrote:
Any idea on how often narwhal will do a build?
It looks that it builds -HEAD every 6 hours:
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Jignesh K. Shah wrote:
I changed CLOG Buffers to 16
Running the test again:
# ./read.d
dtrace: script
Peter Eisentraut [EMAIL PROTECTED] writes:
Do we care to maintain a maximum width for programs' --help output (and
psql's
\?)? I think 79 characters was once a recommendation (or perhaps 72), but we
have a couple of violations either way, which I'd like to fix, but what to?
I think 79 is
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I already asked Dave if he could force a rebuild from home, no go :-(
I will force one in a few minutes.
narwhal and dawn_bat are both showing green, so I think we're ready to
wrap at Marc's convenience.
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
I already asked Dave if he could force a rebuild from home, no go :-(
I will force one in a few minutes.
narwhal and dawn_bat are both showing green, so I think we're ready to
wrap at Marc's convenience.
Agreed.
Peter Eisentraut wrote:
Do we care to maintain a maximum width for programs' --help output (and
psql's
\?)? I think 79 characters was once a recommendation (or perhaps 72), but we
have a couple of violations either way, which I'd like to fix, but what to?
79 is perfect IMHO. It would be
Marc G. Fournier [EMAIL PROTECTED] writes:
Let me know when ready to proceed ...
I just fixed a second bug in that patch :-(
But I think we're good to go now.
Note that none of the version-stamping has been done yet.
Also, I'm not sure where Bruce is with his pgindent stuff.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Let me know when ready to proceed ...
- --On Thursday, November 15, 2007 16:30:00 -0500 Tom Lane [EMAIL PROTECTED]
wrote:
Dave Page [EMAIL PROTECTED] writes:
hold the presses...
Narwhal just broke :-(
Grumble ... looks like we have to use
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
'k, 2.59 isn't even available in FreeBSD ports anymore, only 2.13 and 2.61, so
can someone else please run autoconf and commit, and I'll re-tag ...
- --On Thursday, November 15, 2007 23:37:22 -0500 Tom Lane [EMAIL PROTECTED]
wrote:
[EMAIL
Tom Lane wrote:
[EMAIL PROTECTED] (Marc G. Fournier) writes:
configure (r1.570 - r1.571)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/configure?r1=1.570r2=1.571)
It appears that Marc has got autoconf 2.61 installed now, instead of the
2.59 that we've been using for some
Marc G. Fournier wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
'k, 2.59 isn't even available in FreeBSD ports anymore, only 2.13 and 2.61, so
can someone else please run autoconf and commit, and I'll re-tag ...
I can't commit but I can give access to a 2.59 version...
Sincerely,
Marc G. Fournier wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Thursday, November 15, 2007 20:49:04 -0800 Joshua D. Drake
[EMAIL PROTECTED] wrote:
Marc G. Fournier wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
'k, 2.59 isn't even available in FreeBSD ports anymore,
Marc G. Fournier [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
I can't commit but I can give access to a 2.59 version...
Well, easiest is for Tom to run autoconf 2.59 and commit ... or Bruce ...
Locally I've got several autoconf versions installed so that I can
update back-branch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Thursday, November 15, 2007 21:21:59 -0800 Joshua D. Drake
[EMAIL PROTECTED] wrote:
Marc G. Fournier wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
That would be a good idea, and really simply things ... FreeBSD seems to
have
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Friday, November 16, 2007 00:03:46 -0500 Tom Lane [EMAIL PROTECTED]
wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
I can't commit but I can give access to a 2.59 version...
Well, easiest is for Tom to run
Marc G. Fournier [EMAIL PROTECTED] writes:
- --On Friday, November 16, 2007 00:03:46 -0500 Tom Lane [EMAIL PROTECTED]
wrote:
Either that or we try to move up all supported back branches to the
latest autoconf version; which might be a good idea but it scares me
a bit.
That would be a good
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Friday, November 16, 2007 00:40:31 -0500 Tom Lane [EMAIL PROTECTED]
wrote:
Marc G. Fournier [EMAIL PROTECTED] writes:
- --On Friday, November 16, 2007 00:03:46 -0500 Tom Lane [EMAIL PROTECTED]
wrote:
Either that or we try to move up all
Any last-minute fixes out there?
With luck this will be the last beta --- we are thinking RC1 in about
two weeks and final in early December, if no showstopper bugs are
reported. So get out there and test it ...
regards, tom lane
---(end of
Hi,
In GiST, I found that after the crash recovery, NSN and right page link
are initialized. We can search all the records in this case but
performance may become a little worse because we cannot traverse leaves.
I'm not sure if it is preffered behavior.
--
Koichi Suzuki
Marc G. Fournier [EMAIL PROTECTED] writes:
'k, 2.59 isn't even available in FreeBSD ports anymore, only 2.13 and 2.61,
so
can someone else please run autoconf and commit, and I'll re-tag ...
Done
regards, tom lane
---(end of
hold the presses...
Narwhal just broke :-(
Original Message
Subject: PGBuildfarm member narwhal Branch HEAD Status changed from OK
to Make failure
Date: Thu, 15 Nov 2007 13:23:06 -0800 (PST)
From: PG Build Farm [EMAIL PROTECTED]
To: [EMAIL PROTECTED],
[EMAIL PROTECTED]
The
49 matches
Mail list logo
