Re: [PATCHES] [HACKERS] regressin failure on latest CVS
I think the patch is ok now, intervall is not failing anymore as of 18:50 CET. However stats fails. regression.diffs: *** ./expected/stats.outSat Jul 23 17:18:20 2005 --- ./results/stats.out Sat Jul 23 18:55:17 2005 *** *** 53,59 WHERE st.relname='tenk2' AND cl.relname='tenk2'; ?column? | ?column? | ?column? | ?column? --+--+--+-- ! t| t| t| t (1 row) SELECT st.heap_blks_read + st.heap_blks_hit >= pr.heap_blks + cl.relpages, --- 53,59 WHERE st.relname='tenk2' AND cl.relname='tenk2'; ?column? | ?column? | ?column? | ?column? --+--+--+-- ! f| f| t| t (1 row) SELECT st.heap_blks_read + st.heap_blks_hit >= pr.heap_blks + cl.relpages, *** *** 62,68 WHERE st.relname='tenk2' AND cl.relname='tenk2'; ?column? | ?column? --+-- ! t| t (1 row) -- End of Stats Test --- 62,68 WHERE st.relname='tenk2' AND cl.relname='tenk2'; ?column? | ?column? --+-- ! f| t (1 row) -- End of Stats Test == On Sat, 23 Jul 2005, Bruce Momjian wrote: > Date: Sat, 23 Jul 2005 11:36:43 -0400 (EDT) > From: Bruce Momjian > To: ohp@pyrenet.fr > Cc: Rocco Altier <[EMAIL PROTECTED]>, > Michael Glaesemann <[EMAIL PROTECTED]>, pgsql-patches@postgresql.org, > pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] regressin failure on latest CVS > > ohp@pyrenet.fr wrote: > > I just checked latest CVS (5 mn ago) the problem is still the same, > > BTW, this is on Unixware 714 and no --enable-integer-datetime > > Do you have the latest patch included int that version of CVS? > Anonymous CVS has a delay, and what was the problem you were seeing, the > rounding or the day - 1 result? > > --- > > > > > > Regards > > On Sat, 23 Jul 2005, Rocco Altier wrote: > > > > > Date: Sat, 23 Jul 2005 11:15:44 -0400 > > > From: Rocco Altier <[EMAIL PROTECTED]> > > > To: Bruce Momjian > > > Cc: Michael Glaesemann <[EMAIL PROTECTED]>, pgsql-patches@postgresql.org, > > > pgsql-hackers@postgresql.org, ohp@pyrenet.fr > > > Subject: RE: [HACKERS] regressin failure on latest CVS > > > > > > This still does not fix the problem. > > > > > > I had done my patch to try to mimic the way 8.0 had handled the math > > > with the remainders, but to carry it over another bucket (day). > > > > > > The problem that I see is that we are taking day_remainder and > > > multiplying by USECS_PER_DAY. Which is a double * int64, thus there is > > > the precision loss there. > > > > > > I think initial division by the factor can't be helped, but repeatedly > > > doing more floating point math on with it is causing the rounding error. > > > > > > Thanks, > > > -rocco > > > > > > > -Original Message- > > > > From: Bruce Momjian [mailto:[EMAIL PROTECTED] > > > > Sent: Saturday, July 23, 2005 10:54 AM > > > > To: Rocco Altier > > > > Cc: Michael Glaesemann; pgsql-patches@postgresql.org; > > > > pgsql-hackers@postgresql.org; ohp@pyrenet.fr > > > > Subject: Re: [HACKERS] regressin failure on latest CVS > > > > > > > > > > > > Rocco Altier wrote: > > > > > This patch fixes the interval regression on my AIX box > > > > (kookaburra) by > > > > > only doing integer math on the interval, instead of > > > > float/double math. > > > > > > > > > > I think this is the correct way to handle this, since it's > > > > an integer > > > > > data type. > > > > > > > > > > I don't know if it will fix Olivier's problem, since I > > > > wasn't able to > > > > > reproduce it. > > > > > > > > > > > > > I have changed the way I compute the remainder values --- instead of > > > > using multiplication, I use division and then subtraction. > > > > This should > > > > fix your rounding problem. Looking at your fix, I don't see > > > > how adding > > > > USECS changes things because the factor is already a float, > > > > but I think > > > > the problem was more the way I was
Re: [PATCHES] [HACKERS] regressin failure on latest CVS
On Sat, 23 Jul 2005, Bruce Momjian wrote: > Date: Sat, 23 Jul 2005 11:36:43 -0400 (EDT) > From: Bruce Momjian > To: ohp@pyrenet.fr > Cc: Rocco Altier <[EMAIL PROTECTED]>, > Michael Glaesemann <[EMAIL PROTECTED]>, pgsql-patches@postgresql.org, > pgsql-hackers@postgresql.org > Subject: Re: [HACKERS] regressin failure on latest CVS > > ohp@pyrenet.fr wrote: > > I just checked latest CVS (5 mn ago) the problem is still the same, > > BTW, this is on Unixware 714 and no --enable-integer-datetime > > Do you have the latest patch included int that version of CVS? > Anonymous CVS has a delay, and what was the problem you were seeing, the > rounding or the day - 1 result? > I was seeing (and still see) the day -1 result. However, if I ./configure --with-integer-datetimes I see the rounding of the day. > --- > > > > > > Regards > > On Sat, 23 Jul 2005, Rocco Altier wrote: > > > > > Date: Sat, 23 Jul 2005 11:15:44 -0400 > > > From: Rocco Altier <[EMAIL PROTECTED]> > > > To: Bruce Momjian > > > Cc: Michael Glaesemann <[EMAIL PROTECTED]>, pgsql-patches@postgresql.org, > > > pgsql-hackers@postgresql.org, ohp@pyrenet.fr > > > Subject: RE: [HACKERS] regressin failure on latest CVS > > > > > > This still does not fix the problem. > > > > > > I had done my patch to try to mimic the way 8.0 had handled the math > > > with the remainders, but to carry it over another bucket (day). > > > > > > The problem that I see is that we are taking day_remainder and > > > multiplying by USECS_PER_DAY. Which is a double * int64, thus there is > > > the precision loss there. > > > > > > I think initial division by the factor can't be helped, but repeatedly > > > doing more floating point math on with it is causing the rounding error. > > > > > > Thanks, > > > -rocco > > > > > > > -Original Message- > > > > From: Bruce Momjian [mailto:[EMAIL PROTECTED] > > > > Sent: Saturday, July 23, 2005 10:54 AM > > > > To: Rocco Altier > > > > Cc: Michael Glaesemann; pgsql-patches@postgresql.org; > > > > pgsql-hackers@postgresql.org; ohp@pyrenet.fr > > > > Subject: Re: [HACKERS] regressin failure on latest CVS > > > > > > > > > > > > Rocco Altier wrote: > > > > > This patch fixes the interval regression on my AIX box > > > > (kookaburra) by > > > > > only doing integer math on the interval, instead of > > > > float/double math. > > > > > > > > > > I think this is the correct way to handle this, since it's > > > > an integer > > > > > data type. > > > > > > > > > > I don't know if it will fix Olivier's problem, since I > > > > wasn't able to > > > > > reproduce it. > > > > > > > > > > > > > I have changed the way I compute the remainder values --- instead of > > > > using multiplication, I use division and then subtraction. > > > > This should > > > > fix your rounding problem. Looking at your fix, I don't see > > > > how adding > > > > USECS changes things because the factor is already a float, > > > > but I think > > > > the problem was more the way I was computing the remainders. > > > > > > > > Patch attached --- let me know if it does not fix your problem. > > > > > > > > -- > > > > > > > > > > > > > -- > > Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) > > 15, Chemin des Monges+33-5-61-50-97-01 (Fax) > > 31190 AUTERIVE +33-6-07-63-80-64 (GSM) > > FRANCE Email: ohp@pyrenet.fr > > -- > > Make your life a dream, make your dream a reality. (St Exupery) > > > > ---(end of broadcast)--- > > TIP 6: explain analyze is your friend > > > > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [HACKERS] regressin failure on latest CVS
I just checked latest CVS (5 mn ago) the problem is still the same, BTW, this is on Unixware 714 and no --enable-integer-datetime Regards On Sat, 23 Jul 2005, Rocco Altier wrote: > Date: Sat, 23 Jul 2005 11:15:44 -0400 > From: Rocco Altier <[EMAIL PROTECTED]> > To: Bruce Momjian > Cc: Michael Glaesemann <[EMAIL PROTECTED]>, pgsql-patches@postgresql.org, > pgsql-hackers@postgresql.org, ohp@pyrenet.fr > Subject: RE: [HACKERS] regressin failure on latest CVS > > This still does not fix the problem. > > I had done my patch to try to mimic the way 8.0 had handled the math > with the remainders, but to carry it over another bucket (day). > > The problem that I see is that we are taking day_remainder and > multiplying by USECS_PER_DAY. Which is a double * int64, thus there is > the precision loss there. > > I think initial division by the factor can't be helped, but repeatedly > doing more floating point math on with it is causing the rounding error. > > Thanks, > -rocco > > > -Original Message- > > From: Bruce Momjian [mailto:[EMAIL PROTECTED] > > Sent: Saturday, July 23, 2005 10:54 AM > > To: Rocco Altier > > Cc: Michael Glaesemann; pgsql-patches@postgresql.org; > > pgsql-hackers@postgresql.org; ohp@pyrenet.fr > > Subject: Re: [HACKERS] regressin failure on latest CVS > > > > > > Rocco Altier wrote: > > > This patch fixes the interval regression on my AIX box > > (kookaburra) by > > > only doing integer math on the interval, instead of > > float/double math. > > > > > > I think this is the correct way to handle this, since it's > > an integer > > > data type. > > > > > > I don't know if it will fix Olivier's problem, since I > > wasn't able to > > > reproduce it. > > > > > > > I have changed the way I compute the remainder values --- instead of > > using multiplication, I use division and then subtraction. > > This should > > fix your rounding problem. Looking at your fix, I don't see > > how adding > > USECS changes things because the factor is already a float, > > but I think > > the problem was more the way I was computing the remainders. > > > > Patch attached --- let me know if it does not fix your problem. > > > > -- > > > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] PITR Archive Recovery
Many thanks for your reply Simon On Wed, 30 Jun 2004, Simon Riggs wrote: > Date: Wed, 30 Jun 2004 19:29:14 +0100 > From: Simon Riggs <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: [PATCHES] PITR Archive Recovery > > On Wed, 2004-06-30 at 12:27, [EMAIL PROTECTED] wrote: > > Given that log files will be archieved, how can we purge them (ie know for > > sure we won't need them anymore) > > > > Good question - you're right I've not mentioned that. > > The answer is straightforward. Whenever you do a backup, one of the > transaction logs will be the current one. That means any logs before the > earliest one you can see can now be purged from the archive. > > So if you can see: 137,138,139 then that means anything at 136 or before > is able to be discarded. Ok, that's clear... BUT not very easy to put in a backup stagtegy... It may be ok if you user tar or cpio; but surely more complicated if you use backup software like Netvault or Tapeware > > However, I'd recommend keeping more than just one backup, usually 2 or > 3, so the actual purge point is dependant upon your data retention > strategy, possibly linked to tape rotation etc.. > sure > > if I do a backup of the DATA dir, then obviously I won't need the logs > > that were taken before. I can't just delete them all because maybe a few > > will be archived during the backup. > > > I agree > Taking a full physical backup will normally need to exclude the pg_xlog > directory, or at least the current xlog. Since it is being written to > very regularly it is almost impossible to take a clean copy using > standard utilities - though filesystem level utilities work fine. > Would it make sense to have SQL phrases (as I recall from my informix days 10 years ago) like START BACKUP LEVEL 0 where cluster would be archieved on whatever you want, disallowing all writes and SART BACKUP LEVEL 1 where cluster and logs would be archieved letting read/write o databases possible... > Best regards, Simon Riggs > > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster > Best regards -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 6, Chemin d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] PITR Archive Recovery
Dear Simon, I've been following the PITR thread with great interest since a long time. I apologie to jump it so late, but there's one question I can't find any answer for. Given that log files will be archieved, how can we purge them (ie know for sure we won't need them anymore) if I do a backup of the DATA dir, then obviously I won't need the logs that were taken before. I can't just delete them all because maybe a few will be archived during the backup. Same thing goes for pg_dump. Maybe I've missed something. Regards, and many thanks for that great feature On Wed, 30 Jun 2004, Simon Riggs wrote: > Date: Wed, 30 Jun 2004 02:46:57 +0100 > From: Simon Riggs <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: [PATCHES] PITR Archive Recovery > > On Tue, 2004-06-29 at 20:59, Simon Riggs wrote: > > On Mon, 2004-06-28 at 21:58, Simon Riggs wrote: > > > PITR Archive Recovery, 28 June 2004 > > > > > > What's in this patch? > > This my LAST, PLANNED patch before Freeze. Any questions? > > This is a patch-on-patch, rather than a full patch. To use this, apply > earlier patches for pitr_v4_4*, then apply this. (Full patch available > upon request...just saving the good people of this list some annoyance > time from a 50k download). > > This now provides: > > - parsing of restore program from recovery.conf > - minor cosmetic changes to some error messages > > ...there's more to do, but I'm working on the... > if it ain't broke, don't fix it... > > Best Regards, Simon Riggs > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 6, Chemin d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] Patch for search_path --- apply to 7.4 branch?
Hi Tom, I'd love to see it in a 7.4.2... With maybe the patch for SMP... Regards On Mon, 19 Jan 2004, Tom Lane wrote: > Date: Mon, 19 Jan 2004 14:15:08 -0500 > From: Tom Lane <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: [PATCHES] Patch for search_path --- apply to 7.4 branch? > > Attached is the patch I just applied to CVS HEAD to fix the search_path > problem that Olivier Prenant recently identified (can't set a search > path for another database if it mentions schemas not present in the > current database). I am looking for comments on whether to back-patch > this into REL7_4_STABLE. It is a rather large patch to fix what might > be considered a non-critical problem, so I'm a bit hesitant about back > patching. Any opinions? > > regards, tom lane > > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 6, Chemin d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] update i386 spinlock for hyperthreading
I have a bi-Xeon 2.6G hyperthreaded if it helps... feel free Regards On Sat, 27 Dec 2003, Manfred Spraul wrote: > Date: Sat, 27 Dec 2003 11:34:16 +0100 > From: Manfred Spraul <[EMAIL PROTECTED]> > To: Tom Lane <[EMAIL PROTECTED]> > Cc: PostgreSQL-patches <[EMAIL PROTECTED]> > Subject: Re: [PATCHES] update i386 spinlock for hyperthreading > > Tom Lane wrote: > > >Manfred Spraul <[EMAIL PROTECTED]> writes: > > > > > >>Tom Lane wrote: > >> > >> > >>>Don't you have to put it in a specific place in the loop to make that > >>>work? If not, why not? > >>> > >>> > >>> > >>Rep;nop is just a short delay - that's all. > >> > >> > > > >That view seems to me to be directly contradicted by this statement: > > > > > > > >>The PAUSE instruction provides a hint to the processor that > >>the code sequence is a spin-wait loop. The processor uses this hint to > >>avoid the memory order violation in most situations, which greatly > >>improves processor performance. > >> > >> > > > >It's not apparent to me how a short delay translates into avoiding a > >memory order violation (possibly some docs on what that means exactly > >might help...). I suspect strongly that there needs to be some near > >proximity between the PAUSE instruction and the lock-test instruction > >for this to work as advertised. It would help if Intel were less coy > >about what the instruction really does. > > > > > My guess: Pentium 4 cpu support something like 250 uops in flight - it > will have a dozend of the spinlock loops in it's pipeline. When the > spinlock is released, it must figure out which of the loops should get > it, and gets lost. My guess is that rep;nop delays the cpu buy at least > 100 cpu ticks, and thus the pipeline will be empty before it proceeds. I > don't have a Pentium 4, and the HP testdrive is down. Someone around who > could run my test app? > > > > > > >>This instruction does not change the architectural state of the > >>processor (that is, it performs essentially a delaying noop > >>operation). > >> > >> > > > >This can be rephrased as "we're not telling you what this instruction > >really does, because its interesting effects are below the level of the > >instruction set architecture". Great. How are we supposed to know > >how to use it? > > > > > There was a w_spinlock.pdf document with reference code. google still > finds it, but the links are dead :-( > > >>I think a separate function is better than adding it into TAS: if it's > >>part of tas, then it would automatically be included by every > >>SpinLockAcquire call - unnecessary .text bloat. > >> > >> > > > >Why do you think it's unnecessary? One thing that I find particularly > >vague in the quoted documentation is the statement that the PAUSE > >instruction is needed to avoid a delay when *exiting* the spin-wait > >loop. Doesn't this mean that a PAUSE is needed in the success path > >when the first TAS succeeds (i.e, the normal no-contention path)? > > > IIRC: No. > > >If not, why not? If so, does it go before or after the lock > >instruction? > > > > > Neither: somewhere in the failure path. > > >Also, if the principal effect is a "short delay", do we really need it > >at all considering that our inner loop in s_lock is rather more than > >an "xchgb" followed by a conditional branch? There will be time for > >the write queue to drain while we're incrementing and testing our > >spin counter (which I trust is in a register...). > > > >The reason I'm so full of questions is that I spent some time several > >days ago looking at exactly this issue, and came away with only the > >conclusion that I had to find some more-detailed documentation before > >I could figure out what we should do about the spinlocks for Xeons. > > > I'll try to find some more docs and post links. > > The 2nd thing I would change is to add a nonatomic test in the slow > path: locked instructions generate lots of bus traffic, and that's a > waste of resources. > > Another question: regardless of the placement of rep;nop - 10% speedup > means that the postgres spends far too much time in the spinlock code. > I've looked at the oprofile dumps, and something like 1.2% of the total > cpu time is spent it the TAS macro in LWLockAcquire. That's the hottest > instruction in the whole profile, it eats more cpu cycles than the > memcpy() calls that transfer data to/from kernel. > Is there an easy way find out which LWLock is contended? > -- > Manfred > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 6, Chemin d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] fix log_min_duration_statement logic error
On Sun, 5 Oct 2003, Rod Taylor wrote: > Date: Sun, 05 Oct 2003 13:05:32 -0400 > From: Rod Taylor <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Cc: Tom Lane <[EMAIL PROTECTED]>, Bruce Momjian <[EMAIL PROTECTED]>, > Peter Eisentraut <[EMAIL PROTECTED]>, Neil Conway <[EMAIL PROTECTED]>, > PostgreSQL Patches <[EMAIL PROTECTED]> > Subject: Re: [PATCHES] fix log_min_duration_statement logic error > > > > That was true already with log_statement and log_duration as separate > > > operations. People use log_pid to deal with it. > > Sorry to jump in... the log_pid is NOT ENOUGH where you have more than > > 3 connections a day (witch is my case) > > log_pid isn't enough, but log_pid + log_connections certainly is. > > log_connections tells you when a new connection was made, so guessing > isn't required. > > > There has been discussion as to have 1 Log file/database where are we on > > that? Is it dead? > > Well, this wouldn't help either unless you happen to have several not so > active databases that makes for a busy system. > Only that I could give the log file to the customer owning the database(s) that would make my job esier. Also I'd love to see the log_query being settable per database... -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 6, Chemin d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] fix log_min_duration_statement logic error
On Sat, 4 Oct 2003, Tom Lane wrote: > Date: Sat, 04 Oct 2003 15:43:34 -0400 > From: Tom Lane <[EMAIL PROTECTED]> > To: Bruce Momjian <[EMAIL PROTECTED]> > Cc: Peter Eisentraut <[EMAIL PROTECTED]>, Neil Conway <[EMAIL PROTECTED]>, > PostgreSQL Patches <[EMAIL PROTECTED]> > Subject: Re: [PATCHES] fix log_min_duration_statement logic error > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> I would prefer to see the log entries look like > >> > >> LOG: query: select * from pg_class; > >> LOG: duration: nn.nnn msec > > > The problem with two lines is that another log message could get between > > them. > > That was true already with log_statement and log_duration as separate > operations. People use log_pid to deal with it. Sorry to jump in... the log_pid is NOT ENOUGH where you have more than 3 connections a day (witch is my case) There has been discussion as to have 1 Log file/database where are we on that? Is it dead? Thanks > > regards, tom lane > > ---(end of broadcast)--- > TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 6, Chemin d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Unixware 713 probs
Thanks Tom, I just cvs update'd and it ccompiles and regression tests pass. I've have no time today to go further though On Sun, 7 Sep 2003, Tom Lane wrote: > Date: Sun, 07 Sep 2003 20:57:04 -0400 > From: Tom Lane <[EMAIL PROTECTED]> > To: Andreas Pflug <[EMAIL PROTECTED]> > Cc: Larry Rosenman <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: Re: [PATCHES] Unixware 713 probs > > Andreas Pflug <[EMAIL PROTECTED]> writes: > > Larry Rosenman wrote: > >> Here's a quickie patch I did to fix it. > > > Patching this or not, if the function's called the backend will SEGV > > either (at least on my 2.4.20 it does) because a IPV6 address is copied > > in the memory space of a IPV4 address. > > I fixed that yesterday. > > The s_addr name collision is unfortunate, but easily worked around; > fix committed as suggested by Larry. > > regards, tom lane > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > >http://archives.postgresql.org > -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 6, Chemin d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
