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 P
"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 broadcast)-
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
---
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 broadc
-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
"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 wo
-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
-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 f
"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-bran
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 anymo
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,
J
Tom Lane wrote:
[EMAIL PROTECTED] (Marc G. Fournier) writes:
configure (r1.570 -> r1.571)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/configure?r1=1.570&r2=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
-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 PROT
"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.
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
-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
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 convenie
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 7
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.
re
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,
"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
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
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:
http://pgbuildfarm.org/cgi-bin/show_histo
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=narwhal&br=HEAD
> and t
-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 Th
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=narwhal&br=HEAD
and the next build is 2 hours later.
Regards,
--
Devrim GÜNDÜZ ,
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
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)--
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 yo
-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 recomme
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_c
-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 co
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/
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
"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 chec
> 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
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
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 would
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 seem
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
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 f
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. Tr
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
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
se
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
u
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
http://developer.post
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:
[EISDIR]
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
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 star
49 matches
Mail list logo
