Re: [PATCHES] IPV4 addresses on IPV6 machines in pg_hba.conf
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Would you like me to conditionally add the IPv6 line to pg_hba.conf from > > initdb now? > > I was going to tackle that tomorrow, but if you wanna do it, go for it. No, go ahead. I wasn't sure if you were waiting for me so I asked. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] IPV4 addresses on IPV6 machines in pg_hba.conf
Bruce Momjian <[EMAIL PROTECTED]> writes: > Would you like me to conditionally add the IPv6 line to pg_hba.conf from > initdb now? I was going to tackle that tomorrow, but if you wanna do it, go for it. regards, tom lane ---(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] IPV4 addresses on IPV6 machines in pg_hba.conf
[EMAIL PROTECTED] wrote: > Bruce Momjian said: > > > > Would you like me to conditionally add the IPv6 line to pg_hba.conf > > from initdb now? > > > > As a matter of taste and possibly due to some paranoia I would prefer to > see it added unconditionally to pg_hba.conf and conditionally commented > out in initdb. (The paranoia is what says to me that it is better to have > hidden removal of something useless than hidden addition of something > potentially dangerous). So have initdb coditionally comment it out in data/pg_hba.conf --- I can do that. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] IPV4 addresses on IPV6 machines in pg_hba.conf
Bruce Momjian said: > > Would you like me to conditionally add the IPv6 line to pg_hba.conf > from initdb now? > As a matter of taste and possibly due to some paranoia I would prefer to see it added unconditionally to pg_hba.conf and conditionally commented out in initdb. (The paranoia is what says to me that it is better to have hidden removal of something useless than hidden addition of something potentially dangerous). cheers andrew ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] IPV4 addresses on IPV6 machines in pg_hba.conf
Tom Lane wrote: > Andreas Pflug <[EMAIL PROTECTED]> writes: > > are you sure it's not just for beauty's sake? > > What I didn't like about your last patch was the close coupling of the > CIDR/netmask processing to the v4-to-v6 conversion; as Andrew pointed > out, you were hacking into hba.c functionality that overlapped with > SockAddr_cidr_mask. Doing the conversion after we've collected the > netmask seems a lot cleaner to me. Also, this way keeps a fairly decent > separation of interests between hba.c (parsing the hba.conf syntax) and > ip.c (messing with address representations). > > > While talking about beauty: that setting of *cidr_slash to '/' and 0 > > doesn't look too esthetic... > > It is ugly (and I didn't write it ;-)). But if we palloc'd a modified > version of the token we'd have to remember to pfree it, so it nets out > to about the same amount of code either way I think. If you wanna try > to clean it up more, be my guest ... Would you like me to conditionally add the IPv6 line to pg_hba.conf from initdb now? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] IPV4 addresses on IPV6 machines in pg_hba.conf
Tom Lane said: > Andreas Pflug <[EMAIL PROTECTED]> writes: >> are you sure it's not just for beauty's sake? > > What I didn't like about your last patch was the close coupling of the CIDR/netmask processing to the v4-to-v6 conversion; as Andrew pointed out, you were hacking into hba.c functionality that overlapped with SockAddr_cidr_mask. Doing the conversion after we've collected the netmask seems a lot cleaner to me. Also, this way keeps a fairly decent separation of interests between hba.c (parsing the hba.conf syntax) and ip.c (messing with address representations). > >> While talking about beauty: that setting of *cidr_slash to '/' and 0 doesn't look too esthetic... > > It is ugly (and I didn't write it ;-)). But if we palloc'd a modified version of the token we'd have to remember to pfree it, so it nets out to about the same amount of code either way I think. If you wanna try to clean it up more, be my guest ... > I wrote it :-) The reason is that alone of the tokens in this file address/mask is a composite. I agree it is a bit ugly. In fact, this whole function is ugly and getting uglier and needs recasting. I intend to have a go at that, since I am partly responsible, but not in the present cycle. Nobody objected when the original patch from Kurt (including my bit) was submitted, though, so it's a bit late to complain now about aesthetics. cheers andrew ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] minor documentation improvements
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Bruce Momjian writes: >> Huh? We have been uppercasing GUC variable names in most places >> already. > Currently, the documentation contains about 2 GUC variable names in upper > case, the rest is lower case. (The exception are the list headings in the > main description in runtime.sgml, which are all upper case. That is a bit > inconsistent, but I think it's OK, because here they sort of serve as > section titles.) Okay, that seems reasonable. Ignore my prior message --- I hadn't come across this one yet. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] minor documentation improvements
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Neil Conway writes: >> This patch makes a few minor improvements to the docs: make the >> conventions more consistent, > They are consistent: They're all lowercase. Until now. The varnames listed in runtime.sgml are uppercase though, no? Or were you intending the variable definitions to be upper case and all the references lower case? It's not real clear what the intended style is, and I have to say that I thought Neil was heading in the intended direction also. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] minor documentation improvements
On Fri, 2003-09-05 at 17:16, Peter Eisentraut wrote: > Currently, the documentation contains about 2 GUC variable names in upper > case, the rest is lower case. There are significantly more than 2 uses of upper-case GUC names in the docs (more like 10 by my guess), but in any case, the current usage is inconsistent. So, is upper-case or lower-case better? I'd personally prefer lower-case, I suppose, but I'm not too bothered either way. -Neil ---(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] IPV4 addresses on IPV6 machines in pg_hba.conf
Andreas Pflug <[EMAIL PROTECTED]> writes: > are you sure it's not just for beauty's sake? What I didn't like about your last patch was the close coupling of the CIDR/netmask processing to the v4-to-v6 conversion; as Andrew pointed out, you were hacking into hba.c functionality that overlapped with SockAddr_cidr_mask. Doing the conversion after we've collected the netmask seems a lot cleaner to me. Also, this way keeps a fairly decent separation of interests between hba.c (parsing the hba.conf syntax) and ip.c (messing with address representations). > While talking about beauty: that setting of *cidr_slash to '/' and 0 > doesn't look too esthetic... It is ugly (and I didn't write it ;-)). But if we palloc'd a modified version of the token we'd have to remember to pfree it, so it nets out to about the same amount of code either way I think. If you wanna try to clean it up more, be my guest ... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] Minor verbosity increase for analyze
Found some bugs with this patch - that makes it about 1 per line
patched... :-(
i) onerel->rd_nblocks should be elog'ed as an unsigned int.
ii) acquire_sample_rows has 2 return points - I had ignored the case
where the
onerel has < sample size tuples in it.
--- src/backend/commands/analyze.c.orig 2003-09-06 10:31:02.0 +1200
+++ src/backend/commands/analyze.c 2003-09-06 10:35:15.0 +1200
@@ -539,6 +539,9 @@
if (!HeapTupleIsValid(tuple))
{
*totalrows = (double) numrows;
+ elog(elevel, " pages = %u rows = %.0f [smaller than sample size]",
+ onerel->rd_nblocks, *totalrows); /* display pages and rows */
+
return numrows;
}
@@ -690,7 +693,7 @@
/*
* Emit some interesting relation info
*/
- elog(elevel, " pages = %d rows/page = %d rows = %.0f",
+ elog(elevel, " pages = %u rows/page = %d rows = %.0f",
onerel->rd_nblocks, (int)tuplesperpage, *totalrows);
return numrows;
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [PATCHES] IPV4 addresses on IPV6 machines in pg_hba.conf
Tom Lane wrote: IMHO the struct needs to be created officially by getaddrinfo(), which will lead more or less the the same solution I posted previously. No, we just need to use datastructures that are under our control for the values that will get passed to rangeSockAddr. A few more lines... Hm, are you sure it's not just for beauty's sake? While talking about beauty: that setting of *cidr_slash to '/' and 0 doesn't look too esthetic... Regards, Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] IPV4 addresses on IPV6 machines in pg_hba.conf
Andreas Pflug <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> I thought this was still really messy, so I modified it to use a >> separate "promote v4 address to v6" subroutine. I've applied the >> attached patch (plus docs). It's not very well tested since I don't >> have an IPv6 setup here; please check that it does what you want. >> > It SEGVs. Reason is that the memcpy of the promote_v4_to_v6_XXX > functions assumes that the sockaddr_storage is large enough to hold an > IPV6 address, which appears to be not true. Drat. That didn't happen when I forced it through that path here, but I guess it could if getaddrinfo is trying to be conservative about the amount of memory in its return value. I'll rework it. > IMHO the struct needs to be created officially by > getaddrinfo(), which will lead more or less the the same solution I > posted previously. No, we just need to use datastructures that are under our control for the values that will get passed to rangeSockAddr. A few more lines... regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] note on dropped columns in pg_attribute
On Friday 05 September 2003 16:24, Peter Eisentraut wrote:
> Robert Treat writes:
> > I didn't see it documented anywhere that a 0 in attypid of pg_attribute,
> > and given the note on the need to match pg_type lest failure seems to
> > warrant the mention.
>
> A column is dropped if and only if attisdropped is true.
Right. I didn't mean to imply otherwise. That first line should have read "I
didn't see it documented anywhere that a 0 in attypid of pg_attribute is OK
with dropped columns". My only point was that in the notes it says that
attypid is the OID in pg_type, and that information in that table must match
information in this table else PostgreSQL will fail. However that's not
neccessarily true for dropped columns where there is no match cause attypid
will be 0. Are there other cases where it can be set to 0?
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] IPV4 addresses on IPV6 machines in pg_hba.conf
Tom Lane wrote: I thought this was still really messy, so I modified it to use a separate "promote v4 address to v6" subroutine. I've applied the attached patch (plus docs). It's not very well tested since I don't have an IPv6 setup here; please check that it does what you want. It SEGVs. Reason is that the memcpy of the promote_v4_to_v6_XXX functions assumes that the sockaddr_storage is large enough to hold an IPV6 address, which appears to be not true. Since the struct isn't created by a plain malloc() and returned by free(), but assembled by getaddrinfo() according to the family's requirement, I don't see a way how to fix this. IMHO the struct needs to be created officially by getaddrinfo(), which will lead more or less the the same solution I posted previously. Regards, Andreas ---(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
Re: [PATCHES] note on dropped columns in pg_attribute
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Robert Treat writes: >> I didn't see it documented anywhere that a 0 in attypid of pg_attribute, >> and given the note on the need to match pg_type lest failure seems to >> warrant the mention. > A column is dropped if and only if attisdropped is true. Yes. If we're going to add something to pg_attribute.h, it ought to say that atttypid is *undefined* in a dropped column. The last thing we need is people testing it instead of attisdropped. Also, any such documentation addition should go into catalogs.sgml not only the .h file. BTW, the rationale for the behavior Robert noticed is explained in heap.c: /* * Set the type OID to invalid. A dropped attribute's type link * cannot be relied on (once the attribute is dropped, the type might * be too). Fortunately we do not need the type row --- the only * really essential information is the type's typlen and typalign, * which are preserved in the attribute's attlen and attalign. We set * atttypid to zero here as a means of catching code that incorrectly * expects it to be valid. */ attStruct->atttypid = InvalidOid; 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
Re: [PATCHES] minor documentation improvements
Peter Eisentraut wrote: > Bruce Momjian writes: > > > Huh? We have been uppercasing GUC variable names in most places > > already. > > Currently, the documentation contains about 2 GUC variable names in upper > case, the rest is lower case. (The exception are the list headings in the > main description in runtime.sgml, which are all upper case. That is a bit > inconsistent, but I think it's OK, because here they sort of serve as > section titles.) Also note that postgresql.conf, command-line option > equivalents, and SET commands all tend to use them in lower case, so that > seems like the direction to go. Oh, OK, got it. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(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] Warning for missing createlang
Peter Eisentraut wrote: > Bruce Momjian writes: > > > How about this, that also suggests you mistyped the name: > > > > > HINT: Perhaps you need to use 'createlang' to load the language into > > > the database, or you mistyped the language name. > > That's only one step away from this: > > peter=# SELECT * FROM test; > ERROR: relation "test" does not exist > HINT: Perhaps you need to use "CREATE TABLE" to create the table in the > database, or you mistyped the table name. > > I think not... I never suggested that. Just because the extreme is wrong doesn't make the case we are discussing wrong. If the hint is useful, then we add it. I don't see the above as useful, while I see the CREATE FUCTION as useful. No one is posting asking why they have to create the table before selecting from it. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] minor documentation improvements
Peter Eisentraut wrote: > Neil Conway writes: > > > This patch makes a few minor improvements to the docs: make the > > conventions more consistent, > > They are consistent: They're all lowercase. Until now. Huh? We have been uppercasing GUC variable names in most places already. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] minor documentation improvements
Bruce Momjian writes: > Huh? We have been uppercasing GUC variable names in most places > already. Currently, the documentation contains about 2 GUC variable names in upper case, the rest is lower case. (The exception are the list headings in the main description in runtime.sgml, which are all upper case. That is a bit inconsistent, but I think it's OK, because here they sort of serve as section titles.) Also note that postgresql.conf, command-line option equivalents, and SET commands all tend to use them in lower case, so that seems like the direction to go. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] Warning for missing createlang
Bruce Momjian writes: > How about this, that also suggests you mistyped the name: > > > HINT: Perhaps you need to use 'createlang' to load the language into > > the database, or you mistyped the language name. That's only one step away from this: peter=# SELECT * FROM test; ERROR: relation "test" does not exist HINT: Perhaps you need to use "CREATE TABLE" to create the table in the database, or you mistyped the table name. I think not... -- Peter Eisentraut [EMAIL PROTECTED] ---(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] IPV4 addresses on IPV6 machines in pg_hba.conf
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
>> You should check that the CIDR mask is a valid integer. You would need
>> to use strtol() rather than atoi() to do that. Perhaps this should be
>> hoisted out of ip.c:SockAddr_cidr_mask() and put in hba.c.
> Right, I added this.
I thought this was still really messy, so I modified it to use a
separate "promote v4 address to v6" subroutine. I've applied the
attached patch (plus docs). It's not very well tested since I don't
have an IPv6 setup here; please check that it does what you want.
regards, tom lane
*** src/backend/libpq/hba.c.origFri Sep 5 10:35:54 2003
--- src/backend/libpq/hba.c Fri Sep 5 16:24:41 2003
***
*** 673,685
if (cidr_slash)
*cidr_slash = '/';
- if (file_ip_addr->ai_family != port->raddr.addr.ss_family)
- {
- /* Wrong address family. */
- freeaddrinfo_all(hints.ai_family, file_ip_addr);
- return;
- }
-
/* Get the netmask */
if (cidr_slash)
{
--- 673,678
***
*** 703,708
--- 696,723
if (file_ip_addr->ai_family != mask->ss_family)
goto hba_syntax;
+ }
+
+ if (file_ip_addr->ai_family != port->raddr.addr.ss_family)
+ {
+ /*
+* Wrong address family. We allow only one case: if the
+* file has IPv4 and the port is IPv6, promote the file
+* address to IPv6 and try to match that way.
+*/
+ #ifdef HAVE_IPV6
+ if (file_ip_addr->ai_family == AF_INET &&
+ port->raddr.addr.ss_family == AF_INET6)
+ {
+ promote_v4_to_v6_addr((struct sockaddr_storage *)
file_ip_addr->ai_addr);
+ promote_v4_to_v6_mask(mask);
+ }
+ else
+ #endif /* HAVE_IPV6 */
+ {
+ freeaddrinfo_all(hints.ai_family, file_ip_addr);
+ return;
+ }
}
/* Read the rest of the line. */
*** src/backend/libpq/ip.c.orig Sun Aug 3 23:00:36 2003
--- src/backend/libpq/ip.c Fri Sep 5 16:24:42 2003
***
*** 34,40
#endif
#include
#include
! #endif
#include "libpq/ip.h"
--- 34,41
#endif
#include
#include
!
! #endif /* !defined(_MSC_VER) && !defined(__BORLANDC__) */
#include "libpq/ip.h"
***
*** 265,273
--- 266,281
return 0;
}
+
#endif /* HAVE_UNIX_SOCKETS */
+ /*
+ * rangeSockAddr - is addr within the subnet specified by netaddr/netmask ?
+ *
+ * Note: caller must already have verified that all three addresses are
+ * in the same address family; and AF_UNIX addresses are not supported.
+ */
int
rangeSockAddr(const struct sockaddr_storage * addr,
const struct sockaddr_storage * netaddr,
***
*** 287,292
--- 295,333
return 0;
}
+ static int
+ rangeSockAddrAF_INET(const struct sockaddr_in * addr,
+const struct sockaddr_in * netaddr,
+const struct sockaddr_in * netmask)
+ {
+ if (((addr->sin_addr.s_addr ^ netaddr->sin_addr.s_addr) &
+netmask->sin_addr.s_addr) == 0)
+ return 1;
+ else
+ return 0;
+ }
+
+
+ #ifdef HAVE_IPV6
+ static int
+ rangeSockAddrAF_INET6(const struct sockaddr_in6 * addr,
+ const struct sockaddr_in6 * netaddr,
+ const struct sockaddr_in6 * netmask)
+ {
+ int i;
+
+ for (i = 0; i < 16; i++)
+ {
+ if (((addr->sin6_addr.s6_addr[i] ^ netaddr->sin6_addr.s6_addr[i]) &
+netmask->sin6_addr.s6_addr[i]) != 0)
+ return 0;
+ }
+
+ return 1;
+ }
+
+ #endif
+
/*
*SockAddr_cidr_mask - make a network mask of the appropriate family
* and required number of significant bits
***
*** 358,391
return 0;
}
! static int
! rangeSockAddrAF_INET(const struct sockaddr_in * addr, const struct sockaddr_in *
netaddr,
!const struct sockaddr_in * netmask)
{
! if (((addr->sin_addr.s_addr ^ netaddr->sin_addr.s_addr) &
!netmask->sin_addr.s_addr) == 0)
! return 1;
! else
! return 0;
! }
! #ifdef HAVE_IPV6
! static int
! rangeSockAddrAF_INET6
Re: [PATCHES] minor documentation improvements
Neil Conway writes: > This patch makes a few minor improvements to the docs: make the > conventions more consistent, They are consistent: They're all lowercase. Until now. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] note on dropped columns in pg_attribute
Robert Treat writes: > I didn't see it documented anywhere that a 0 in attypid of pg_attribute, > and given the note on the need to match pg_type lest failure seems to > warrant the mention. A column is dropped if and only if attisdropped is true. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] doc patch - linux memory handling
Andrew Dunstan <[EMAIL PROTECTED]> writes: > can you the missing space on the marked line, or do you need another > patch from me? Fixed. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] doc patch - linux memory handling
Bruce, can you the missing space on the marked line, or do you need another patch from me? thanks andrew Andriy Tkachuk wrote: seems to be little syntax problem: On Thu, 4 Sep 2003, Bruce Momjian wrote: Patch applied. Thanks. --- Andrew Dunstan wrote: ... ! ! To avoid this situation, run PostgreSQL ! on a machine where you ! can be sure that other processes will not run the machine out ! of memory. If your kernel supports strict and/or paranoid modes ! of overcommit handling, you can also relieve this problem by ! altering the system's default behaviour. This can be determined ! by examining the function vm_enough_memory ! in the file mm/mmap.cin the kernel source. ^^ -- Because strait is the gate, and narrow is the way, which leadeth unto life, and few there be that find it. (MAT 7:14) Ask, and it shall be given you; seek, and ye shall find; knock, and it shall be opened unto you... (MAT 7:7) ANT17-RIPE http://www.imt.com.ua ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(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] postgresql-7.4b1 Native-Windows patch
Hi Bruce. As for mbvalidate, it seems that this is all right. Thank you. Regards, Hiroshi Saito - Original Message - From: "Bruce Momjian" <[EMAIL PROTECTED]> > > I went over this patch and fixed the problem with WIN32_CONSOLE. It > seems you have a problem with mbvalidate. Is that correct? What > doesn't work there? > > Also, I see you had to ifdef out something in thread.c. Would you test > current CVS and see if you still need that change. > > Thanks. postgresql-7.4b2_win32.patch Description: Binary data ---(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
Re: [PATCHES] [HACKERS] [BUGS] 7.4 beta 1: SET log_statement=false
On Thu, Sep 04, 2003 at 01:06:15AM -0400, Bruce Momjian wrote:
> I have followed your suggestion and applied the following patch to have
> PGC_USERLIMIT track reset_val rather than session_val. I now see that
> all sources set the default, except SET:
I just updated my CVS workign directory tree. Your patch as
expected.
Thanks!
Bertrand.
--
%!PS
297.6 420.9 translate 90 rotate 0 setgray gsave 0 1 1{pop 0 180 moveto 100
180 170 100 170 -10 curveto 180 -9 180 -9 190 -10 curveto 190 100 100 180
0 180 curveto fill 180 rotate}for grestore/Bookman-LightItalic findfont
240 scalefont setfont -151.536392 -63.7998886 moveto (bp)show showpage
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [PATCHES] IPV4 addresses on IPV6 machines in pg_hba.conf
Andrew Dunstan wrote:
Andreas,
You should check that the CIDR mask is a valid integer. You would need
to use strtol() rather than atoi() to do that. Perhaps this should be
hoisted out of ip.c:SockAddr_cidr_mask() and put in hba.c.
Right, I added this.
Regards,
Andreas
Index: hba.c
===
RCS file: /projects/cvsroot/pgsql-server/src/backend/libpq/hba.c,v
retrieving revision 1.112
diff -c -r1.112 hba.c
*** hba.c 5 Sep 2003 03:57:13 - 1.112
--- hba.c 5 Sep 2003 09:04:33 -
***
*** 673,708
if (cidr_slash)
*cidr_slash = '/';
! if (file_ip_addr->ai_family != port->raddr.addr.ss_family)
{
! /* Wrong address family. */
freeaddrinfo_all(hints.ai_family, file_ip_addr);
! return;
}
! /* Get the netmask */
! if (cidr_slash)
{
! if (SockAddr_cidr_mask(&mask, cidr_slash + 1,
!
file_ip_addr->ai_family) < 0)
! goto hba_syntax;
}
else
{
! /* Read the mask field. */
! line = lnext(line);
! if (!line)
! goto hba_syntax;
! token = lfirst(line);
!
! ret = getaddrinfo_all(token, NULL, &hints, &file_ip_mask);
! if (ret || !file_ip_mask)
! goto hba_syntax;
!
! mask = (struct sockaddr_storage *) file_ip_mask->ai_addr;
!
! if (file_ip_addr->ai_family != mask->ss_family)
! goto hba_syntax;
}
/* Read the rest of the line. */
--- 673,774
if (cidr_slash)
*cidr_slash = '/';
! #ifdef HAVE_IPV6
!
! if (file_ip_addr->ai_family == AF_INET && port->raddr.addr.ss_family
== AF_INET6)
{
! /* port got a IPV6 address, but the current line is IPV4.
! * We'll make a IPV6 entry from this line, to check if by chance the
connecting port
! * is a converted IPV4 address. */
!
! char *v6addr=palloc(strlen(token)+8);
! char *v6mask;
!
freeaddrinfo_all(hints.ai_family, file_ip_addr);
!
! if (cidr_slash)
! *cidr_slash = 0;
! sprintf(v6addr, ":::%s", token);
! if (cidr_slash)
! *cidr_slash = '/';
!
! ret = getaddrinfo_all(v6addr, NULL, &hints, &file_ip_addr);
! if (ret || !file_ip_addr)
! {
! ereport(LOG,
! (errcode(ERRCODE_CONFIG_FILE_ERROR),
!errmsg("could not interpret converted
IP address \"%s\" in config file: %s",
! token,
gai_strerror(ret;
! }
! if (cidr_slash)
! {
! int v4bits;
! char *endptr;
!
! v4bits=strtol(cidr_slash+1, &endptr, 10);
! if (cidr_slash[1]==0 || *endptr!=0 || v4bits<0 ||
v4bits>32)
! goto hba_syntax;
!
! v6mask = palloc(20);
! sprintf(v6mask, "%d", v4bits+96);
! if (SockAddr_cidr_mask(&mask, v6mask,
file_ip_addr->ai_family) < 0)
! goto hba_syntax;
! }
! else
! {
! line = lnext(line);
! if (!line)
! goto hba_syntax;
! token = lfirst(line);
! v6mask = palloc(strlen(token)+32);
! sprintf(v6mask, "::::::%s",
token);
!
! ret = getaddrinfo_all(v6mask, NULL, &hints,
&file_ip_mask);
! if (ret || !file_ip_mask)
! goto hba_syntax;
!
! mask = (struct sockaddr_storage *)
file_ip_mask->ai_addr;
!
! if (file_ip_addr->ai_family != mask->ss_family)
!
Re: [PATCHES] libpq-win32 patches
Hi Bruce, + +/* getpwuid doesn't exist under win32 */ +#define getpwuid(uid) NULL + #endif /* pg_config_h_win32__ */ Why was this needed? I realize we don't have getpwuid() on Win32, but we do have GetUserName() for cases where we need the name but not the directory. Because all the getpwuid() calls seem ifdef'ed out under Win32 anyway, I don't understand why you needed it. I believe it was the first thing I did to have libpq compile at all. Later, I went into the ssl code and made it work, effectively commenting out all calls to getpwuid() making that line unnecessary. Can't we check the OS version via the compiler? Maybe not portabily between the various compilers supported. If you're talking about the WIN32 macro, this should be supported by every compiler running for win32, because windows headers rely on this. Regards, Andreas ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PATCHES] doc patch - linux memory handling
seems to be little syntax problem: On Thu, 4 Sep 2003, Bruce Momjian wrote: > > Patch applied. Thanks. > > --- > > > Andrew Dunstan wrote: ... > > > > ! > > ! To avoid this situation, run PostgreSQL > > ! on a machine where you > > ! can be sure that other processes will not run the machine out > > ! of memory. If your kernel supports strict and/or paranoid modes > > ! of overcommit handling, you can also relieve this problem by > > ! altering the system's default behaviour. This can be determined > > ! by examining the function vm_enough_memory > > ! in the file mm/mmap.cin the kernel source. ^^ -- Because strait is the gate, and narrow is the way, which leadeth unto life, and few there be that find it. (MAT 7:14) Ask, and it shall be given you; seek, and ye shall find; knock, and it shall be opened unto you... (MAT 7:7) ANT17-RIPE http://www.imt.com.ua ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
