> email. The current patch is attached -- Tom hasn't yet gotten back to
> me on whether this fixes the problem for him on HPUX, but it fixes my
> OS X box.
Fixes issues under win32. Thanks.
Claudio
---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text
Tom Lane <[EMAIL PROTECTED]> wrote:
>
[snip]
>
> (I also see some post-7.4.1 changes in src/template/solaris, so you
> possibly should look there too.)
[snip]
>
I think I have the fix for part of it, but this remains...
gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
-Wmissing
Currently we need to read pg_control to know the location(LSN) of the
checkpoint record. This means if pg_control is lost or corrupted, we
have to give up the database recovery. I think we could start from the
first WAL segment and read through entire WAL logs to find out the
latest valid checkpoin
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am seeing the following regression failure for current CVS. On my OS,
> BSD/OS 4.3, it seems once you hit Infinity, you can't negate it.
> /usr/include/math.h has:
> /* Generate an overflow to create +Inf; the multiply shuts up gcc 1 */
>
Jan Wieck wrote:
> Bruce Momjian wrote:
>
> > Jan Wieck wrote:
> >> Greg Stark wrote:
> >>
> >> > Jan Wieck <[EMAIL PROTECTED]> writes:
> >> >
> >> >> the point is that PostgreSQL is no GNU product, never has been and if someone
> >> >> intends to he shall do so after yanking out the contributio
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am seeing the following regression failure for current CVS. On my
> OS, BSD/OS 4.3, it seems once you hit Infinity, you can't negate it.
Actually, I suspect the problem is that isinf() on your platform
returns 1 for any infinity (rather than -1 for ne
Bruce Momjian wrote:
Jan Wieck wrote:
Greg Stark wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
>
>> the point is that PostgreSQL is no GNU product, never has been and if someone
>> intends to he shall do so after yanking out the contributions I made.
>
> Note that when you released your contri
I am seeing the following regression failure for current CVS. On my OS,
BSD/OS 4.3, it seems once you hit Infinity, you can't negate it.
/usr/include/math.h has:
/* Generate an overflow to create +Inf; the multiply shuts up gcc 1 */
#define HUGE_VAL(1e250*1e250) /* IEEE
Jan Wieck wrote:
> Greg Stark wrote:
>
> > Jan Wieck <[EMAIL PROTECTED]> writes:
> >
> >> the point is that PostgreSQL is no GNU product, never has been and if someone
> >> intends to he shall do so after yanking out the contributions I made.
> >
> > Note that when you released your contribution
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Manfred Spraul wrote:
> Bruce Momjian wro
Greg Stark wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
the point is that PostgreSQL is no GNU product, never has been and if someone
intends to he shall do so after yanking out the contributions I made.
Note that when you released your contributions you did so under a license that
imposed no suc
Manfred Spraul wrote:
> Bruce Momjian wrote:
>
> >What killed the idea of doing ssl or kerberos locking inside libpq was
> >that there was no way to be sure that outside code didn't also access
> >those routines.
> >
> A callback based implementation can handle that: libpq has a default
> impleme
Merlin Moncure wrote:
> > > The problem with gprof is that I am going to see all the backend
> startup
> > > stuff too, no? Is there a way to get a dump just the run of the
> query?
> >
> > I was sort of lurking on this thread, waiting to see what became of
> it.
> > Did
> > nobody actually come
[EMAIL PROTECTED] (Jim Seymour) writes:
> Diff'ing thread.c between 7.4.1 and 7.4.2, it *looks* like, at first
> blush, nothing changed that should affect the relevant code.
> Anybody got any idea what's broken?
The relevant change is probably this one:
2004-02-11 12:32 momjian
* confi
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Looking at what we have, we know every table will get some inserts, and
> we know every insert will have to check the primary key. What we don't
> know is if there will be any modifications or deletes to the primary
> key.
Yeah. It's possible that the
Tom Lane wrote:
> While reviewing Fabien Coelho's patch for emitting warnings for slow
> foreign-key checks, it occurred to me that we aren't covering all bases.
> The patch as committed makes sure that there is a usable index on the
> referenced table, but it does not look for one on the referenci
While reviewing Fabien Coelho's patch for emitting warnings for slow
foreign-key checks, it occurred to me that we aren't covering all bases.
The patch as committed makes sure that there is a usable index on the
referenced table, but it does not look for one on the referencing table.
Failure to pro
Hi,
Environment:
SunOS 5.8 Generic_108528-27 sun4u sparc SUNW,Ultra-250
gcc version 3.3.1
PostgreSQL-7.4.2
./configure --with-java --enable-thread-safety
"make" results in:
gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
-Wmissing-declarations -fPIC -I. -I../../
Tom Lane wrote:
> I did take a look at the Apache rotator program, and found that it
> was probably more trouble to adopt than it's worth. It seemed to
> depend on a lot of configuration and library-routine infrastructure
> that we don't share.
Here's a log rotation program that does not share th
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Did anything ever come from this thread?
http://archives.postgresql.org/pgsql-hackers/2003-05/msg00603.php
(Heading: "Plan B for log rotation support: borrow Apache code")
Only an entry on my depressingly long personal to-do li
On Saturday 13 March 2004 01:00 pm, Fernando Nasser wrote:
> There are some applicatons which run in servers with very strict
> response times and any syscall, network packet that can be saved counts.
Ok, what about pipe overhead? If we're gong to split hairs, let's split all
of them. The desig
On Saturday 13 March 2004 10:36 am, Fernando Nasser wrote:
> The problem is that sysloging has more overhead than a plain append to a
> file. There are some very strict response time AppServer applications
> where we want to keep this things out of the picture.
Well, I have a couple of ideas on t
Patrick Welche wrote:
On Sat, Mar 13, 2004 at 10:36:23AM -0500, Fernando Nasser wrote:
Lamar Owen wrote:
Ok, riddle me this:
If I have PostgreSQL set to log to syslog facility LOCAL0, and a
local0.none on /var/log/messages and local0.* to /var/log/pgsql (assuming
only one postmaster, unfortuna
On Sat, Mar 13, 2004 at 10:36:23AM -0500, Fernando Nasser wrote:
> Lamar Owen wrote:
> >Ok, riddle me this:
> >
> >If I have PostgreSQL set to log to syslog facility LOCAL0, and a
> >local0.none on /var/log/messages and local0.* to /var/log/pgsql (assuming
> >only one postmaster, unfortunately) t
Rod Taylor wrote:
I can see that in a multipostmaster setting how you might want some
differentiation between postmasters, but ISTM that the tool reading these
logs should be trained in how to separate loglines out.
Different postmasters = different conf files. Just set your syslog_facility
and/o
Robert Treat wrote:
Different postmasters = different conf files. Just set your syslog_facility
and/or your syslog_ident differently and it should be pretty easy to seperate
the logs. Actually, now that I have started using syslog fairly regularly, I
find it hard to believe it would be worth th
> > I can see that in a multipostmaster setting how you might want some
> > differentiation between postmasters, but ISTM that the tool reading these
> > logs should be trained in how to separate loglines out.
>
> Different postmasters = different conf files. Just set your syslog_facility
> and/
Lamar Owen wrote:
Anyway, Syslog is not an option for us. We need flat files.
Ok, riddle me this:
If I have PostgreSQL set to log to syslog facility LOCAL0, and a local0.none
on /var/log/messages and local0.* to /var/log/pgsql (assuming only one
postmaster, unfortunately) then you get a flat
Bruno Wolff III wrote:
On Fri, Mar 12, 2004 at 15:19:29 -0500,
Fernando Nasser <[EMAIL PROTECTED]> wrote:
Bruno Wolff III wrote:
I can see their problem with making a dependency to all of apache or
including
multilog in their distribution. But they probably could include something
that is only
On Saturday 13 March 2004 09:36, Lamar Owen wrote:
> On Friday 12 March 2004 03:21 pm, Fernando Nasser wrote:
> > Lamar Owen wrote:
> > > Uh, we have many many many different ways to use syslog. So my other
> > > message on the topic.
> >
> > Which other message?
>
> The one I didn't post. :-)
>
>
On Friday 12 March 2004 03:21 pm, Fernando Nasser wrote:
> Lamar Owen wrote:
> > Uh, we have many many many different ways to use syslog. So my other
> > message on the topic.
> Which other message?
The one I didn't post. :-)
> Anyway, Syslog is not an option for us. We need flat files.
Ok, r
31 matches
Mail list logo
