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: ... !para ! To avoid this situation, run productnamePostgreSQL/productname ! 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 functionvm_enough_memory/ ! in the file filenamemm/mmap.c/in 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
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] 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 || v4bits0 ||
v4bits32)
! 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)
! goto hba_syntax;
!
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
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
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] 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] 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] 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] 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
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
