Failed to build on Solaris.
Summary
1. Checking for pstat... no
2. Regression Failur stats . FAILED .
3. Not running stats buffer process and stats collector process.
Environments
SunOS 5.8 Generic_108528-15 sun4m sparc
SunOS 5.8 Generic_108
On Tuesday 11 November 2003 00:50, Neil Conway wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > We can't resize shared memory because we allocate the whole thing in
> > one big hump - which causes the shmmax problem BTW. If we allocate
> > that in chunks of multiple blocks, we only have to give i
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> Are there further concerns with this patch?
>
> > No, just getting to it now. Sorry.
>
> Peter didn't agree with this patch, and I have to concur with him
> that the need for it is unproven.
>
> Given that it is certainly not goin
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Are there further concerns with this patch?
> No, just getting to it now. Sorry.
Peter didn't agree with this patch, and I have to concur with him
that the need for it is unproven.
Given that it is certainly not going into 7.4 at this late date,
I th
You need bison 1.875.
---
strk wrote:
> I can't build postgresql from CVS. Any help ?
> This is the message I get:
>
> bison -y -d preproc.y
> preproc.y:6275: fatal error: maximum table size (32767) exceeded
>
Is the problem with backing up and restoring a database which has tsearch2
installed and enabled delt with in Version 7.4 of PostgreSQL?
If it's the problem with restoring the tsearch2-related functions, then no,
and I'm not sure whether it's "fixable" (in the sense that a tsearch2 enabled
datab
> Jan Wieck wrote:
> > What bothers me a little is that you keep telling us that you have all
> > that great code from SRA. Do you have any idea when they intend to share
> > this with us and contribute the stuff? I mean at least some pieces
> > maybe? You personally got all the code from NuSphe
We have just packaged up our second Release Candidate for v7.4, with the
hopes of producing a full release next week.
A full ChangeLog is available at:
ftp://ftp.postgresql.org/pub/sources/v7.4/ChangeLog.RC1.to.RC2
But, one of the highlights is that support for tcl8.0.x has been
re-int
Andrew Sullivan wrote:
On Sun, Nov 09, 2003 at 08:54:25PM -0800, Joe Conway wrote:
two servers, mounted to the same data volume, and some kind of
coordination between the writer processes. Anyone know if this is
similar to how Oracle handles RAC?
It is similar, yes, but there's some mighty power
No, just getting to it now. Sorry.
---
Michael Mauger wrote:
> --- Michael Mauger <[EMAIL PROTECTED]> wrote:
> > --- Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> > > Michael Mauger writes:
> > > >
> > > > Emacs is not a Cy
Jan Wieck wrote:
> Bruce Momjian wrote:
>
> > Jan Wieck wrote:
> >> Zeugswetter Andreas SB SD wrote:
> >>
> >> >> > One problem with O_SYNC would be, that the OS does not group writes any
> >> >> > more. So the code would need to eighter do it's own sorting and grouping
> >> >> > (256k) or use a
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Joe, do you recall the reasoning for this code in parse_coerce.c?
>> [much snipped]
> Does the RelabelType keep a record of what was relabeled (I presume from
> your description above it does)?
The RelabelType node itself doesn't, but y
OK, release notes updated to:
Allow polymorphic PL/pgSQL functions (Tom, Joe)
Allow polymorphic SQL functions (Joe)
Allow functions to accept arbitrary data types for input, and return arbitrary
types.
---
Jan Wieck wrote:
> Bruce Momjian wrote:
>
> > Jan Wieck wrote:
> >> >> > If the background cleaner has to not just write() but write/fsync or
> >> >> > write/O_SYNC, it isn't going to be able to clean them fast enough. It
> >> >> > creates a bottleneck where we didn't have one before.
> >> >> >
On Monday 10 November 2003 20:47, Ed Baer wrote:
> To whom it may concern,
>
> Please accept my apology if this is not the correct forum, I am new and was
> unable to find the correct location to send this question.
>
> If you don't wish to answer, could you please direct me to the correct
> place
strk writes:
> I can't build postgresql from CVS. Any help ?
Search the fine archives.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister Yo
I can't build postgresql from CVS. Any help ?
This is the message I get:
bison -y -d preproc.y
preproc.y:6275: fatal error: maximum table size (32767) exceeded
Bison version:
bison (GNU Bison) 1.35
TIA
.strk;
--
pallamondo.net <-- take a look !
Tom Lane wrote:
Joe, do you recall the reasoning for this code in parse_coerce.c?
if (targetTypeId == ANYOID ||
targetTypeId == ANYARRAYOID ||
targetTypeId == ANYELEMENTOID)
{
/* assume can_coerce_type verified that implicit coercion is okay */
/* NB: we do
Bruce Momjian wrote:
Jan Wieck wrote:
>> > If the background cleaner has to not just write() but write/fsync or
>> > write/O_SYNC, it isn't going to be able to clean them fast enough. It
>> > creates a bottleneck where we didn't have one before.
>> >
>> > We are trying to eliminate an I/O storm
Bruce Momjian wrote:
Jan Wieck wrote:
Zeugswetter Andreas SB SD wrote:
>> > One problem with O_SYNC would be, that the OS does not group writes any
>> > more. So the code would need to eighter do it's own sorting and grouping
>> > (256k) or use aio, or you won't be able to get the maximum out of
To whom it may concern,
Please accept my apology if this is not the correct forum, I am new and was unable to
find the correct location to send this question.
If you don't wish to answer, could you please direct me to the correct place to ask
the question.
Thanks
The question is:
Is the prob
--- Michael Mauger <[EMAIL PROTECTED]> wrote:
> --- Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> > Michael Mauger writes:
> > >
> > > Emacs is not a Cygwin (Un*x emulation on Windows) executable (like
> > > psql is)
> >
> > Why don't you use the native Windows version of psql?
> >
>
> The Cygwi
Neil Conway wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Another idea --- if fsync() is slow because it can't find the dirty
> > buffers, use write() to write the buffers, copy the buffer to local
> > memory, mark it as clean, then open the file with O_SYNC and write
> > it again.
>
> Yu
On Mon, Nov 10, 2003 at 10:50:30AM -0500, Tom Lane wrote:
> I looked over it, and the only part that seems odd is that you seem to
> have removed the type info caching behavior in execute.c. Is that
> intended? It looks like ECPGis_type_an_array() will now issue a query
Well actually no. I remov
On Mon, 10 Nov 2003, Gaetano Mendola wrote:
> Marc G. Fournier wrote:
>
> > 'k, this doesn't look right, but it could be that I'm overlooking
> > something ...
> >
> > The function I created:
> >
> > CREATE FUNCTION month_trunc (timestamp without time zone) RETURNS timestamp
> > without time zo
Joe, do you recall the reasoning for this code in parse_coerce.c?
if (targetTypeId == ANYOID ||
targetTypeId == ANYARRAYOID ||
targetTypeId == ANYELEMENTOID)
{
/* assume can_coerce_type verified that implicit coercion is okay */
/* NB: we do NOT want a Relab
Marc G. Fournier wrote:
'k, this doesn't look right, but it could be that I'm overlooking
something ...
The function I created:
CREATE FUNCTION month_trunc (timestamp without time zone) RETURNS timestamp without
time zone
AS 'SELECT date_trunc(''month'', $1 )'
LANGUAGE sql IMMUTABLE;
The q
Marc G. Fournier wrote:
'k, this doesn't look right, but it could be that I'm overlooking
something ...
The function I created:
CREATE FUNCTION month_trunc (timestamp without time zone) RETURNS timestamp without
time zone
AS 'SELECT date_trunc(''month'', $1 )'
LANGUAGE sql IMMUTABLE;
The
'k, this doesn't look right, but it could be that I'm overlooking
something ...
The function I created:
CREATE FUNCTION month_trunc (timestamp without time zone) RETURNS timestamp without
time zone
AS 'SELECT date_trunc(''month'', $1 )'
LANGUAGE sql IMMUTABLE;
The query that fails:
a
Jan Wieck wrote:
> >> > If the background cleaner has to not just write() but write/fsync or
> >> > write/O_SYNC, it isn't going to be able to clean them fast enough. It
> >> > creates a bottleneck where we didn't have one before.
> >> >
> >> > We are trying to eliminate an I/O storm during check
Bruce Momjian wrote:
Jan Wieck wrote:
Bruce Momjian wrote:
> Jan Wieck wrote:
>> Bruce Momjian wrote:
>>
>> > Now, O_SYNC is going to force every write to the disk. If we have a
>> > transaction that has to write lots of buffers (has to write them to
>> > reuse the shared buffer)
>>
>> So make
Neil Conway wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Another idea --- if fsync() is slow because it can't find the dirty
> > buffers, use write() to write the buffers, copy the buffer to local
> > memory, mark it as clean, then open the file with O_SYNC and write
> > it again.
>
> Yu
Jan Wieck <[EMAIL PROTECTED]> writes:
> We can't resize shared memory because we allocate the whole thing in
> one big hump - which causes the shmmax problem BTW. If we allocate
> that in chunks of multiple blocks, we only have to give it a total
> maximum size to get the hash tables and other stuf
Jan Wieck wrote:
> Zeugswetter Andreas SB SD wrote:
>
> >> > One problem with O_SYNC would be, that the OS does not group writes any
> >> > more. So the code would need to eighter do it's own sorting and grouping
> >> > (256k) or use aio, or you won't be able to get the maximum out of the disks.
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Another idea --- if fsync() is slow because it can't find the dirty
> buffers, use write() to write the buffers, copy the buffer to local
> memory, mark it as clean, then open the file with O_SYNC and write
> it again.
Yuck.
Do we have any idea how many
On Fri, 2003-11-07 at 18:37, Andrew Dunstan wrote:
> Robert Treat wrote:
> >On Fri, 2003-11-07 at 15:28, Andrew Dunstan wrote:
> >>Marc G. Fournier wrote:
> >>>On Fri, 7 Nov 2003, Robert Treat wrote:
> I know most people have talked about using bugzilla, but is anyone
> familiar with GNATS?
--On Monday, November 10, 2003 13:40:24 -0500 Neil Conway
<[EMAIL PROTECTED]> wrote:
Larry Rosenman <[EMAIL PROTECTED]> writes:
You might also look at Veritas' advisory stuff.
Thanks for the suggestion -- it looks like we can make use of
this. For the curious, the cache advisory API is document
Tom Lane wrote:
> "Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> > One problem with O_SYNC would be, that the OS does not group writes any
> > more. So the code would need to eighter do it's own sorting and grouping
> > (256k) or use aio, or you won't be able to get the maximum out of t
In fact: http://oosurvey.gratismania.ro/stats
On Mon, 10 Nov 2003, Marc G. Fournier wrote:
>
>
> On Mon, 10 Nov 2003, Josh Berkus wrote:
>
> > Justin,
> >
> > > From memory, the OpenOffice.org surveys still run from the techdocs
> > > virtual machine too. That may or may not be the case these
Jan Wieck wrote:
> Bruce Momjian wrote:
>
> > Jan Wieck wrote:
> >> Bruce Momjian wrote:
> >> > I would be interested to know if you have the background write process
> >> > writing old dirty buffers to kernel buffers continually if the sync()
> >> > load is diminished. What this does is to push
Jan Wieck wrote:
> Bruce Momjian wrote:
>
> > Jan Wieck wrote:
> >> Bruce Momjian wrote:
> >>
> >> > Now, O_SYNC is going to force every write to the disk. If we have a
> >> > transaction that has to write lots of buffers (has to write them to
> >> > reuse the shared buffer)
> >>
> >> So make t
Jan Wieck wrote:
> > If the background cleaner has to not just write() but write/fsync or
> > write/O_SYNC, it isn't going to be able to clean them fast enough. It
> > creates a bottleneck where we didn't have one before.
> >
> > We are trying to eliminate an I/O storm during checkpoint, but the
<[EMAIL PROTECTED]> writes:
> I am trying to catch the "UPDATE 0" condition in postgresql.
> I have tried it using triggers, but they are only fired when there
> effectively is an update.
You could try using an AFTER STATEMENT trigger (which will be invoked
even if zero rows are updated), and chec
Jan Wieck wrote:
> Bruce Momjian wrote:
>
> > Tom Lane wrote:
> >> Andrew Sullivan <[EMAIL PROTECTED]> writes:
> >> > On Sun, Nov 02, 2003 at 01:00:35PM -0500, Tom Lane wrote:
> >> >> real traction we'd have to go back to the "take over most of RAM for
> >> >> shared buffers" approach, which we al
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Now, if we are sure that writes will happen only in the checkpoint
> > process, O_SYNC would be OK, I guess, but will we ever be sure of that?
>
> This is a performance issue, not a correctness issue. It's okay for
> backends to wait
On Sun, Nov 09, 2003 at 08:54:25PM -0800, Joe Conway wrote:
> two servers, mounted to the same data volume, and some kind of
> coordination between the writer processes. Anyone know if this is
> similar to how Oracle handles RAC?
It is similar, yes, but there's some mighty powerful magic in that
Jan Wieck wrote:
> What bothers me a little is that you keep telling us that you have all
> that great code from SRA. Do you have any idea when they intend to share
> this with us and contribute the stuff? I mean at least some pieces
> maybe? You personally got all the code from NuSphere AKA Pee
Larry Rosenman <[EMAIL PROTECTED]> writes:
> You might also look at Veritas' advisory stuff.
Thanks for the suggestion -- it looks like we can make use of
this. For the curious, the cache advisory API is documented here:
http://www.lerctr.org:8458/en/man/html.7/vxfsio.7.html
http://www.lerctr.org
On Mon, 10 Nov 2003, Josh Berkus wrote:
> Justin,
>
> > From memory, the OpenOffice.org surveys still run from the techdocs
> > virtual machine too. That may or may not be the case these days, I just
> > don't remember.
>
> Really? I thought that they were running from one of Sun's machines.
Justin,
> From memory, the OpenOffice.org surveys still run from the techdocs
> virtual machine too. That may or may not be the case these days, I just
> don't remember.
Really? I thought that they were running from one of Sun's machines. Will
check with Cristian.
If we're hosting the
Zeugswetter Andreas SB SD wrote:
> One problem with O_SYNC would be, that the OS does not group writes any
> more. So the code would need to eighter do it's own sorting and grouping
> (256k) or use aio, or you won't be able to get the maximum out of the disks.
Or just run multiple writer process
--On Monday, November 10, 2003 11:40:45 -0500 Neil Conway
<[EMAIL PROTECTED]> wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Now, the disadvantages of large kernel cache, small PostgreSQL buffer
cache is that data has to be transfered to/from the kernel buffers, and
second, we can't control t
Anthony W. Youngman kirjutas K, 05.11.2003 kell 01:15:
> >1) Your database might change over time and say a table that originally
> >had only a few rows
> >could suddenty grow considerably. Now an optimiser would insulate you
> >from these changes
> >or in the worst case all that would need to b
Hello,
I am trying to catch the "UPDATE 0" condition in postgresql.
I have tried it using triggers, but they are only fired when there
effectively is an update. So, an Update 0 does not fire triggers.
Is it possible to make the backend raise and exception when the
Update 0 happens? This would be us
> > One problem with O_SYNC would be, that the OS does not group writes any
> > more. So the code would need to eighter do it's own sorting and grouping
> > (256k) or use aio, or you won't be able to get the maximum out of the disks.
>
> Or just run multiple writer processes, which I believe is
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Now, the disadvantages of large kernel cache, small PostgreSQL buffer
> cache is that data has to be transfered to/from the kernel buffers, and
> second, we can't control the kernel's cache replacement strategy, and
> will probably not be able to in the n
On Sun, 9 Nov 2003, Jan Wieck wrote:
> scott.marlowe wrote:
>
> > On Fri, 7 Nov 2003, Matthew T. O'Connor wrote:
> >
> >> - Original Message -
> >> From: "Jan Wieck" <[EMAIL PROTECTED]>
> >> > Tom Lane wrote:
> >> > > Gaetano and a couple of other people did experiments that seemed to s
[EMAIL PROTECTED] wrote:
Hi,
I am Suchindra Katageri and am working as a Software Engineer at
Linuxlabs, Atlanta, GA.
I am presently working on developing libraries to make postgresql
run on a cluster. I was wondering if it was possible to force Database
writes to stable storage, without m
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> writes:
> One problem with O_SYNC would be, that the OS does not group writes any
> more. So the code would need to eighter do it's own sorting and grouping
> (256k) or use aio, or you won't be able to get the maximum out of the disks.
Or just run m
> that works well enough to make it uncommon for backends to have to
> write dirty buffers for themselves. If we can, then doing all the
> writes O_SYNC would not be a problem.
One problem with O_SYNC would be, that the OS does not group writes any
more. So the code would need to eighter do it'
Michael Meskes <[EMAIL PROTECTED]> writes:
> I just fixed a bug in ecpglib that caused it to misbehave for all
> internal array/vector types. They were treated like the external ones.
> So ecpg expected them to be listed as '{...}' which surely failed.
> However, this bug fix involves more code ch
On Mon, 10 Nov 2003, Robert Treat wrote:
> On Fri, 2003-11-07 at 13:51, Josh Berkus wrote:
> > > really the most important thing here is that we get some movement on the
> > > site in order to ditch the old VM the site lives on and get it on our new
> > > web VM.
> >
> > On techdocs? What part
I just
installed kylix3 and had a problem when try to connect PostgreSQLI use
SQLConnection to connect with PostgreSQLwhen I set property connection to
true it causean error "unable to load libsqlpg.so"can anyone help
me?thanxwelly
On Fri, 2003-11-07 at 13:51, Josh Berkus wrote:
> > really the most important thing here is that we get some movement on the
> > site in order to ditch the old VM the site lives on and get it on our new
> > web VM.
>
> On techdocs? What part of that needs to be migrated?
>
Last I check it was
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Now, if we are sure that writes will happen only in the checkpoint
process, O_SYNC would be OK, I guess, but will we ever be sure of that?
This is a performance issue, not a correctness issue. It's okay for
backends to wait for writes as l
Bruce Momjian wrote:
Jan Wieck wrote:
Bruce Momjian wrote:
> I would be interested to know if you have the background write process
> writing old dirty buffers to kernel buffers continually if the sync()
> load is diminished. What this does is to push more dirty buffers into
> the kernel cache in
Bruce Momjian wrote:
Jan Wieck wrote:
Bruce Momjian wrote:
> Now, O_SYNC is going to force every write to the disk. If we have a
> transaction that has to write lots of buffers (has to write them to
> reuse the shared buffer)
So make the background writer/checkpointer keeping the LRU head clean.
Should be on the mirrors now, will announce it this evening ... things
looked to build clean, just would like a second opinion on it ...
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresq
Bruce Momjian wrote:
Tom Lane wrote:
Andrew Sullivan <[EMAIL PROTECTED]> writes:
> On Sun, Nov 02, 2003 at 01:00:35PM -0500, Tom Lane wrote:
>> real traction we'd have to go back to the "take over most of RAM for
>> shared buffers" approach, which we already know to have a bunch of
>> severe disad
What bothers me a little is that you keep telling us that you have all
that great code from SRA. Do you have any idea when they intend to share
this with us and contribute the stuff? I mean at least some pieces
maybe? You personally got all the code from NuSphere AKA PeerDirect even
weeks befor
Jan Wieck wrote:
> Bruce Momjian wrote:
> > I would be interested to know if you have the background write process
> > writing old dirty buffers to kernel buffers continually if the sync()
> > load is diminished. What this does is to push more dirty buffers into
> > the kernel cache in hopes the O
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Now, if we are sure that writes will happen only in the checkpoint
> process, O_SYNC would be OK, I guess, but will we ever be sure of that?
This is a performance issue, not a correctness issue. It's okay for
backends to wait for writes as long as it ha
Jan Wieck wrote:
> Bruce Momjian wrote:
>
> > Now, O_SYNC is going to force every write to the disk. If we have a
> > transaction that has to write lots of buffers (has to write them to
> > reuse the shared buffer)
>
> So make the background writer/checkpointer keeping the LRU head clean. I
> e
Andriy Tkachuk <[EMAIL PROTECTED]> writes:
> On Fri, 7 Nov 2003, Tom Lane wrote:
>> Andriy Tkachuk <[EMAIL PROTECTED]> writes:
>>> Nov 5 20:22:42 monstr postgres[16071]: [3] PANIC: open of
>>> /usr/local/pgsql/data/pg_clog/0040 failed: No such file or directory
>>
>> Could we see ls -l /usr/loc
Bruce Momjian wrote:
Now, O_SYNC is going to force every write to the disk. If we have a
transaction that has to write lots of buffers (has to write them to
reuse the shared buffer)
So make the background writer/checkpointer keeping the LRU head clean. I
explained that 3 times now.
Jan
--
#===
Bruce Momjian wrote:
I would be interested to know if you have the background write process
writing old dirty buffers to kernel buffers continually if the sync()
load is diminished. What this does is to push more dirty buffers into
the kernel cache in hopes the OS will write those buffers on its o
you could put a view on every table that called a function?
Maybe, but how can i retrieve the select statement
_
MSN 8 with e-mail virus protection service: 2 months FREE*
http://join.msn.com/?page=features/virus
---
shure, Tom
[10:49]/2:[EMAIL PROTECTED]:~>sudo ls -al /usr/local/pgsql/data/pg_clog
total 40
drwx--2 pgsqlpostgres 4096 Nov 7 03:28 .
drwx--6 pgsqlroot 4096 Oct 23 10:45 ..
-rw---1 pgsqlpostgres32768 Nov 10 10:47 000D
[10:49]/2:[EMAIL PROTECTED]
78 matches
Mail list logo
