Re: [HACKERS] psql & readline & win32
"Tom Lane" <[EMAIL PROTECTED]> wrote > > Anyone for trying to port BSD libedit to work on Windows? > Maybe just let it be on Windows is acceptable. I am currently happy with my psql without readline support on Windows, but on Unix that's hard. If Windows users want more advanced client, there are a bunch of GUI tools. Regards, Qingqing ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Why don't we allow DNS names in pg_hba.conf?
I also support this change. My clients have tended to move machines and networks around a lot as well as move databases from machine to machine. It would be nice to let the network gurus concentrate on getting the dns servers up and correct and leverage that work instead of having to change pg_hba.conf when these changes occur. elein [EMAIL PROTECTED] On Sun, Jan 01, 2006 at 01:30:46PM -0500, Tom Lane wrote: > I was reminded of $subject by > http://archives.postgresql.org/pgsql-admin/2006-01/msg2.php > > While I haven't tried it, I suspect that allowing a DNS host name > would take little work (basically removing the AI_NUMERICHOST flag > passed to getaddrinfo in hba.c). There was once a good reason not > to allow it: slow DNS lookups would lock up the postmaster. But > now that we do this work in an already-forked backend, with an overall > timeout that would catch any indefinite blockage, I don't see a good > reason why we shouldn't let people use DNS names. > > Thoughts? > > regards, tom lane > > ---(end of broadcast)--- > TIP 9: In versions below 8.0, the planner will ignore your desire to >choose an index scan if your joining column's datatypes do not >match > ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] SIGALRM in autovacuum.c
Bruce Momjian writes: > Is this correct in autovacuum.c? > pqsignal(SIGALRM, handle_sig_alarm); > Should it be SIG_IGN? Absolutely not. autovacuum takes locks just like a backend and has to be able to handle deadlock timeout checks. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] SIGALRM in autovacuum.c
Bruce Momjian wrote: > Is this correct in autovacuum.c? > > pqsignal(SIGALRM, handle_sig_alarm); > > Should it be SIG_IGN? I don't see autovacuum using a timer or a reason > it is calling the backend's timer routine. FYI, the comment above this says: * Set up signal handlers. We operate on databases much like a regular * backend, so we use the same signal handling. See equivalent code in * tcop/postgres.c. but can you have autovacuum running as a regular backend? I didn't think so. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: 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
[HACKERS] SIGALRM in autovacuum.c
Is this correct in autovacuum.c? pqsignal(SIGALRM, handle_sig_alarm); Should it be SIG_IGN? I don't see autovacuum using a timer or a reason it is calling the backend's timer routine. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: Don't 'kill -9' the postmaster
Re: [HACKERS] psql & readline & win32
Robert Treat <[EMAIL PROTECTED]> writes: > On Sunday 01 January 2006 18:51, Andrew Dunstan wrote: >> This has been debated ad nauseam in the past. The consensus, bar a few >> people with more advanced paranoia than I suffer from, is that we can ;-) > I don't think it is good practice to ship packaged software that is > statically > linked to a gpl library and then claim that your package is bsd licensed. Robert is 100% right. If the Readline people wanted non-GPL packages linking to their code, they'd have used LGPL not GPL. We must not ignore their clear intentions; to do so is certainly unethical and probably illegal. Anyone for trying to port BSD libedit to work on Windows? (Of course, you could also treat the Windows installer as being entirely GPL-licensed, which would effectively comply with both upstream licenses. But I don't find that an appealing solution.) regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] psql & readline & win32
On Sunday 01 January 2006 18:51, Andrew Dunstan wrote:
> Magnus Hagander wrote:
> >4) Can we ship linked with readline in the installer? If not, can we ship
> > a readline-linked binary at all, or just the source? Considering readline
> > drags along the GPL, and not just the LGPL. (We can link either
> > statically (default) or dynamically (separate package) to readline
> > without problems, from what I can tell)
>
> This has been debated ad nauseam in the past. The consensus, bar a few
> people with more advanced paranoia than I suffer from, is that we can ;-)
>
I don't think it is good practice to ship packaged software that is statically
linked to a gpl library and then claim that your package is bsd licensed. If
I were trying to use the windows installer in a commercial application, I
sure wouldn't want that liability.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [HACKERS] EINTR error in SunOS
Doug Royer <[EMAIL PROTECTED]> writes: > Yes - if you assume that EINTR only happens on NFS mounts. > My point is that independent of NFS, the error checking > that I have found in the code is not complete even for > non-NFS file systems. > > > The read() and write() LINUX man pages do NOT specify that EINTR > is an NFS-only error. > > EINTR The call was interrupted by a signal before any data was > read. Right, but I think that's because read() and write() also work on sockets and serial ports, which are always interruptible. I have not heard of local-disk filesystem code on any Unix I've seen ever giving EINTR--a process waiting for disk is always in D state, which means it's not interruptible by signals. If I have the time maybe I'll grovel through the Linux sources and verify this, but I'm pretty sure of it. I'm not a PG internals expert by any means, but my $0.02 on this is that we should: a) recommend NOT using NFS for the database storage b) if NFS must be used, recommend 'hard,nointr' mounts c) treat EINTR as an I/O error (I don't know how easy this would be) d) say "if you mount 'soft' and lose data, tough luck for you" -Doug ---(end of broadcast)--- TIP 1: 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
[HACKERS] Ignore, just a test ...
Upgraded the News Server, and need to make sure gateways are working ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] EINTR error in SunOS
Doug Royer <[EMAIL PROTECTED]> writes: > The MOUNT options are opposite. > > Linux NFS mount - defualts to no-intr > Solaris NFS mount - default to intr Oh, right--I didn't realize that was what you were talking about. -Doug ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] EINTR error in SunOS
Yes - if you assume that EINTR only happens on NFS mounts. My point is that independent of NFS, the error checking that I have found in the code is not complete even for non-NFS file systems. The read() and write() LINUX man pages do NOT specify that EINTR is an NFS-only error. EINTR The call was interrupted by a signal before any data was read. The read() and write() SOLARIS man pages say: EINTR A signal was caught during the read operation and no data was transferred. There are other SVR read() and write() errors: EOVERFLOW (read) The file is a regular file, nbyte is greater than 0, the starting position is before the end-of-file, and the starting position is greater than or equal to the offset maximum established in the open file descrip- tion associated with fildes. EDEADLK The write was going to go to sleep and cause a deadlock situation to occur. EDQUOT The user's quota of disk blocks on the file system containing the file has been exhausted. EFBIG (write) An attempt is made to write a file that exceeds the process's file size limit or the maximum file size (see getrlimit(2) and ulimit(2)). EFBIG The file is a regular file, nbyte is greater than 0, and the starting position is greater than or equal to the offset maximum established in the file description associated with fildes. ENOSPC During a write to an ordinary file, there is no free space left on the device. Bruce Momjian wrote: Let me give you a sky-high view of this. Database reliability requires that the disk drive be 100% reliable. If any part of the disk storage fails (I/O write failure, NFS failure) we have to assume that the disk storage is corrupt and the database needs to be restored from backup. The NFS failure modes seem to suggest that any kind of NFS failure makes our storage suspect, meaning we want NFS to be as non-failure mode as possible. Making PostgreSQL work on NFS system itself is risky, and allowing it to work on systems that will soft-failure on writes seems even worse. -- Doug Royer | http://INET-Consulting.com ---|- We Do Standards - You Need Standards begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consulting.com adr:;;U.S.A email;internet:[EMAIL PROTECTED] title:CEO tel;work:866-594-8574 tel;fax:866-594-8574 note;quoted-printable:AOL: SupportUnix=0D=0A= MSN: [EMAIL PROTECTED] Yahoo: Help4Unix x-mozilla-html:FALSE url:http://Royer.com version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
Re: [HACKERS] EINTR error in SunOS
The MOUNT options are opposite. Linux NFS mount - defualts to no-intr Solaris NFS mount - default to intr Doug McNaught wrote: Doug Royer <[EMAIL PROTECTED]> writes: From the Linux 'nfs' man page: intr If an NFS file operation has a major timeout and it is hard mounted, then allow signals to interupt the file operation and cause it to return EINTR to the calling program. The default is to not allow file operations to be interrupted. Solaris 'mount_nfs' man page intr | nointr Allow (do not allow) keyboard interrupts to kill a process that is hung while waiting for a response on a hard-mounted file system. The default is intr, which makes it possible for clients to interrupt applications that may be waiting for a remote mount. The Solaris and Linux defaults seem to be the opposite of each other. Actually they're the same, though differently worded. "Major timeout" means the server has not responded for N milliseconds, not that the client has decided to time out the request. If 'hard' is set, the client will keep trying indefinitely, though you can interrupt it if you've specified 'intr'. So I think we are saying the same thing. You can get EINTR with hard+intr mounts. Yes, *only* if the user specifically decides to send a signal, or if it uses SIGALRM or whatever. I agree that if you expect 'intr' to be used, your code needs to handle EINTR. I am not sure what you get with soft mounts on a timeout. The Linux manpage implies you get EIO. -Doug ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster -- Doug Royer | http://INET-Consulting.com ---|- We Do Standards - You Need Standards begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consulting.com adr:;;U.S.A email;internet:[EMAIL PROTECTED] title:CEO tel;work:866-594-8574 tel;fax:866-594-8574 note;quoted-printable:AOL: SupportUnix=0D=0A= MSN: [EMAIL PROTECTED] Yahoo: Help4Unix x-mozilla-html:FALSE url:http://Royer.com version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
Re: [HACKERS] Add a "Known Issues" section
Qingqing Zhou <[EMAIL PROTECTED]> writes: > On Sun, 1 Jan 2006, Tom Lane wrote: >> Aren't they all "known issues"? You need to be a lot clearer about what >> distinction you intend to draw, and why it's so important that it >> deserves to be the principal classification metric for TODO. > ... However, there is blur border line between them ... I don't think we want the top-level division of TODO to be a classification that is inherently in-the-eye-of-the-beholder. There would be way too much time wasted arguing what goes where, to little purpose --- because, quite frankly, whether someone else thinks XYZ is an issue has nothing to do with whether any given developer is going to spend time on it tomorrow. Things that are serious bugs (eg, server crashes) usually get fixed fast enough that they never get on TODO in the first place. And many of the things that might be called "known issues" don't belong on TODO because we don't intend to change them (eg, identifier case folding behavior). It might be useful to pick up the "postgresql gotchas" list that's out on the net someplace, and expand and maintain it as a resource oriented mainly at new users: here are some things you might not have expected to behave like that. I don't think this should have anything directly to do with TODO though. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] EINTR error in SunOS
Let me give you a sky-high view of this. Database reliability requires that the disk drive be 100% reliable. If any part of the disk storage fails (I/O write failure, NFS failure) we have to assume that the disk storage is corrupt and the database needs to be restored from backup. The NFS failure modes seem to suggest that any kind of NFS failure makes our storage suspect, meaning we want NFS to be as non-failure mode as possible. Making PostgreSQL work on NFS system itself is risky, and allowing it to work on systems that will soft-failure on writes seems even worse. --- Doug McNaught wrote: > Doug Royer <[EMAIL PROTECTED]> writes: > > > From the Linux 'nfs' man page: > > > > intr If an NFS file operation has a major timeout and it is > > hard mounted, then allow signals to interupt the file > > operation and cause it to return EINTR to the calling > > program. The default is to not allow file operations to > > be interrupted. > > > > Solaris 'mount_nfs' man page > > > > intr | nointr > > Allow (do not allow) keyboard interrupts to kill > > a process that is hung while waiting for a > > response on a hard-mounted file system. The > > default is intr, which makes it possible for > > clients to interrupt applications that may be > > waiting for a remote mount. > > > > The Solaris and Linux defaults seem to be the opposite of each other. > > Actually they're the same, though differently worded. "Major timeout" > means the server has not responded for N milliseconds, not that the > client has decided to time out the request. If 'hard' is set, the > client will keep trying indefinitely, though you can interrupt it if > you've specified 'intr'. > > > So I think we are saying the same thing. > > > > You can get EINTR with hard+intr mounts. > > Yes, *only* if the user specifically decides to send a signal, or if > it uses SIGALRM or whatever. I agree that if you expect 'intr' to be > used, your code needs to handle EINTR. > > > I am not sure what you get with soft mounts on a timeout. > > The Linux manpage implies you get EIO. > > -Doug > > ---(end of broadcast)--- > TIP 2: Don't 'kill -9' the postmaster > -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: Don't 'kill -9' the postmaster
Re: [HACKERS] EINTR error in SunOS
Doug Royer <[EMAIL PROTECTED]> writes: > From the Linux 'nfs' man page: > > intr If an NFS file operation has a major timeout and it is > hard mounted, then allow signals to interupt the file > operation and cause it to return EINTR to the calling > program. The default is to not allow file operations to > be interrupted. > > Solaris 'mount_nfs' man page > > intr | nointr > Allow (do not allow) keyboard interrupts to kill > a process that is hung while waiting for a > response on a hard-mounted file system. The > default is intr, which makes it possible for > clients to interrupt applications that may be > waiting for a remote mount. > > The Solaris and Linux defaults seem to be the opposite of each other. Actually they're the same, though differently worded. "Major timeout" means the server has not responded for N milliseconds, not that the client has decided to time out the request. If 'hard' is set, the client will keep trying indefinitely, though you can interrupt it if you've specified 'intr'. > So I think we are saying the same thing. > > You can get EINTR with hard+intr mounts. Yes, *only* if the user specifically decides to send a signal, or if it uses SIGALRM or whatever. I agree that if you expect 'intr' to be used, your code needs to handle EINTR. > I am not sure what you get with soft mounts on a timeout. The Linux manpage implies you get EIO. -Doug ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] default resource limits
Andrew Dunstan <[EMAIL PROTECTED]> writes: > That's easily fixed, I think. We just need to remember what we have > proved works. > I can apply the attached patch if you think that's worth doing. If you like; but if so, remove the comment saying that there's a connection between the required list entries. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Why don't we allow DNS names in pg_hba.conf?
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Am Sonntag, 1. Januar 2006 19:30 schrieb Tom Lane: >> I don't see a good >> reason why we shouldn't let people use DNS names. > I generally support this, but I wonder if this could have strange > effects if a name resolves to more than one IP address or even an IPv4 > and an IPv6 address. That's a good point: we'd have to be prepared to match the actual remote IP address to more than one return value from getaddrinfo, so the change wouldn't be a one-liner after all. It still seems like a pretty localized change though. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] default resource limits
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
In experimenting I needed to set this at 20 for it to bite much. If we
wanted to fine tune it I'd be inclined to say that we wanted
20*connections buffers for the first, say, 50 or 100 connections and 10
or 16 times for each connection over that. But that might be getting a
little too clever - something we should leave to a specialised tuning
tool. After all, we try these in fairly discrete jumps anyway. Maybe a
simple factor around 20 would be sufficient.
I think 10 is probably a good compromise value. If we set it to 20
we'll find "make check" failing on Darwin because Apple's standard
SHMMAX value doesn't allow more than about 300 buffers ... and the
regression tests want max_connections to be at least 20.
Well, we could do something like:
#define MIN_BUFS_FOR_CONNS(nconns) ((nconns) <= 20 ? (nconns) * 10 : 200
+ (((nconns) - 20) * 20))
But I'm happy just to live with 10 :-)
I noticed while fooling with this on my laptop that initdb was selecting
a shared_buffers value less than the value it had just proved would work
:-(. This is because the list of shared_buffers values it was probing
did not include all the values corresponding to values tried during the
max_connections scan. I've added documentation about that gotcha.
That's easily fixed, I think. We just need to remember what we have
proved works.
I can apply the attached patch if you think that's worth doing.
Thanks for cleaning this up. The remaining question is whether to leave
the max connections tried at 100 on all platforms or bump it for those
that won't hurt from extra semaphore use. I can see arguments both ways
- I'm less concerned about this than the shared buffers numbers.
cheers
andrew
Index: initdb.c
===
RCS file: /cvsroot/pgsql/src/bin/initdb/initdb.c,v
retrieving revision 1.103
diff -c -r1.103 initdb.c
*** initdb.c 31 Dec 2005 23:50:59 - 1.103
--- initdb.c 2 Jan 2006 00:52:58 -
***
*** 1122,1128
status,
test_conns,
test_buffs,
! test_max_fsm;
printf(_("selecting default max_connections ... "));
fflush(stdout);
--- 1122,1130
status,
test_conns,
test_buffs,
! test_max_fsm,
! ok_buffers = 0;
!
printf(_("selecting default max_connections ... "));
fflush(stdout);
***
*** 1144,1150
--- 1146,1155
DEVNULL, DEVNULL, SYSTEMQUOTE);
status = system(cmd);
if (status == 0)
+ {
+ ok_buffers = test_buffs;
break;
+ }
}
if (i >= connslen)
i = connslen - 1;
***
*** 1158,1163
--- 1163,1173
for (i = 0; i < bufslen; i++)
{
test_buffs = trial_bufs[i];
+ if (test_buffs <= ok_buffers)
+ {
+ test_buffs = ok_buffers;
+ break;
+ }
test_max_fsm = FSM_FOR_BUFS(test_buffs);
snprintf(cmd, sizeof(cmd),
***
*** 1173,1181
if (status == 0)
break;
}
! if (i >= bufslen)
! i = bufslen - 1;
! n_buffers = trial_bufs[i];
n_fsm_pages = FSM_FOR_BUFS(n_buffers);
printf("%d/%d\n", n_buffers, n_fsm_pages);
--- 1183,1189
if (status == 0)
break;
}
! n_buffers = test_buffs;
n_fsm_pages = FSM_FOR_BUFS(n_buffers);
printf("%d/%d\n", n_buffers, n_fsm_pages);
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] EINTR error in SunOS
From the Linux 'nfs' man page: intr If an NFS file operation has a major timeout and it is hard mounted, then allow signals to interupt the file operation and cause it to return EINTR to the calling program. The default is to not allow file operations to be interrupted. Solaris 'mount_nfs' man page intr | nointr Allow (do not allow) keyboard interrupts to kill a process that is hung while waiting for a response on a hard-mounted file system. The default is intr, which makes it possible for clients to interrupt applications that may be waiting for a remote mount. The Solaris and Linux defaults seem to be the opposite of each other. So I think we are saying the same thing. You can get EINTR with hard+intr mounts. I am not sure what you get with soft mounts on a timeout. Doug McNaught wrote: Doug Royer <[EMAIL PROTECTED]> writes: The 'intr' option to NFS is not the same as EINTR. It it means 'if the server does not respond for a while, then return an EINTR', just like any other disk read() or write() does when it fails to reply. No, you're thinking of 'soft'. 'intr' (which is actually a modifier to the 'hard' setting) causes the I/O to hang until the server comes back or the process gets a signal (in which case EINTR is returned). -Doug ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster -- Doug Royer | http://INET-Consulting.com ---|- We Do Standards - You Need Standards begin:vcard fn:Doug Royer n:Royer;Doug org:INET-Consulting.com adr:;;U.S.A email;internet:[EMAIL PROTECTED] title:CEO tel;work:866-594-8574 tel;fax:866-594-8574 note;quoted-printable:AOL: SupportUnix=0D=0A= MSN: [EMAIL PROTECTED] Yahoo: Help4Unix x-mozilla-html:FALSE url:http://Royer.com version:2.1 end:vcard smime.p7s Description: S/MIME Cryptographic Signature
Re: [HACKERS] Add a "Known Issues" section
Qingqing Zhou <[EMAIL PROTECTED]> writes: > Do we have a "known issues" section somewhere? If not, I would suggest we > split the TODO list into two big sections, one is the PostgreSQL > improvement part, the other is the known issues part. Aren't they all "known issues"? You need to be a lot clearer about what distinction you intend to draw, and why it's so important that it deserves to be the principal classification metric for TODO. regards, tom lane ---(end of broadcast)--- TIP 1: 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: [HACKERS] psql & readline & win32
Magnus Hagander wrote: Considering we have a fix, I think we need to re-enable readline on win32, and document this. However, there are a couple of things to decide on first: 1) Should it be made default? As it requires you to include this file to work, perhaps it should be set to non-default and specifically require a --with-readline? Also depends on th eanswers of a couple of questions below, I think. Good work. It should be the default - if we find readline we should use it. I guess that means the installer would need to ship the readline DLL, along with all the other third party DLLs it ships. 2) Should we ship a file of standard bindings. We're not going to get it complete, but we could get some of the most common ones in europe at least (in sweden, this would for example include "[EMAIL PROTECTED]|"). Which would help people a lot. Yes we should, at least for Windows - put it in share along with other samples, maybe. 3) How should the inputrc file be loaded. By default, you have to type SET INPUTRC="\some\where\inputrc" before you launch psql. But we could just as easily add: #if defined(WIN32) && defined(USE_READLINE) rl_read_init_file(our_path_to_inputrc); #endif to psql, making that step a whole lot easier. Especially for people who launch psql from the startmenu, and can't specify program-specific env vars. if user has $HOME/inputrc load $HOME/inputrc elsif exists $SYSTEMCONFIG/inputrc load $SYSTEMCONFIG/inputrc endif Since inputrc is meant to service many applications, we shouldn't try to bypass that. cheers andrew 4) Can we ship linked with readline in the installer? If not, can we ship a readline-linked binary at all, or just the source? Considering readline drags along the GPL, and not just the LGPL. (We can link either statically (default) or dynamically (separate package) to readline without problems, from what I can tell) This has been debated ad nauseam in the past. The consensus, bar a few people with more advanced paranoia than I suffer from, is that we can ;-) cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Add a "Known Issues" section
On Sunday 01 January 2006 17:30, Qingqing Zhou wrote:
> On Sun, 1 Jan 2006, Tom Lane wrote:
> > Qingqing Zhou <[EMAIL PROTECTED]> writes:
> > > Do we have a "known issues" section somewhere? If not, I would suggest
> > > we split the TODO list into two big sections, one is the PostgreSQL
> > > improvement part, the other is the known issues part.
> >
> > Aren't they all "known issues"? You need to be a lot clearer about what
> > distinction you intend to draw, and why it's so important that it
> > deserves to be the principal classification metric for TODO.
>
> If I believe "Terminators" will dominate the world in a predicatable
> future, I will draw a clear distinction here.
>
> "Known issues" means bugs or something beyond your expectation -- but
> "bug" itself by definition is "functional". For example, if a program
> crashes, you can say it is bug or it is not a bug totally by your
> functional definition.
Well, we've certainly put certain items like this on the todo list before, and
if you know of any that exist in the current code I don't think anyone would
be against adding them to TODO (provided that there isn't a more immediate
fix that would be implemented)
> Another example is "Allow commenting of variables
> in postgresql.conf to restore them to defaults", which is beyound our
> expectation.
>
This doesn't seem like a good example, since this isn't an agreed upon desired
behavior. I mean some people agree with it but others don't so until we can
decide on a plan of action it's hard to put specifics on the todo.
> "Improvement" means something that we want to add does not exist before or
> usable but not that good. All the performance items and new functions
> should come here.
>
> However, there is blur border line between them and some "improvements"
> may have higher priority than "known issues". For example, those in the
> PITR section.
>
This is starting to sound like the "how do i determine the priority of xyz
issues and/or set those priorities" idea. Typically these don't work well
because any given issue is only as high priority as someone willing to fix
it.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [HACKERS] Why don't we allow DNS names in pg_hba.conf?
Tom Lane wrote: I was reminded of $subject by http://archives.postgresql.org/pgsql-admin/2006-01/msg2.php While I haven't tried it, I suspect that allowing a DNS host name would take little work (basically removing the AI_NUMERICHOST flag passed to getaddrinfo in hba.c). There was once a good reason not to allow it: slow DNS lookups would lock up the postmaster. But now that we do this work in an already-forked backend, with an overall timeout that would catch any indefinite blockage, I don't see a good reason why we shouldn't let people use DNS names. Thoughts? We debated this back in May 2003 - I was going to do it but it got lost among other stuff. Still worth doing, I think. cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Add a "Known Issues" section
On Sun, 1 Jan 2006, Tom Lane wrote: > Qingqing Zhou <[EMAIL PROTECTED]> writes: > > Do we have a "known issues" section somewhere? If not, I would suggest we > > split the TODO list into two big sections, one is the PostgreSQL > > improvement part, the other is the known issues part. > > Aren't they all "known issues"? You need to be a lot clearer about what > distinction you intend to draw, and why it's so important that it > deserves to be the principal classification metric for TODO. > If I believe "Terminators" will dominate the world in a predicatable future, I will draw a clear distinction here. "Known issues" means bugs or something beyond your expectation -- but "bug" itself by definition is "functional". For example, if a program crashes, you can say it is bug or it is not a bug totally by your functional definition. Another example is "Allow commenting of variables in postgresql.conf to restore them to defaults", which is beyound our expectation. "Improvement" means something that we want to add does not exist before or usable but not that good. All the performance items and new functions should come here. However, there is blur border line between them and some "improvements" may have higher priority than "known issues". For example, those in the PITR section. Regards, Qingqing ---(end of broadcast)--- TIP 1: 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
[HACKERS] Add a "Known Issues" section
Do we have a "known issues" section somewhere? If not, I would suggest we split the TODO list into two big sections, one is the PostgreSQL improvement part, the other is the known issues part. AFAICS there are some long lasting problems there simply because hackers are not aware of or too trouble to fix. Splitting the TODO list will ring the bell more loudly. Regards, Qingqing ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Why don't we allow DNS names in pg_hba.conf?
Am Sonntag, 1. Januar 2006 19:30 schrieb Tom Lane: > I don't see a good > reason why we shouldn't let people use DNS names. I generally support this, but I wonder if this could have strange effects if a name resolves to more than one IP address or even an IPv4 and an IPv6 address. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Why don't we allow DNS names in pg_hba.conf?
On Jan 1, 2006, at 2:02 PM, Martijn van Oosterhout wrote: For the user in referred to thread: SSH tunnelling. I wonder if there's a way we can make that easier to setup... Making this easier and transparent would be nice, but I would still vote to allow DNS names in pg_hba.conf. SSH tunneling implies another level of software, user accounts, and permissions. It would be nice to handle the entire sphere of users and permissions from within PostgreSQL. For database access requirements, I would much rather allow DNS names in pg_hba.conf than provide SSH access. John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 1: 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: [HACKERS] Why don't we allow DNS names in pg_hba.conf?
"Marc G. Fournier" <[EMAIL PROTECTED]> writes: > On Sun, 1 Jan 2006, Tom Lane wrote: >> ... I don't see a good >> reason why we shouldn't let people use DNS names. > Security? Possibly, but if you're worried about that sort of attack you just don't use DNS names in pg_hba.conf. Certainly it'd be worth putting a warning in the manual about the risks of referring to DNS servers that aren't directly under your control. But that doesn't seem like a reason not to provide the feature for those who want it. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Why don't we allow DNS names in pg_hba.conf?
Marc G. Fournier wrote: On Sun, 1 Jan 2006, Tom Lane wrote: I was reminded of $subject by http://archives.postgresql.org/pgsql-admin/2006-01/msg2.php While I haven't tried it, I suspect that allowing a DNS host name would take little work (basically removing the AI_NUMERICHOST flag passed to getaddrinfo in hba.c). There was once a good reason not to allow it: slow DNS lookups would lock up the postmaster. But now that we do this work in an already-forked backend, with an overall timeout that would catch any indefinite blockage, I don't see a good reason why we shouldn't let people use DNS names. Thoughts? Security? I'd bet most pg_hba.conf entries will be (private) networks, not hosts. Since private networks defined in DNS are probably quite rare, only few people could benefit. Those who *do* define specific host entries, are probably quite security aware. They might find DNS safe for their purposes, but they'd probably like a function that shows the resulting hba entries after DNS resolution. Routers/firewalls that allow DNS names will usually resolve them immediately, and store the IP addresses. Regards, Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Why don't we allow DNS names in pg_hba.conf?
On Sun, Jan 01, 2006 at 02:50:37PM -0400, Marc G. Fournier wrote: > Employee adds his DNS to pg_hba.conf, becomes disgruntled employee, moves > to different IP and same name, and can still access your database? I think it depends how you do the check. You can either do a forward lookup from the name and match that to the IP. Or you can do a reverse lookup on the IP to match the name. Or both. To work around either requires hijacking DNS but which servers varies. If you've got the entries in /etc/hosts that makes hijacking harder. I'm thinking something like tcpwrappers would be an example here. They have a paranoid mode where your reverse and forward have to match. Something to consider. For the user in referred to thread: SSH tunnelling. I wonder if there's a way we can make that easier to setup... Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them. pgpsS9MEdVnjX.pgp Description: PGP signature
Re: [HACKERS] EINTR error in SunOS
On Sun, 1 Jan 2006, Tom Lane wrote: > Qingqing Zhou <[EMAIL PROTECTED]> writes: > > I understand put a CHECK_FOR_INTERRUPTS() in the retry-loop may make more > > graceful stop, but it won't work in some cases -- notice that the io > > routines we will patch can be used before the signal mechanism is setup. > > I don't think it will help much at all: too many of the operations in > question are invoked in places where CHECK_FOR_INTERRUPTS is a no-op. > Examples: > * disk writes are mostly done by the bgwriter and not backends at all > * unlinks are generally done during xact commit/rollback > Right. > Qingqing's point about failures in system()-invoked commands (think > archive_command for PITR) is a mighty good one too. That puts a > serious crimp into any illusion that we can really fix this in any > reliable way. > Not my credit, I just collect Rod & Greg's posts about this here :-) And I still not sure what exactly the problem we want to fix here -- think our target is the "operation should not faild because of EINTR". Regards, Qingqing ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Why don't we allow DNS names in pg_hba.conf?
On Sun, 1 Jan 2006, Tom Lane wrote: I was reminded of $subject by http://archives.postgresql.org/pgsql-admin/2006-01/msg2.php While I haven't tried it, I suspect that allowing a DNS host name would take little work (basically removing the AI_NUMERICHOST flag passed to getaddrinfo in hba.c). There was once a good reason not to allow it: slow DNS lookups would lock up the postmaster. But now that we do this work in an already-forked backend, with an overall timeout that would catch any indefinite blockage, I don't see a good reason why we shouldn't let people use DNS names. Thoughts? Security? Employee adds his DNS to pg_hba.conf, becomes disgruntled employee, moves to different IP and same name, and can still access your database? What about "DNS hijacking/forging"? I don't know how hard it is to do, but if one of the upstream network provides puts in a 'filter' for port 53 (DNS) and starts feeding you incorrect data, so that they can access your databases? Both are relatively extreme, and in both bases, the 'attacker' would have to have previous knowledge (ie. disgruntled ex employee) but DNS != trusted IP ... then again, it may be possible to hijack/forge the IP itself, in which case, there is no difference ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] Why don't we allow DNS names in pg_hba.conf?
I was reminded of $subject by http://archives.postgresql.org/pgsql-admin/2006-01/msg2.php While I haven't tried it, I suspect that allowing a DNS host name would take little work (basically removing the AI_NUMERICHOST flag passed to getaddrinfo in hba.c). There was once a good reason not to allow it: slow DNS lookups would lock up the postmaster. But now that we do this work in an already-forked backend, with an overall timeout that would catch any indefinite blockage, I don't see a good reason why we shouldn't let people use DNS names. Thoughts? regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Removing SORTFUNC_LT/REVLT
Martijn van Oosterhout writes: > On Thu, Dec 29, 2005 at 04:33:32PM -, Andrew - Supernews wrote: >> Does it matter? How would the same operator specify different orderings >> in different operator classes, > Well, we currently don't forbid it and indeed encourage it (by > encouraging reverse operator classes) as the only way to handle the > ORDER a, b DESC case right now. > I don't think I can find any other examples right now. I don't think > I'd have a problem with forbidding it at some future date. Right, the reverse-sort opclass is the only practical example that anyone's pointed out ... for btree. For GiST it would be a serious error to try to restrict operators to appear in at most one opclass. Therefore, we're not going to be forbidding it, and the code has to behave in a sane fashion if someone does it. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] EINTR error in SunOS
Qingqing Zhou <[EMAIL PROTECTED]> writes: > I understand put a CHECK_FOR_INTERRUPTS() in the retry-loop may make more > graceful stop, but it won't work in some cases -- notice that the io > routines we will patch can be used before the signal mechanism is setup. I don't think it will help much at all: too many of the operations in question are invoked in places where CHECK_FOR_INTERRUPTS is a no-op. Examples: * disk writes are mostly done by the bgwriter and not backends at all * unlinks are generally done during xact commit/rollback Qingqing's point about failures in system()-invoked commands (think archive_command for PITR) is a mighty good one too. That puts a serious crimp into any illusion that we can really fix this in any reliable way. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] psql & readline & win32
Getting started early this year, I've finally found a way around the issues with readline on win32. And it just took a little bit of google research and some testing. Recap of the problem: When running psql in a readline enabled mode on win32, any character requiring the AltGr key to generate will not work. In a lot of non-US locales, this includes the backslash key, which makes psql pretty darn unusable. The "fix" for this that went into 8.0 is to disable readline on win32 pending a fix. Now, this can be fixed. And it's as simple as specifying an inputrc file. For backslash, this file needs to contain: "\M-\\": "\\" And then similarly for every other character requiring AltGr. Considering we have a fix, I think we need to re-enable readline on win32, and document this. However, there are a couple of things to decide on first: 1) Should it be made default? As it requires you to include this file to work, perhaps it should be set to non-default and specifically require a --with-readline? Also depends on th eanswers of a couple of questions below, I think. 2) Should we ship a file of standard bindings. We're not going to get it complete, but we could get some of the most common ones in europe at least (in sweden, this would for example include "[EMAIL PROTECTED]|"). Which would help people a lot. 3) How should the inputrc file be loaded. By default, you have to type SET INPUTRC="\some\where\inputrc" before you launch psql. But we could just as easily add: #if defined(WIN32) && defined(USE_READLINE) rl_read_init_file(our_path_to_inputrc); #endif to psql, making that step a whole lot easier. Especially for people who launch psql from the startmenu, and can't specify program-specific env vars. If we wanted to, we could even bind the keys using rl_parse_and_bind() or similar, but keeping it in a separate file makes it possible to edit it without recompiling, which is a definite plus. 4) Can we ship linked with readline in the installer? If not, can we ship a readline-linked binary at all, or just the source? Considering readline drags along the GPL, and not just the LGPL. (We can link either statically (default) or dynamically (separate package) to readline without problems, from what I can tell) I think we ship readline-linked RPMs, but I'm not sure about that? Now even if we can't ship readline linked binaries in the installer, it's still a good thing to provide the ability to build them, of course :-) //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Removing SORTFUNC_LT/REVLT
On Thu, Dec 29, 2005 at 04:33:32PM -, Andrew - Supernews wrote: > On 2005-12-29, Tom Lane <[EMAIL PROTECTED]> wrote: > > Well, no, that's not the problem: the problem is that you should be able > > to specify ORDER BY any sort ordering that the system can deal with, and > > the USING syntax is in fact too impoverished to do that. What if the > > mentioned operator is in more than one operator class? I believe that > > ATM the code makes a random choice of which opclass' sort function to > > use, which pretty much sucks. > > Does it matter? How would the same operator specify different orderings > in different operator classes, given that it must be a strict weak ordering > for sorting to even work, and such an ordering is completely determined by > either one of its greater-than/less-than operators? Well, we currently don't forbid it and indeed encourage it (by encouraging reverse operator classes) as the only way to handle the ORDER a, b DESC case right now. I don't think I can find any other examples right now. I don't think I'd have a problem with forbidding it at some future date. Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them. pgpWfmh0w16LM.pgp Description: PGP signature
Re: [HACKERS] Removing SORTFUNC_LT/REVLT
On Sun, Jan 01, 2006 at 07:48:56AM -, Andrew - Supernews wrote:
> Doesn't this result in incorrect output in multi-column sorts?
>
> i.e. if 'Foo' = 'foo', but for sorting purposes you always sort them
> with 'Foo' first, then a multicolumn sort of the following data:
>
> ('Foo',1)
> ('foo',2)
> ('Foo',3)
>
> would produce the wrong output, no?
Yeah, I was thinking about that but I'm not sure how big a problem it
is.
We could make this work by having the sorting routines (and by
extension the lookups for indexes) by doing two passes: one with the
comparison routines and use the actual sorting routines only on
tie-breaks. A kind of big mark against the idea. Although this is
exactly the kind of work required for string sorting in many locales...
Whatever we do, the result of ORDER BY has to match index order. Does
this mean scankeys need to have two functions, in case of tie-breaking
multi-column keys. I dunno but it needs thinking about.
Have a nice day,
--
Martijn van Oosterhout http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.
pgpoA71wMSYFC.pgp
Description: PGP signature
Re: [HACKERS] Removing SORTFUNC_LT/REVLT
On 2005-12-29, Tom Lane <[EMAIL PROTECTED]> wrote: > Well, no, that's not the problem: the problem is that you should be able > to specify ORDER BY any sort ordering that the system can deal with, and > the USING syntax is in fact too impoverished to do that. What if the > mentioned operator is in more than one operator class? I believe that > ATM the code makes a random choice of which opclass' sort function to > use, which pretty much sucks. Does it matter? How would the same operator specify different orderings in different operator classes, given that it must be a strict weak ordering for sorting to even work, and such an ordering is completely determined by either one of its greater-than/less-than operators? -- Andrew, Supernews http://www.supernews.com - individual and corporate NNTP services ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
