Re: [HACKERS] Problem with pg_attribute.attstorage for pg_class.relacl
Bruce Momjian [EMAIL PROTECTED] writes: pg_class.relacl is of type aclitem[] and has a pg_attribute.attstorage of 'x', even though it doesn't support TOAST expansion: It can't be toasted because pg_class hasn't got a toast table. I can't recall at the moment whether there's a fundamental reason for that or it's just an oversight. Should we modify pg_attribute.h to make it not an 'x'? No, because that would not improve the error message. All it would do is prevent relacl from making use of a pg_class toast table, when and if we get around to adding one. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Hi, Am Mittwoch, 3. September 2003 20:16 schrieb Bruce Momjian: ... As for the IPv6 issue --- how prevalent is this problem. What OS versions are affected? Has the user done something special to enable this? I have a SuSE 8.2 out of the box. I have done nothing with IPv6. I don't even know much about IPv6. Users expect, that it works just after installation. But after following the discussion I think, that it is not so much a problem. I have 127.0.0.1 in my pg_hba.conf and when I set PGHOST to 127.0.0.1 it workes. If I set PGHOST to localhost, it resolves to ::1, wich don't match my pg_hba.conf-entry. The error message is somewhat clear and gives the user a good hint, where to look for. I don't like the idea of doing something special with loopback-interfaces. Loopback-interfaces are to test the network and tries to handle everything like normal networking. Is it possible to ignore IPv6-entries in pg_hba.conf on non-IPv6-machines? Then we could uncomment IPv6 localhost connections by default. Or uncomment these entries just on IPv6-machines. But this needs modification of default pg_hba.conf depending on OS. Tommi -- Dr. Eckhardt + Partner GmbH http://www.epgmbh.de ---(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: [HACKERS] Win32 native port
Hi! Thanks to all who have replied (privately or via the list), it seems sometimes it's just necessary to be a bit insistant! That said, I'm positively surprised by what has been done already (especially Bruce and Marc, this is really a GoodThing to have the web page and the list). I'm currently in the process of setting up my development environment (how the heck do I get bison/flex to compile under MingW/MSYS? Oh my...), and then I'll go adventuring in the code. Thanks again, all. Looking forward to seeing you on the -win32 list. Greetings, Joerg -- Leading SW developer - S.E.A GmbH Mail: [EMAIL PROTECTED] WWW: http://www.sea-gmbh.com ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Win32 native port
Joerg Hessdoerfer kirjutas N, 04.09.2003 kell 10:22: I'm currently in the process of setting up my development environment (how the heck do I get bison/flex to compile under MingW/MSYS? Oh my...) there is a precompiled bison in the MinGW filelist http://www.mingw.org/download.shtml#hdr2 dunno about flex ;( , and then I'll go adventuring in the code. -- Hannu ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Stats Collector Error 7.4beta1 and 7.4beta2
On Thu, 4 Sep 2003, Bruce Momjian wrote:
Tom Lane wrote:
Matthew T. O'Connor [EMAIL PROTECTED] writes:
... Initially I saw an error in the logs about an IPv6 address
error but after I recompiled everthing with a simple ./configure
--prefix=/home/user/somethingelse/ I didn't get the IPv6 error in the
logs anymore.
Hm. Could it be an IPv6 issue --- that is, the stats collector is alive
and faithfully listening on some UDP port, but it's not the same port
the backends try to send to? Given the discussion over the past couple
of days about bizarre interpretations of loopback addresses in
pg_hba.conf, I could sure believe there's some similar kind of issue for
the stats collector.
Doesn't the stats collector use unix domain sockets, not IP?
Nup.
for (addr = addrs; addr; addr = addr-ai_next)
{
#ifdef HAVE_UNIX_SOCKETS
/* Ignore AF_UNIX sockets, if any are returned. */
if (addr-ai_family == AF_UNIX)
continue;
#endif
if ((pgStatSock = socket(addr-ai_family, SOCK_DGRAM, 0)) = 0)
break;
}
I thing I haven't seen asked: is there a packet filter blocking
local-local UDP traffic by any chance?
Thanks,
Gavin
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Transaction status in default psql prompt?
On Wed, Sep 03, 2003 at 11:31:55PM -0400, Bruce Momjian wrote:
Yes, I like the transaction status being the default prompt, but I don't
like the prompt shifting. Remember guys who have the current directory
in their prompt --- the thing bounces around all over the place.
Is that avoidable if you want to be able to indicate nesting level as well?
There may be a simple but difficult choice there. Personally I'd like to
see something like an opening brace ({) in my prompt for a transaction;
that'd be a nice, nagging reminder that I'm in the middle of unfinished
business.
Jeroen
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] Is it a memory leak in PostgreSQL 7.4beta?
Hans, You are right about the startup memory - here is the top line for a few seconds after startup : PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 10116 postgres 15 0 3816 3816 3180 R 33.8 1.0 0:01.03 postmaster seems that VIRT, RES, SHR all get the increase counted against them as time goes on (as Tom suggested, I guess its to do with how top does its accounting on this platform). Hans-Jürgen Schönig wrote: I can hardly imagine that the backend started working with 9mb of memory. what did you do that PostgreSQL needed so much memory from the beginning??? are you using the default settings? usually the postmaster does not need more than 3mb at startup (in this scenario). ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Tommi Maekitalo wrote: Users expect, that it works just after installation. But after following the discussion I think, that it is not so much a problem. I have 127.0.0.1 in my pg_hba.conf and when I set PGHOST to 127.0.0.1 it workes. If I set PGHOST to localhost, it resolves to ::1, wich don't match my pg_hba.conf-entry. The error message is somewhat clear and gives the user a good hint, where to look for. With the patch I submitted yesterday it would just work out of the box and no error message. ISTM the default setting should do just that. I don't like the idea of doing something special with loopback-interfaces. Loopback-interfaces are to test the network and tries to handle everything like normal networking. Have a look at the patch: http://archives.postgresql.org/pgsql-patches/2003-09/msg00010.php The only special thing it does is in deciding if a connection matches the rule. Otherwise it is treated exactly the same as any other network connection. Is it possible to ignore IPv6-entries in pg_hba.conf on non-IPv6-machines? Then we could uncomment IPv6 localhost connections by default. Or uncomment these entries just on IPv6-machines. But this needs modification of default pg_hba.conf depending on OS. Ignoring entries is probably storing up trouble for yourself in the future. Say I mistype 192.168:1.1 on an IP4 only machine and it is silently ignored? Commenting out / uncommenting entries is problematic. The only sane time would be to do it at initdb time, ISTM. But what if IP6 is turned on after you run initdb? BOOM no work. With my patch you would keep working happily :-) I'm done arguing about this - I'll leave it up to the committers to decide what they want to do and move on to something else. cheers andrew ---(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
[HACKERS] Potential bug in ALTER TABLE?
Hi,
just want to verify first with you guys before dumping it on the bugs
list. Most likely I am just being silly here or something.
Take this:
create table blah (name TEXT CHECK (name IN ('blah', 'bleh')));
test=# \d blah
Table public.blah
Column | Type | Modifiers
+--+---
name | text |
Check constraints: blah_name ((name = 'blah'::text) OR (name = 'bleh'::text))
As we would expect PostgreSQL to do. The constraint has an
automatically assigned name.
Now, to continue:
ALTER TABLE blah DROP CONSTRAINT blah_name;
ALTER TABLE blah ADD CHECK (name IN ('blah', 'bleh'));
test=# \d blah
Table public.blah
Column | Type | Modifiers
+--+---
name | text |
Check constraints: $1 ((name = 'blah'::text) OR (name = 'bleh'::text))
And this time around PostgreSQL doesn't assign an automatic name.
Well, it depends on what you call a name, but $1, $2, and so on isn't
quite descriptive. Is this an oversight or am I missing some subtle
thing here?
--
Jeroen Ruigrok van der Werven asmodai(at)wxs.nl / asmodai
PGP fingerprint: 2D92 980E 45FE 2C28 9DB7 9D88 97E6 839B 2EAC 625B
http://www.tendra.org/ | http://www.in-nomine.org/~asmodai/diary/
Happiness is the absence of the striving for happiness...
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Potential bug in ALTER TABLE?
Jeroen Ruigrok/asmodai [EMAIL PROTECTED] writes:
just want to verify first with you guys before dumping it on the bugs
list. Most likely I am just being silly here or something.
The ALTER ADD CONSTRAINT form creates a table constraint, ie, one that's
not attached to any particular column. If you write the constraint in
the CREATE TABLE as a table constraint, then you get the same result as
with ALTER ADD CONSTRAINT.
regression=# create table blah (name TEXT, CHECK (name IN ('blah', 'bleh')));
CREATE TABLE
regression=# \d blah
Table public.blah
Column | Type | Modifiers
+--+---
name | text |
Check constraints:
$1 CHECK ((name = 'blah'::text) OR (name = 'bleh'::text))
If you don't like the automatically generated name, assign your own...
regression=# ALTER TABLE blah ADD CONSTRAINT fooey CHECK (name IN ('blah', 'bleh'));
ALTER TABLE
regression=# \d blah
Table public.blah
Column | Type | Modifiers
+--+---
name | text |
Check constraints:
$1 CHECK ((name = 'blah'::text) OR (name = 'bleh'::text))
fooey CHECK ((name = 'blah'::text) OR (name = 'bleh'::text))
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: [HACKERS] Potential bug in ALTER TABLE?
Jeroen Ruigrok/asmodai wrote:
Hi,
just want to verify first with you guys before dumping it on the bugs
list. Most likely I am just being silly here or something.
Take this:
create table blah (name TEXT CHECK (name IN ('blah', 'bleh')));
test=# \d blah
Table public.blah
Column | Type | Modifiers
+--+---
name | text |
Check constraints: blah_name ((name = 'blah'::text) OR (name = 'bleh'::text))
As we would expect PostgreSQL to do. The constraint has an
automatically assigned name.
Now, to continue:
ALTER TABLE blah DROP CONSTRAINT blah_name;
ALTER TABLE blah ADD CHECK (name IN ('blah', 'bleh'));
test=# \d blah
Table public.blah
Column | Type | Modifiers
+--+---
name | text |
Check constraints: $1 ((name = 'blah'::text) OR (name = 'bleh'::text))
And this time around PostgreSQL doesn't assign an automatic name.
Well, it depends on what you call a name, but $1, $2, and so on isn't
quite descriptive. Is this an oversight or am I missing some subtle
thing here?
You can name it yourself:
ALTER TABLE blah ADD CONSTRAINT blurfl CHECK (name IN ('blah', 'bleh'));
I do this a lot.
I agree the autogenerated names are less than pretty.
cheers
andrew
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
[HACKERS] Seqscan in MAX(index_column)
(Perhaps a newbie question, but I tried to google this out without success). Why postgres does an expensive seqscan to find the max(value) for an indexed column? I think MAX() does not know or cares if a column is indexed, but... Should not it? BTW, is there some smarter trick to do that? I know I can just do a very fast (SELECT pk FROM foo ORDER BY pk DESC LIMIT 1) instead, but my coleagues are arguing that MAX(indexed_column) seems to be a lot more smarter in MS-SQLServer and I end up without a good response. Thank you, -- Paulo Scardine Brazil ---(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: [HACKERS] Seqscan in MAX(index_column)
On 4 Sep 2003 at 11:32, Paulo Scardine wrote: (Perhaps a newbie question, but I tried to google this out without success). Why postgres does an expensive seqscan to find the max(value) for an indexed column? I think MAX() does not know or cares if a column is indexed, but... Should not it? BTW, is there some smarter trick to do that? No. Postgresql uses MVCC which mean there could be multiple views of sample tuple active at the same time. There is no way to tell which is max. value for a column as definition of a committed value can be a moving target. It can not be cached, at least easily. That's the price to pay for MVCC. Same goes for select count(*) from table. That query has to end up with a sequential scan. I know I can just do a very fast (SELECT pk FROM foo ORDER BY pk DESC LIMIT 1) instead, but my coleagues are arguing that MAX(indexed_column) seems to be a lot more smarter in MS-SQLServer and I end up without a good response. Well, postgresql earns solid concurrency due to MVCC. Set up postgresql and MS SQL server on same machine and do a rudimentary benchmark with 100 clients hitting database hard. See where you get more tps'.s In postgresql, readers and writers don't block each other. AFAIK, in MS SQL server rows are ocked for update. So if you lock a row in transaction and does not commit for long, MS SQL will have serious problems. All night long transactions are no problem to postgresql except for the fact that vacuum can not clean the tuples locked in tranactions. HTH Bye Shridhar -- Blutarsky's Axiom: Nothing is impossible for the man who will not listen to reason. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Seqscan in MAX(index_column)
On Thu, 4 Sep 2003, Shridhar Daithankar wrote: column? I think MAX() does not know or cares if a column is indexed, but... No. Postgresql uses MVCC which mean there could be multiple views of sample tuple active at the same time. There is no way to tell which is max. value for a column as definition of a committed value can be a moving target. It can not be cached, at least easily. That's the price to pay for MVCC. Same goes for select count(*) from table. That query has to end up with a sequential scan. It does not have to be like that. Even with a mvcc database it can use the index for max/min and in my opinion it should. As far as I know the only reason why it's not implemented in postgresql is because pg has a general aggregate model and max/min are implemented using that. Still, max/min are special in that they are almost the only aggregates that can use an index to deliver the result directly. Some day someone should make max/min a special case in pg. Exactly how is the question. I don't know mssql much, but I guess you can't define your own aggregate functions there? Then all aggregate functions are special anyway. -- /Dennis ---(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: [HACKERS] Win32 native port
Joerg Hessdoerfer wrote: Hi! Thanks to all who have replied (privately or via the list), it seems sometimes it's just necessary to be a bit insistant! That said, I'm positively surprised by what has been done already (especially Bruce and Marc, this is really a GoodThing to have the web page and the list). I'm currently in the process of setting up my development environment (how the heck do I get bison/flex to compile under MingW/MSYS? Oh my...), and then I'll go adventuring in the code. Thanks again, all. Looking forward to seeing you on the -win32 list. Uh, I should have mentioned that on the web page --- I will now. I normally mount the Unix file via Samba and run everthing from there so I can run bison/flex and CVS from Unix, and just do the compiles via Win32. -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Seqscan in MAX(index_column)
This is an FAQ, BTW -- try searching the archives again. It's also mentioned in the documentation: http://candle.pha.pa.us/main/writings/pgsql/sgml/functions-aggregate.html On Thu, 2003-09-04 at 11:10, Dennis Bjorklund wrote: On Thu, 4 Sep 2003, Shridhar Daithankar wrote: It can not be cached, at least easily. That's the price to pay for MVCC. Same goes for select count(*) from table. That query has to end up with a sequential scan. It does not have to be like that. Even with a mvcc database it can use the index for max/min and in my opinion it should. Right, AFAIK MVCC isn't relevant to MAX() (given a btree index, you can just read the index in the right order and return the first valid tuple), although it makes optimizing COUNT(*) trickier, I believe. As far as I know the only reason why it's not implemented in postgresql is because pg has a general aggregate model and max/min are implemented using that. Still, max/min are special in that they are almost the only aggregates that can use an index to deliver the result directly. Some day someone should make max/min a special case in pg. Exactly how is the question. Well, it's an open question whether it's worth uglifying the backend to support this optimization, given that there is a trivial workaround that people can use. It would make it easier to port code to PostgreSQL from other RDBMSs, though... -Neil ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Seqscan in MAX(index_column)
Hello In my opinion, in 7.4 this optimized max() aggregate function would be a very small, but significant improvement. As one of the members on the list said, it would be a lot easier to port from/to other RDBMSes, with keeping the same optimalization of the queries. Bye, Gergely Czuczy mailto: [EMAIL PROTECTED] PGP: http://phoemix.harmless.hu/phoemix.pgp The point is, that geeks are not necessarily the outcasts society often believes they are. The fact is that society isn't cool enough to be included in our activities. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] FK type mismatches?
Should this produce a warning? nconway=# create table a (b int4 unique); NOTICE: CREATE TABLE / UNIQUE will create implicit index a_b_key for table a CREATE TABLE nconway=# create table c (d int8 references a (b)); NOTICE: CREATE TABLE will create implicit trigger(s) for FOREIGN KEY check(s) CREATE TABLE Aside from the logical inconsistency, it will also lead to poor performance since the type mismatch will prevent index scans. I've noticed a couple people have reported performance issues due to making this kind of mistake. -Neil ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Seqscan in MAX(index_column)
Shridhar Daithankar [EMAIL PROTECTED] writes: On 4 Sep 2003 at 11:32, Paulo Scardine wrote: (Perhaps a newbie question, but I tried to google this out without success). Why postgres does an expensive seqscan to find the max(value) for an indexed column? I think MAX() does not know or cares if a column is indexed, but... Should not it? BTW, is there some smarter trick to do that? No. Postgresql uses MVCC which mean there could be multiple views of sample tuple active at the same time. There is no way to tell which is max. value for a column as definition of a committed value can be a moving target. It has nothing to do with MVCC. It has to do with implementing this is hard in the general case. Think of examples like: select max(foo) group by bar; or select max(foo) where xyz = z; To do it properly max/min have to be special-cased and tightly integrated with other code to handle index scans and aggregates. As it currently stands they're implemented the same way as any other aggregate, which means they get to see all the records in the grouping. This is a frequently asked question, I'm surprised you didn't find stuff searching with google. There have been numerous long discussions on this topic not long ago. People are still trying to think about how to handle this better. -- greg ---(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: [HACKERS] FE/BE Protocol - Specific version
If my memory serves me well, Oracle has a number of system triggers. On database startup and shutdown and perhaps also on connection start and stop. Sometimes they're very handy. Is this a TODO? Is there an API that would make sense for us? I believe it would make sense. But I'm not up to the task to implement it. Maybe if someone is looking into triggers anyway in another context... -- Kaare Rasmussen--Linux, spil,--Tlf:3816 2582 Kaki Datatshirts, merchandize Fax:3816 2501 Howitzvej 75 Åben 12.00-18.00Email: [EMAIL PROTECTED] 2000 FrederiksbergLørdag 12.00-16.00 Web: www.suse.dk ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Stats Collector Error 7.4beta1 and 7.4beta2
I thing I haven't seen asked: is there a packet filter blocking local-local UDP traffic by any chance? Iptables is set to accept everything. If it would help I can give you all log in information to poke around yourselves. I appreciate your help. --- Adam Kavan --- [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] compile warnings in CVS HEAD?
On Wed, Sep 03, 2003 at 10:30:05PM -0400, Tom Lane wrote: tablecmds.c: In function `validateForeignKeyConstraint': tablecmds.c:3546: warning: dereferencing type-punned pointer will break strict-aliasing rules Hm. Got any idea what these are really complaining about? I see no such gripes with the gcc versions I use, but I wouldn't be surprised if gcc 3.3 is trying to tighten up. It's about optimisation. The compiler is free to assume that 2 pointers of a different type never point to the same variable. It basicly happens when you cast a pointer of 1 type to an other. See the gcc info page for a little more information. The recommended way to deal with is to put them into a union. Kurt ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Tom Lane writes: Bruce Momjian [EMAIL PROTECTED] writes: Can we allow the IPv6 entries to be in pg_hba.conf but ignore them on non-IPv6 machines, or allow the connection to fail? I don't see a good way yet. The fly in the ointment is that HAVE_IPV6 is set by configure based on the capabilities of userland libraries; we cannot assume that HAVE_IPV6 means the kernel knows IPv6. But if we simply suppress failure messages on IPv6 addresses, we are going to create severe headaches for people who are actually using IPv6. What is the problem? Is it that a non-IPv6 enabled postmaster is unable to identify or parse valid IPv6 address specifications? In that case, we need to provide some substitute routines. -- Peter Eisentraut [EMAIL PROTECTED] ---(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: [HACKERS] Win32 native port
Joerg Hessdoerfer writes: I'm currently in the process of setting up my development environment (how the heck do I get bison/flex to compile under MingW/MSYS? Oh my...), Use the Cygwin tools. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Seqscan in MAX(index_column)
Greg Stark wrote: It has nothing to do with MVCC. It has to do with implementing this is hard in the general case. Think of examples like: select max(foo) group by bar; or select max(foo) where xyz = z; To do it properly max/min have to be special-cased and tightly integrated with other code to handle index scans and aggregates. As it currently stands they're implemented the same way as any other aggregate, which means they get to see all the records in the grouping. This is a frequently asked question, I'm surprised you didn't find stuff searching with google. There have been numerous long discussions on this topic not long ago. People are still trying to think about how to handle this better. The FAQ does have the example of using ORDER BY LIMIT 1 for MAX(). What we don't have a workaround for is COUNT(*). I think that will require some cached value that obeys MVCC rules of visibility. -- 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: [HACKERS] TCP/IP with 7.4 beta2 broken?
Peter Eisentraut [EMAIL PROTECTED] writes: Bruce Momjian [EMAIL PROTECTED] writes: Can we allow the IPv6 entries to be in pg_hba.conf but ignore them on non-IPv6 machines, or allow the connection to fail? What is the problem? Is it that a non-IPv6 enabled postmaster is unable to identify or parse valid IPv6 address specifications? In that case, we need to provide some substitute routines. To what purpose? I think I prefer Andrew Dunstan's approach of allowing IPv4 syntax in pg_hba.conf to match appropriate IPv6 connections. 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: [HACKERS] Stats Collector Error 7.4beta1 and 7.4beta2
On Thu, Sep 04, 2003 at 01:39:04AM -0400, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Doesn't the stats collector use unix domain sockets, not IP? No. IIRC, we deliberately chose IP/UDP because it had buffering behavior we liked. Once you said it was because not all platforms have unix domain sockets. I asked why we weren't using something like socketpair(). Kurt ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
On Thu, Sep 04, 2003 at 07:18:57PM +0200, Peter Eisentraut wrote: Tom Lane writes: Bruce Momjian [EMAIL PROTECTED] writes: Can we allow the IPv6 entries to be in pg_hba.conf but ignore them on non-IPv6 machines, or allow the connection to fail? I don't see a good way yet. The fly in the ointment is that HAVE_IPV6 is set by configure based on the capabilities of userland libraries; we cannot assume that HAVE_IPV6 means the kernel knows IPv6. But if we simply suppress failure messages on IPv6 addresses, we are going to create severe headaches for people who are actually using IPv6. What is the problem? Is it that a non-IPv6 enabled postmaster is unable to identify or parse valid IPv6 address specifications? In that case, we need to provide some substitute routines. Our replacement getaddrinfo can only read IPv4 addresses. If we need to make it support IPv6 addresses too, we need to define our own struct sockaddr_in6 and AF_INET6, and always use our own version and not the one from the system libs if it has any. There probably is no need for our getaddrinfo replacement function to try to resolve to IPv6 addresses, so it shouldn't be that hard. Kurt ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Win32 native port
Cygwin requires a license for commercial use. -Original Message- From: Peter Eisentraut [mailto:[EMAIL PROTECTED] Sent: Thursday, September 04, 2003 10:20 AM To: Joerg Hessdoerfer Cc: Bruce Momjian; [EMAIL PROTECTED] Subject: Re: [HACKERS] Win32 native port Joerg Hessdoerfer writes: I'm currently in the process of setting up my development environment (how the heck do I get bison/flex to compile under MingW/MSYS? Oh my...), Use the Cygwin tools. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Prelimiary DBT-2 Test results
http://developer.osdl.org/markw/44/ I threw together (kind of sloppily) a web page of the data I was starting to collect for our DBT-2 workload (TPC-C derivative) on PostgreSQL 7.3.4. Keep in mind not much database tuning has been done yet. Feel free to ask any questions. -- Mark Wong - - [EMAIL PROTECTED] Open Source Development Lab Inc - A non-profit corporation 12725 SW Millikan Way - Suite 400 - Beaverton, OR 97005 (503) 626-2455 x 32 (office) (503) 626-2436 (fax) http://www.osdl.org/archive/markw/ ---(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: [HACKERS] ANONCVS? Is it being updated correctly?
I still did NOT pick up any changes :-( Would you like an account on my box or do I need to do a full checkout? LER --On Thursday, September 04, 2003 14:59:32 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: by the time you see this email, it should be fixed ... On Thu, 4 Sep 2003, Larry Rosenman wrote: --On Thursday, September 04, 2003 14:44:07 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: k, I just wipe'd out and rebuild /projects/cvsroot, and it looks like the files are in sync again ... I checked abased on the pltcl.c commit that Tom made at noon today, and the changes are there ... not sure why it wasn't updating properly, bu tlet me know if you see it again ... Now I get this: cvs server: failed to create lock directory for `/projects/cvsroot/pgsql-server' (/projects/cvsroot/pgsql-server/#cvs.lock): Permission denied cvs server: failed to obtain dir lock in repository `/projects/cvsroot/pgsql-server' cvs [server aborted]: read lock failed - giving up $ On Wed, 3 Sep 2003, Larry Rosenman wrote: --On Thursday, September 04, 2003 01:26:29 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: everything looks okay on teh server ...the script is set to run hourly, and there aren't any log files to that can go stale with that one to prevent it from happening ... I just manually ran it .. did that help? Nope. I'm still not seeing Bruce's changes for the threads stuff nor the added tools files. :-( LER On Wed, 3 Sep 2003, Larry Rosenman wrote: Today's commits from Bruce don't seem to be there. I'm doing: cvs update -d -P (I sent another note to Marc as a safety). LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 On Wed, 3 Sep 2003, Larry Rosenman wrote: --On Wednesday, September 03, 2003 23:34:09 -0500 Larry Rosenman [EMAIL PROTECTED] wrote: --On Thursday, September 04, 2003 01:26:29 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: everything looks okay on teh server ...the script is set to run hourly, and there aren't any log files to that can go stale with that one to prevent it from happening ... I just manually ran it .. did that help? Nope. I'm still not seeing Bruce's changes for the threads stuff nor the added tools files. :-( For example, I'm missing this added file: CVSROOT: /cvsroot Module name: pgsql-server Changes by:[EMAIL PROTECTED] 03/09/03 16:30:31 Modified files: src/port : thread.c Added files: src/tools : test_thread_funcs.c Log message: Add test for thread-safeness of libc functions. LER On Wed, 3 Sep 2003, Larry Rosenman wrote: Today's commits from Bruce don't seem to be there. I'm doing: cvs update -d -P (I sent another note to Marc as a safety). LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Bruce Momjian [EMAIL PROTECTED] writes: Can we allow the IPv6 entries to be in pg_hba.conf but ignore them on non-IPv6 machines, or allow the connection to fail? What is the problem? Is it that a non-IPv6 enabled postmaster is unable to identify or parse valid IPv6 address specifications? In that case, we need to provide some substitute routines. To what purpose? I think I prefer Andrew Dunstan's approach of allowing IPv4 syntax in pg_hba.conf to match appropriate IPv6 connections. I am confused. Andrew Dunstan's approach added a new 'loopback' line to pg_hba.conf. Andreas Pflug had the patch that treated IPv4 as IPv6. -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] ANONCVS? Is it being updated correctly?
by the time you see this email, it should be fixed ... On Thu, 4 Sep 2003, Larry Rosenman wrote: --On Thursday, September 04, 2003 14:44:07 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: k, I just wipe'd out and rebuild /projects/cvsroot, and it looks like the files are in sync again ... I checked abased on the pltcl.c commit that Tom made at noon today, and the changes are there ... not sure why it wasn't updating properly, bu tlet me know if you see it again ... Now I get this: cvs server: failed to create lock directory for `/projects/cvsroot/pgsql-server' (/projects/cvsroot/pgsql-server/#cvs.lock): Permission denied cvs server: failed to obtain dir lock in repository `/projects/cvsroot/pgsql-server' cvs [server aborted]: read lock failed - giving up $ On Wed, 3 Sep 2003, Larry Rosenman wrote: --On Thursday, September 04, 2003 01:26:29 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: everything looks okay on teh server ...the script is set to run hourly, and there aren't any log files to that can go stale with that one to prevent it from happening ... I just manually ran it .. did that help? Nope. I'm still not seeing Bruce's changes for the threads stuff nor the added tools files. :-( LER On Wed, 3 Sep 2003, Larry Rosenman wrote: Today's commits from Bruce don't seem to be there. I'm doing: cvs update -d -P (I sent another note to Marc as a safety). LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 On Wed, 3 Sep 2003, Larry Rosenman wrote: --On Wednesday, September 03, 2003 23:34:09 -0500 Larry Rosenman [EMAIL PROTECTED] wrote: --On Thursday, September 04, 2003 01:26:29 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: everything looks okay on teh server ...the script is set to run hourly, and there aren't any log files to that can go stale with that one to prevent it from happening ... I just manually ran it .. did that help? Nope. I'm still not seeing Bruce's changes for the threads stuff nor the added tools files. :-( For example, I'm missing this added file: CVSROOT: /cvsroot Module name: pgsql-server Changes by:[EMAIL PROTECTED] 03/09/03 16:30:31 Modified files: src/port : thread.c Added files: src/tools : test_thread_funcs.c Log message: Add test for thread-safeness of libc functions. LER On Wed, 3 Sep 2003, Larry Rosenman wrote: Today's commits from Bruce don't seem to be there. I'm doing: cvs update -d -P (I sent another note to Marc as a safety). LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Win32 native port
Bruce Momjian wrote: Joerg Hessdoerfer wrote: Hi! Thanks to all who have replied (privately or via the list), it seems sometimes it's just necessary to be a bit insistant! That said, I'm positively surprised by what has been done already (especially Bruce and Marc, this is really a GoodThing to have the web page and the list). I'm currently in the process of setting up my development environment (how the heck do I get bison/flex to compile under MingW/MSYS? Oh my...), and then I'll go adventuring in the code. Thanks again, all. Looking forward to seeing you on the -win32 list. Uh, I should have mentioned that on the web page --- I will now. I normally mount the Unix file via Samba and run everthing from there so I can run bison/flex and CVS from Unix, and just do the compiles via Win32. I have added a Compiling section to the web page: http://candle.pha.pa.us/main/writings/pgsql/win32.html -- 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: [HACKERS] TCP/IP with 7.4 beta2 broken?
Peter Eisentraut wrote: Tom Lane writes: Bruce Momjian [EMAIL PROTECTED] writes: Can we allow the IPv6 entries to be in pg_hba.conf but ignore them on non-IPv6 machines, or allow the connection to fail? I don't see a good way yet. The fly in the ointment is that HAVE_IPV6 is set by configure based on the capabilities of userland libraries; we cannot assume that HAVE_IPV6 means the kernel knows IPv6. But if we simply suppress failure messages on IPv6 addresses, we are going to create severe headaches for people who are actually using IPv6. What is the problem? Is it that a non-IPv6 enabled postmaster is unable to identify or parse valid IPv6 address specifications? In that case, we need to provide some substitute routines. Having parsed it what would it do with it? Surely if IP6 isn't configured in then having an IP6 address in pg_hba.conf is an error. That's why we commented those lines out in the default pg_hba.conf some weeks ago. If Andreas Pflug's patch (with Kurt's caveat) and my patch are applied, then I really think there won't be any more difficulties in this area. cheers andrew ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Tom Lane writes: What is the problem? Is it that a non-IPv6 enabled postmaster is unable to identify or parse valid IPv6 address specifications? In that case, we need to provide some substitute routines. To what purpose? So we can put ::1 in the default pg_hba.conf and have it work on IPv6-enabled hosts by default. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] ANONCVS? Is it being updated correctly?
--On Thursday, September 04, 2003 14:44:07 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: k, I just wipe'd out and rebuild /projects/cvsroot, and it looks like the files are in sync again ... I checked abased on the pltcl.c commit that Tom made at noon today, and the changes are there ... not sure why it wasn't updating properly, bu tlet me know if you see it again ... Now I get this: cvs server: failed to create lock directory for `/projects/cvsroot/pgsql-server' (/projects/cvsroot/pgsql-server/#cvs.lock): Permission denied cvs server: failed to obtain dir lock in repository `/projects/cvsroot/pgsql-server' cvs [server aborted]: read lock failed - giving up $ On Wed, 3 Sep 2003, Larry Rosenman wrote: --On Thursday, September 04, 2003 01:26:29 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: everything looks okay on teh server ...the script is set to run hourly, and there aren't any log files to that can go stale with that one to prevent it from happening ... I just manually ran it .. did that help? Nope. I'm still not seeing Bruce's changes for the threads stuff nor the added tools files. :-( LER On Wed, 3 Sep 2003, Larry Rosenman wrote: Today's commits from Bruce don't seem to be there. I'm doing: cvs update -d -P (I sent another note to Marc as a safety). LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 On Wed, 3 Sep 2003, Larry Rosenman wrote: --On Wednesday, September 03, 2003 23:34:09 -0500 Larry Rosenman [EMAIL PROTECTED] wrote: --On Thursday, September 04, 2003 01:26:29 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: everything looks okay on teh server ...the script is set to run hourly, and there aren't any log files to that can go stale with that one to prevent it from happening ... I just manually ran it .. did that help? Nope. I'm still not seeing Bruce's changes for the threads stuff nor the added tools files. :-( For example, I'm missing this added file: CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/09/03 16:30:31 Modified files: src/port : thread.c Added files: src/tools : test_thread_funcs.c Log message: Add test for thread-safeness of libc functions. LER On Wed, 3 Sep 2003, Larry Rosenman wrote: Today's commits from Bruce don't seem to be there. I'm doing: cvs update -d -P (I sent another note to Marc as a safety). LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] ANONCVS? Is it being updated correctly?
k, I just wipe'd out and rebuild /projects/cvsroot, and it looks like the files are in sync again ... I checked abased on the pltcl.c commit that Tom made at noon today, and the changes are there ... not sure why it wasn't updating properly, bu tlet me know if you see it again ... On Wed, 3 Sep 2003, Larry Rosenman wrote: --On Thursday, September 04, 2003 01:26:29 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: everything looks okay on teh server ...the script is set to run hourly, and there aren't any log files to that can go stale with that one to prevent it from happening ... I just manually ran it .. did that help? Nope. I'm still not seeing Bruce's changes for the threads stuff nor the added tools files. :-( LER On Wed, 3 Sep 2003, Larry Rosenman wrote: Today's commits from Bruce don't seem to be there. I'm doing: cvs update -d -P (I sent another note to Marc as a safety). LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 On Wed, 3 Sep 2003, Larry Rosenman wrote: --On Wednesday, September 03, 2003 23:34:09 -0500 Larry Rosenman [EMAIL PROTECTED] wrote: --On Thursday, September 04, 2003 01:26:29 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: everything looks okay on teh server ...the script is set to run hourly, and there aren't any log files to that can go stale with that one to prevent it from happening ... I just manually ran it .. did that help? Nope. I'm still not seeing Bruce's changes for the threads stuff nor the added tools files. :-( For example, I'm missing this added file: CVSROOT: /cvsroot Module name: pgsql-server Changes by: [EMAIL PROTECTED] 03/09/03 16:30:31 Modified files: src/port : thread.c Added files: src/tools : test_thread_funcs.c Log message: Add test for thread-safeness of libc functions. LER On Wed, 3 Sep 2003, Larry Rosenman wrote: Today's commits from Bruce don't seem to be there. I'm doing: cvs update -d -P (I sent another note to Marc as a safety). LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(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: [HACKERS] PG7.5
Will this have the native Windows port? Marc G. Fournier [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Tue, 2 Sep 2003, postgresql wrote: Hi all Can anyone tell me the approximate pg 7.5 release date? Summer of '04 ... approximate :) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html ---(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: [HACKERS] Win32 native port
Doug McNaught wrote: Dann Corbit [EMAIL PROTECTED] writes: Cygwin requires a license for commercial use. Use in the sense of distributing applications linked against it, yes. In this case I don't think it's a problem. The output of 'flex' and 'bison' is not required to be GPL (there is a specific exception in the Bison license for this), and we're not distributing any Cygwin code, or any binaries linked with it, merely using it to generate parts of the PG source tree. As you can see from the new Compiling web page, I just normally compile under Unix, distclean, then Win32 compile via Samba. -- 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: [HACKERS] Win32 native port
Dann Corbit [EMAIL PROTECTED] writes: Cygwin requires a license for commercial use. Use in the sense of distributing applications linked against it, yes. In this case I don't think it's a problem. The output of 'flex' and 'bison' is not required to be GPL (there is a specific exception in the Bison license for this), and we're not distributing any Cygwin code, or any binaries linked with it, merely using it to generate parts of the PG source tree. -Doug ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] ANONCVS? Is it being updated correctly?
--On Thursday, September 04, 2003 15:35:48 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: k, which file specifically are you expecting a change in? as I said, the changes to pltcl.c that tom did today at noon are in anoncvs now, when I checked ... try doing a full checkout and see if that helps ... ? The src/tools/test_thread stuff, Added files: src/tools : test_thread_funcs.c I'll try a full checkout. LER On Thu, 4 Sep 2003, Larry Rosenman wrote: I still did NOT pick up any changes :-( Would you like an account on my box or do I need to do a full checkout? LER --On Thursday, September 04, 2003 14:59:32 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: by the time you see this email, it should be fixed ... On Thu, 4 Sep 2003, Larry Rosenman wrote: --On Thursday, September 04, 2003 14:44:07 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: k, I just wipe'd out and rebuild /projects/cvsroot, and it looks like the files are in sync again ... I checked abased on the pltcl.c commit that Tom made at noon today, and the changes are there ... not sure why it wasn't updating properly, bu tlet me know if you see it again ... Now I get this: cvs server: failed to create lock directory for `/projects/cvsroot/pgsql-server' (/projects/cvsroot/pgsql-server/#cvs.lock): Permission denied cvs server: failed to obtain dir lock in repository `/projects/cvsroot/pgsql-server' cvs [server aborted]: read lock failed - giving up $ On Wed, 3 Sep 2003, Larry Rosenman wrote: --On Thursday, September 04, 2003 01:26:29 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: everything looks okay on teh server ...the script is set to run hourly, and there aren't any log files to that can go stale with that one to prevent it from happening ... I just manually ran it .. did that help? Nope. I'm still not seeing Bruce's changes for the threads stuff nor the added tools files. :-( LER On Wed, 3 Sep 2003, Larry Rosenman wrote: Today's commits from Bruce don't seem to be there. I'm doing: cvs update -d -P (I sent another note to Marc as a safety). LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 On Wed, 3 Sep 2003, Larry Rosenman wrote: --On Wednesday, September 03, 2003 23:34:09 -0500 Larry Rosenman [EMAIL PROTECTED] wrote: --On Thursday, September 04, 2003 01:26:29 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: everything looks okay on teh server ...the script is set to run hourly, and there aren't any log files to that can go stale with that one to prevent it from happening ... I just manually ran it .. did that help? Nope. I'm still not seeing Bruce's changes for the threads stuff nor the added tools files. :-( For example, I'm missing this added file: CVSROOT: /cvsroot Module name: pgsql-server Changes by: [EMAIL PROTECTED] 03/09/03 16:30:31 Modified files: src/port : thread.c Added files: src/tools : test_thread_funcs.c Log message: Add test for thread-safeness of libc functions. LER On Wed, 3 Sep 2003, Larry Rosenman wrote: Today's commits from Bruce don't seem to be there. I'm doing: cvs update -d -P (I sent another note to Marc as a safety). LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat
Re: [HACKERS] Win32 native port
On Thu, 4 Sep 2003, Dann Corbit wrote: Use the Cygwin tools. Cygwin requires a license for commercial use. It does? I don't see it: http://cygwin.com/licensing.html Jon ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: To what purpose? I think I prefer Andrew Dunstan's approach of allowing IPv4 syntax in pg_hba.conf to match appropriate IPv6 connections. I am confused. Andrew Dunstan's approach added a new 'loopback' line to pg_hba.conf. Andreas Pflug had the patch that treated IPv4 as IPv6. Ah, my mistake. The patch from Andreas seems like a reasonable thing to me. I'm of two minds about 'loopback' --- it's perhaps logically cleaner than referring to 127.0.0.1, but do we want another special case? Also, do we really need it if we add Andreas' patch? I agree we don't need yet another pg_hba.conf keyword, and Andreas' patch handles all IPv4 addresses, not just localhost. Let me load up the patch queue today so everyone can see where we are going. -- 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: To what purpose? I think I prefer Andrew Dunstan's approach of allowing IPv4 syntax in pg_hba.conf to match appropriate IPv6 connections. I am confused. Andrew Dunstan's approach added a new 'loopback' line to pg_hba.conf. Andreas Pflug had the patch that treated IPv4 as IPv6. Ah, my mistake. The patch from Andreas seems like a reasonable thing to me. I'm of two minds about 'loopback' --- it's perhaps logically cleaner than referring to 127.0.0.1, but do we want another special case? Also, do we really need it if we add Andreas' patch? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] ANONCVS? Is it being updated correctly?
k, which file specifically are you expecting a change in? as I said, the changes to pltcl.c that tom did today at noon are in anoncvs now, when I checked ... try doing a full checkout and see if that helps ... ? On Thu, 4 Sep 2003, Larry Rosenman wrote: I still did NOT pick up any changes :-( Would you like an account on my box or do I need to do a full checkout? LER --On Thursday, September 04, 2003 14:59:32 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: by the time you see this email, it should be fixed ... On Thu, 4 Sep 2003, Larry Rosenman wrote: --On Thursday, September 04, 2003 14:44:07 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: k, I just wipe'd out and rebuild /projects/cvsroot, and it looks like the files are in sync again ... I checked abased on the pltcl.c commit that Tom made at noon today, and the changes are there ... not sure why it wasn't updating properly, bu tlet me know if you see it again ... Now I get this: cvs server: failed to create lock directory for `/projects/cvsroot/pgsql-server' (/projects/cvsroot/pgsql-server/#cvs.lock): Permission denied cvs server: failed to obtain dir lock in repository `/projects/cvsroot/pgsql-server' cvs [server aborted]: read lock failed - giving up $ On Wed, 3 Sep 2003, Larry Rosenman wrote: --On Thursday, September 04, 2003 01:26:29 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: everything looks okay on teh server ...the script is set to run hourly, and there aren't any log files to that can go stale with that one to prevent it from happening ... I just manually ran it .. did that help? Nope. I'm still not seeing Bruce's changes for the threads stuff nor the added tools files. :-( LER On Wed, 3 Sep 2003, Larry Rosenman wrote: Today's commits from Bruce don't seem to be there. I'm doing: cvs update -d -P (I sent another note to Marc as a safety). LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 On Wed, 3 Sep 2003, Larry Rosenman wrote: --On Wednesday, September 03, 2003 23:34:09 -0500 Larry Rosenman [EMAIL PROTECTED] wrote: --On Thursday, September 04, 2003 01:26:29 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: everything looks okay on teh server ...the script is set to run hourly, and there aren't any log files to that can go stale with that one to prevent it from happening ... I just manually ran it .. did that help? Nope. I'm still not seeing Bruce's changes for the threads stuff nor the added tools files. :-( For example, I'm missing this added file: CVSROOT:/cvsroot Module name:pgsql-server Changes by: [EMAIL PROTECTED] 03/09/03 16:30:31 Modified files: src/port : thread.c Added files: src/tools : test_thread_funcs.c Log message: Add test for thread-safeness of libc functions. LER On Wed, 3 Sep 2003, Larry Rosenman wrote: Today's commits from Bruce don't seem to be there. I'm doing: cvs update -d -P (I sent another note to Marc as a safety). LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PG7.5
Bupp Phillips wrote: Will this have the native Windows port? We think so. Marc G. Fournier [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Tue, 2 Sep 2003, postgresql wrote: Hi all Can anyone tell me the approximate pg 7.5 release date? Summer of '04 ... approximate :) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html ---(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 -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] PostgreSQL port from DBExperts anybody using it ?
Hi, I was wondering if anybody here has any feedback on the windows version of PostgreSQL from DBExperts. Stability Speed Support Anything else I should know. Thanks -- Patrick McLaughlin Les Logiciels S.I.G.M. Inc. Programmeur analyste ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Peter Eisentraut wrote: Andrew Dunstan writes: Having parsed it what would it do with it? Nothing. Surely if IP6 isn't configured in then having an IP6 address in pg_hba.conf is an error. Arguably, but not surely. If Andreas Pflug's patch (with Kurt's caveat) and my patch are applied, then I really think there won't be any more difficulties in this area. Ignoring that I don't like one of the submitted patches, this still won't get us an pg_hba.conf that works out of the box for sites using IPv6. Please explain a scenario that wouldn't work out of the box. cheers andrew ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Win32 native port
Did you read this: This means that unless you modify the tools so that compiled executables do not make use of the Cygwin library, your compiled programs will also have to be free software distributed under the GPL with source code available to all. And this: Red Hat sells a special Cygwin License for customers who are unable to provide their application in open source code form. For more information, please see: http://www.redhat.com/software/tools/cygwin/, or call 866-2REDHAT ext. 3007 -Original Message- From: Jon Jensen [mailto:[EMAIL PROTECTED] Sent: Thursday, September 04, 2003 11:36 AM To: [EMAIL PROTECTED] Subject: Re: [HACKERS] Win32 native port On Thu, 4 Sep 2003, Dann Corbit wrote: Use the Cygwin tools. Cygwin requires a license for commercial use. It does? I don't see it: http://cygwin.com/licensing.html Jon ---(end of broadcast)--- TIP 8: explain analyze is your friend ---(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: [HACKERS] Win32 native port
On Thu, 4 Sep 2003, Dann Corbit wrote: Did you read this: This means that unless you modify the tools so that compiled executables do not make use of the Cygwin library, your compiled programs will also have to be free software distributed under the GPL with source code available to all. I sure did. My understand was, and someone else already mentioned, that you're just using Cygwin to faciliate the build process, but that the final executable does not use any part of Cygwin at all. Kind of like using GNU Emacs to edit the code, but not including it in the distribution. Maybe I'm wrong on that -- since I haven't and don't plan to build PostgreSQL on Windows, I may have missed something. Jon ---(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
[HACKERS] alternative solution for ipv6 loopback
I just thought of something: For a *real* special case, with no new keywords or other stuff, we could just add something like this to hba.c at the start of the 'host*' section of parse_hba(): #ifndef HAVE_IPV6 if (strcmp(token,::1) == 0 || strcmp(token,::1/128) == 0) return; #endif A bit fragile, but it would allow a default line for the ip6 loopback address that wouldn't break ip4 only postmasters. Any other type of ip6 address would break, as I believe it should. And we wouldn't have to write special routines to handle ip6 addresses where we otherwise don't know about them. cheers andrew ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] ANONCVS? Is it being updated correctly?
The full check out found them :-\ I dunno what was going on. 'k, as I said, for some reason the /projects/cvsroot itself wasn't being updated properly either, so it might be related *shrug* let me know if it happens again, that's all ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Prelimiary DBT-2 Test results
[EMAIL PROTECTED] wrote: http://developer.osdl.org/markw/44/ I threw together (kind of sloppily) a web page of the data I was starting to collect for our DBT-2 workload (TPC-C derivative) on PostgreSQL 7.3.4. Keep in mind not much database tuning has been done yet. Feel free to ask any questions. The kernel readprofile output is very odd: sys_ipc receives lots of hits, but that function is a trivial multiplexer. sys_timedsemop, and try_atomic_semop got 0 hits - that's the main implementation of sysv semaphores. Could you double check your readprofile scripts? -- Manfred ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Stats Collector Error 7.4beta1 and 7.4beta2
Kurt Roeckx wrote: On Thu, Sep 04, 2003 at 01:39:04AM -0400, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Doesn't the stats collector use unix domain sockets, not IP? No. IIRC, we deliberately chose IP/UDP because it had buffering behavior we liked. Once you said it was because not all platforms have unix domain sockets. I asked why we weren't using something like socketpair(). The reason to use INET UDP is that this is the only connection type that simply drops packets if the stupid collector daemon isn't able to keep up with the traffic. Think of a 64 processor SMP machine where 60 backends utilize their own CPU and the poor little collector get's burried in packets, you don't want it to slow down the whole system, do you? And I agree with Tom that it is very likely that the IPV4/IPV6 stuff is the reason. IIRC the postmaster creates the socket and noone ever does bind(2) on it - so it uses it's dynamically assigned port number. Both, the collector and the backends inherit that socket via fork(2). The backends use this socket with it's own sockname to send the stats out, and the collector reads it with recvfrom(2) and verifies that the from address is identical to it's sockname ... that way noone can inject faked stat packets. Now this is a lot of sockname usage that could lead to either the packets not arriving in the collector, or being thrown away by the collector because of failing to see them coming from itself. Jan Kurt ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] PG7.5
its hoped to ... On Mon, 1 Sep 2003, Bupp Phillips wrote: Will this have the native Windows port? Marc G. Fournier [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Tue, 2 Sep 2003, postgresql wrote: Hi all Can anyone tell me the approximate pg 7.5 release date? Summer of '04 ... approximate :) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html ---(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 ---(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: [HACKERS] PG7.5
Bupp Phillips wrote: Will this have the native Windows port? Approximately maybe :-) Jan Marc G. Fournier [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Tue, 2 Sep 2003, postgresql wrote: Hi all Can anyone tell me the approximate pg 7.5 release date? Summer of '04 ... approximate :) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html ---(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 -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Andrew Dunstan writes: Having parsed it what would it do with it? Nothing. Surely if IP6 isn't configured in then having an IP6 address in pg_hba.conf is an error. Arguably, but not surely. If Andreas Pflug's patch (with Kurt's caveat) and my patch are applied, then I really think there won't be any more difficulties in this area. Ignoring that I don't like one of the submitted patches, this still won't get us an pg_hba.conf that works out of the box for sites using IPv6. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] ANONCVS? Is it being updated correctly?
--On Thursday, September 04, 2003 13:39:44 -0500 Larry Rosenman [EMAIL PROTECTED] wrote: --On Thursday, September 04, 2003 15:35:48 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: k, which file specifically are you expecting a change in? as I said, the changes to pltcl.c that tom did today at noon are in anoncvs now, when I checked ... try doing a full checkout and see if that helps ... ? The src/tools/test_thread stuff, Added files: src/tools : test_thread_funcs.c I'll try a full checkout. The full check out found them :-\ I dunno what was going on. Thanks Marc for your time/effort/hosting. LER LER On Thu, 4 Sep 2003, Larry Rosenman wrote: I still did NOT pick up any changes :-( Would you like an account on my box or do I need to do a full checkout? LER --On Thursday, September 04, 2003 14:59:32 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: by the time you see this email, it should be fixed ... On Thu, 4 Sep 2003, Larry Rosenman wrote: --On Thursday, September 04, 2003 14:44:07 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: k, I just wipe'd out and rebuild /projects/cvsroot, and it looks like the files are in sync again ... I checked abased on the pltcl.c commit that Tom made at noon today, and the changes are there ... not sure why it wasn't updating properly, bu tlet me know if you see it again ... Now I get this: cvs server: failed to create lock directory for `/projects/cvsroot/pgsql-server' (/projects/cvsroot/pgsql-server/#cvs.lock): Permission denied cvs server: failed to obtain dir lock in repository `/projects/cvsroot/pgsql-server' cvs [server aborted]: read lock failed - giving up $ On Wed, 3 Sep 2003, Larry Rosenman wrote: --On Thursday, September 04, 2003 01:26:29 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: everything looks okay on teh server ...the script is set to run hourly, and there aren't any log files to that can go stale with that one to prevent it from happening ... I just manually ran it .. did that help? Nope. I'm still not seeing Bruce's changes for the threads stuff nor the added tools files. :-( LER On Wed, 3 Sep 2003, Larry Rosenman wrote: Today's commits from Bruce don't seem to be there. I'm doing: cvs update -d -P (I sent another note to Marc as a safety). LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 On Wed, 3 Sep 2003, Larry Rosenman wrote: --On Wednesday, September 03, 2003 23:34:09 -0500 Larry Rosenman [EMAIL PROTECTED] wrote: --On Thursday, September 04, 2003 01:26:29 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: everything looks okay on teh server ...the script is set to run hourly, and there aren't any log files to that can go stale with that one to prevent it from happening ... I just manually ran it .. did that help? Nope. I'm still not seeing Bruce's changes for the threads stuff nor the added tools files. :-( For example, I'm missing this added file: CVSROOT: /cvsroot Module name: pgsql-server Changes by: [EMAIL PROTECTED] 03/09/03 16:30:31 Modified files: src/port : thread.c Added files: src/tools : test_thread_funcs.c Log message: Add test for thread-safeness of libc functions. LER On Wed, 3 Sep 2003, Larry Rosenman wrote: Today's commits from Bruce don't seem to be there. I'm doing: cvs update -d -P (I sent another note to Marc as a safety). LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 8: explain analyze is your friend -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905
Re: [HACKERS] Win32 native port
Bruce Momjian writes: As you can see from the new Compiling web page, I just normally compile under Unix, distclean, then Win32 compile via Samba. That isn't very efficient unless you have two machines or use something like vmware. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Stats Collector Error 7.4beta1 and 7.4beta2
Kurt Roeckx wrote: It could be useful to have a warning at the following line: if (memcmp(fromaddr, pgStatAddr, fromlen)) continue; That way you can rule out that that is a problem. Anyway, I still didn't see the error message he got in the first place. Maybe we're looking at the wrong thing? I think it's more this piece of code in postmaster/pgstat.c /* * The source address of the packet must be our own socket. * This ensures that only real hackers or our own backends * tell us something. (This should be redundant with a * kernel-level check due to having used connect(), but let's * do it anyway.) */ if (memcmp(fromaddr, pgStatAddr, fromlen)) continue; Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Win32 native port
On Thu, Sep 04, 2003 at 12:27:58PM -0700, Dann Corbit wrote: Did you read this: This means that unless you modify the tools so that compiled executables do not make use of the Cygwin library, your compiled programs will also have to be free software distributed under the GPL with source code available to all. Basicly this means that if you're linked to cygwin1.dll, you have to release your program under the GPL, else there is no restriction. It's just as normal gcc, it's not because you use gcc to compile your program that your program has to be under the GPL too. Kurt ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Win32 native port
-Original Message- From: Jon Jensen [mailto:[EMAIL PROTECTED] Sent: Thursday, September 04, 2003 4:32 PM To: [EMAIL PROTECTED] Subject: Re: [HACKERS] Win32 native port On Thu, 4 Sep 2003, Dann Corbit wrote: Did you read this: This means that unless you modify the tools so that compiled executables do not make use of the Cygwin library, your compiled programs will also have to be free software distributed under the GPL with source code available to all. I am fairly certain that (in English) this paragraph reads: if your software needs Cygwin.dll to run (or is static linked to cygwin runtime libraries), it is GPL software. I agree, I think cygwin flex and bison can be used without any licensing issues. We are only concerned with the output of the software generated from non-GPL input (another way of looking at it, do GPL work processors produce only GPL documents?? viral, indeed!). Merlin ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Win32 native port
-Original Message- From: Jon Jensen [mailto:[EMAIL PROTECTED] Sent: Thursday, September 04, 2003 1:32 PM To: [EMAIL PROTECTED] Subject: Re: [HACKERS] Win32 native port On Thu, 4 Sep 2003, Dann Corbit wrote: Did you read this: This means that unless you modify the tools so that compiled executables do not make use of the Cygwin library, your compiled programs will also have to be free software distributed under the GPL with source code available to all. I sure did. My understand was, and someone else already mentioned, that you're just using Cygwin to faciliate the build process, but that the final executable does not use any part of Cygwin at all. Kind of like using GNU Emacs to edit the code, but not including it in the distribution. Maybe I'm wrong on that -- since I haven't and don't plan to build PostgreSQL on Windows, I may have missed something. That may be the intent. But it does not agree with the wording. I think it would be dangerous to use it. Consider this fragment: This means that unless you modify the tools so that compiled executables do not make use of the Cygwin library,... What are: 1. 'the tools' Are these the Cygwin tools? Are they your tools? Some combination? 2. 'compiled executables' The cygwin executables? Your executables? Both? 3. 'the Cygwin library' The library for cygwin1.dll? _All_ libraries distributed with Cygwin? Something else? All of these are extremely ambiguous. Are you willing to risk your company's safety on your personal interpretation? I have similar problems with the reading of the LGPL. The reading of the actual contract words can give interpretations far more harsh than the supposed original intent. A reasonable interpretation can mean that LGPL is not different than GPL at all. ---(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: [HACKERS] Stats Collector Error 7.4beta1 and 7.4beta2
On Thu, Sep 04, 2003 at 05:01:54PM -0400, Jan Wieck wrote: Kurt Roeckx wrote: It could be useful to have a warning at the following line: if (memcmp(fromaddr, pgStatAddr, fromlen)) continue; That way you can rule out that that is a problem. Anyway, I still didn't see the error message he got in the first place. Maybe we're looking at the wrong thing? I think it's more this piece of code in postmaster/pgstat.c And what do you think I pasted? Kurt ---(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: [HACKERS] Stats Collector Error 7.4beta1 and 7.4beta2
On Thu, Sep 04, 2003 at 04:04:38PM -0400, Jan Wieck wrote: And I agree with Tom that it is very likely that the IPV4/IPV6 stuff is the reason. IIRC the postmaster creates the socket and noone ever does bind(2) on it - so it uses it's dynamically assigned port number. Both, the collector and the backends inherit that socket via fork(2). Actually, it does a bind (to localhost), but send the port to 0, so it gets the random port. Then it connects to itself. I don't get the logic behind that howver. It does: pgStatSock = socket(...); bind(pgStatSock, ...); getsockname(pgStatSock, ...); connect(pgStatSock, ...); So it creates a socket, binds to it, asks what address/port it's bound to, and connects to that port. I don't see the logic behind that connect(), how it can work, and how it would block anybody from sending to it, but it seems to work. The backends use this socket with it's own sockname to send the stats out, and the collector reads it with recvfrom(2) and verifies that the from address is identical to it's sockname ... that way noone can inject faked stat packets. Now this is a lot of sockname usage that could lead to either the packets not arriving in the collector, or being thrown away by the collector because of failing to see them coming from itself. I'm trying to think about some kernel bug that sends packets using the wrong source address ..., but I think that was connecting to a local address it always showed the loopback address. It could be useful to have a warning at the following line: if (memcmp(fromaddr, pgStatAddr, fromlen)) continue; That way you can rule out that that is a problem. Anyway, I still didn't see the error message he got in the first place. Maybe we're looking at the wrong thing? Kurt ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Win32 native port
Dann Corbit wrote: -Original Message- From: Jon Jensen [mailto:[EMAIL PROTECTED] Sent: Thursday, September 04, 2003 1:32 PM To: [EMAIL PROTECTED] Subject: Re: [HACKERS] Win32 native port On Thu, 4 Sep 2003, Dann Corbit wrote: Did you read this: This means that unless you modify the tools so that compiled executables do not make use of the Cygwin library, your compiled programs will also have to be free software distributed under the GPL with source code available to all. I sure did. My understand was, and someone else already mentioned, that you're just using Cygwin to faciliate the build process, but that the final executable does not use any part of Cygwin at all. Kind of like using GNU Emacs to edit the code, but not including it in the distribution. Maybe I'm wrong on that -- since I haven't and don't plan to build PostgreSQL on Windows, I may have missed something. That may be the intent. But it does not agree with the wording. I think it would be dangerous to use it. Consider this fragment: This means that unless you modify the tools so that compiled executables do not make use of the Cygwin library,... What are: 1. 'the tools' Are these the Cygwin tools? Are they your tools? Some combination? 2. 'compiled executables' The cygwin executables? Your executables? Both? 3. 'the Cygwin library' The library for cygwin1.dll? _All_ libraries distributed with Cygwin? Something else? All of these are extremely ambiguous. Are you willing to risk your company's safety on your personal interpretation? I have similar problems with the reading of the LGPL. The reading of the actual contract words can give interpretations far more harsh than the supposed original intent. A reasonable interpretation can mean that LGPL is not different than GPL at all. You have quoted out of context. Before the clause you quoted it says this: By default, all executables link against this library (and in the process include GPL'd Cygwin glue code). Native pg will NOT be linked against any cygwin libraries at all, and so the following sentence which you quote does not apply. Furthermore, there is a specific exemption below that says this: --- In accordance with section 10 of the GPL, Red Hat permits programs whose sources are distributed under a license that complies with the Open Source definition to be linked with libcygwin.a without libcygwin.a itself causing the resulting program to be covered by the GNU GPL. This means that you can port an Open Source(tm) application to cygwin, and distribute that executable as if it didn't include a copy of libcygwin.a linked into it. Note that this does not apply to the cygwin DLL itself. If you distribute a (possibly modified) version of the DLL you must adhere to the terms of the GPL, i.e. you must provide sources for the cygwin DLL. See http://www.opensource.org/docs/definition_plain.html for the precise Open Source Definition referenced above. -- So even if we did link against libcygwin.a we'd be home free. If there's any doubt (I have none) perhaps someone would like to contact RedHat for a clarification. cheers andrew ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Stats Collector Error 7.4beta1 and 7.4beta2
It could be useful to have a warning at the following line: if (memcmp(fromaddr, pgStatAddr, fromlen)) continue; That way you can rule out that that is a problem. Anyway, I still didn't see the error message he got in the first place. Maybe we're looking at the wrong thing? Kurt This is the very line that is giving me problems. I commented it out and recompiled and now the stats system works. Of course I have to assume that its bad to go around with out that check... --- Adam Kavan --- [EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Win32 native port
-Original Message-
From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 04, 2003 2:35 PM
To: Postgresql Hackers
Subject: Re: [HACKERS] Win32 native port
Dann Corbit wrote:
-Original Message-
From: Jon Jensen [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 04, 2003 1:32 PM
To: [EMAIL PROTECTED]
Subject: Re: [HACKERS] Win32 native port
On Thu, 4 Sep 2003, Dann Corbit wrote:
Did you read this:
This means that unless you modify the tools so that compiled
executables do not make use of the Cygwin library, your compiled
programs will also have to be free software distributed
under the GPL
with source code available to all.
I sure did. My understand was, and someone else already
mentioned, that you're just using Cygwin to faciliate the
build process, but that the final executable does not use any
part of Cygwin at all. Kind of like using GNU Emacs to edit
the code, but not including it in the distribution. Maybe I'm
wrong on that -- since I haven't and don't plan to build
PostgreSQL on Windows, I may have missed something.
That may be the intent. But it does not agree with the wording. I
think it would be dangerous to use it.
Consider this fragment:
This means that unless you modify the tools so that compiled
executables do not make use of the Cygwin library,... What are:
1. 'the tools'
Are these the Cygwin tools? Are they your tools? Some combination?
2. 'compiled executables'
The cygwin executables? Your executables? Both?
3. 'the Cygwin library'
The library for cygwin1.dll? _All_ libraries distributed
with Cygwin?
Something else?
All of these are extremely ambiguous. Are you willing to risk your
company's safety on your personal interpretation?
I have similar problems with the reading of the LGPL. The
reading of
the actual contract words can give interpretations far more
harsh than
the supposed original intent. A reasonable interpretation can mean
that LGPL is not different than GPL at all.
You have quoted out of context. Before the clause you quoted
it says this:
By default, all executables link against this library (and in the
process include GPL'd Cygwin glue code).
Native pg will NOT be linked against any cygwin libraries at
all, and so
the following sentence which you quote does not apply.
You are making an assumption that the follwing sentence is only valid
under conditions of the first. That is nowhere stated. That connection
is only implied by your interpretation.
Furthermore, there is a specific exemption below that says this:
---
In accordance with section 10 of the GPL, Red Hat permits
programs whose
sources are distributed under a license that complies with the Open
Source definition to be linked with libcygwin.a without libcygwin.a
itself causing the resulting program to be covered by the GNU GPL.
This means that you can port an Open Source(tm) application
to cygwin,
and distribute that executable as if it didn't include a copy of
libcygwin.a linked into it. Note that this does not apply to
the cygwin
DLL itself. If you distribute a (possibly modified) version
of the DLL
you must adhere to the terms of the GPL, i.e. you must
provide sources
for the cygwin DLL.
See http://www.opensource.org/docs/definition_plain.html for
the precise
Open Source Definition referenced above.
--
And yet above in the original link it specifies that the open source
project must be GPL.
This means that unless you modify the tools so that compiled
executables do not make use of the Cygwin library, your compiled
programs will also have to be free software DISTRIBUTED UNDER THE GPL
with source code available to all. {emphasis mine}
So even if we did link against libcygwin.a we'd be home free.
If there's any doubt (I have none) perhaps someone would like
to contact
RedHat for a clarification.
cheers
andrew
Even a trivial and absurd lawsuit can have disastrous consequences.
Consider SCO verses IBM.
---(end of broadcast)---
TIP 8: explain analyze is your friend
[HACKERS] plpython
Greetings, I've recently been spending some quality time with the plpython module, and I think I'm well on the road to an improved version of it(although, nothing about a trusted variant). By improved, I mostly mean cleaned up, and reorganized.. Here are some of the changes that I have made in my own version: Compilation and execution have been greatly simplified and should be faster(at least execution should be). Caching of compiled code no longer references a Python dictionary(PLyProcedureCache). The handler keeps its own vector of procedure structs(should be faster, and is trivial). Removal of plpython generated dictionaries SD and GD. They don't seem be very useful, as they are forgotten when the postmaster exits and not remembered when a new one starts. SD is questionable, does/did anyone find SD very useful? GD seems almost pointless as the global keyword should be sufficient. Although, I do think there was a mention of GD being safe globals, but I don't know why it would be safer than global var. Removal of the built-in plpy python module that plpython creates. This is done because it provides interfaces to pgsql functions that I feel should be located elsewhere; elsewhere being another python module. I've already generated a preliminary interface to elog and SPI_* with SWIG that at first glance seems quite functional(it links, and is at least able to properly call elog, I haven't really tested SPI). Improvement to tracebacks, as it now NOTICE's the python tracebacks(There is already an ERROR, so I don't think WARNING is necessary). PLy_traceback, originally, seemed to ignore the tb of the PyErr_Fetch. Removal of plpython type conversion routines and data structures. This was done because I felt that there was a better way to do it. Not sure what yet, as it is one of my questions to the list, but it will probably end up being a similar implementation. I also plan to make some changes to trigger handling, but I haven't done anything worth mentioning yet.. Type conversion plpython's current type conversion implementation appears to be dependent on strings as the common format. This is fine, but not very extensible as is, unless you don't mind explicitly parsing strings inside each function that takes an unsupported data type. I was thinking that a better solution would be creating a python object type inside the database. Thus allowing users to write casts to and from non-standard or unimplemented data types with little difficulty(well, maybe some :). This would allow conversion in an extensible way, which doesn't require modification to plpython. Storage could be easily achieved by pickling the object. Another thought would be to just pass valid PyObject pointers in and out of conversion procedures, effectively disallowing storage(outside the process in which the object was created in), unless it is possible to have a persistent storage mechanism that makes it possible to go through pickle?.?..(yeah, I'm new to pgsql dev). Python PostgreSQL Interface plpython, currently, implements its own built-in module to interface with a few pgsql routines, and it works, but I feel it should be located elsewhere, as I said before. For the most part, I can only see most people using elog, and SPI within plpy, but perhaps that is too narrow of a view. Perhaps it would be useful to many to have access to some backend routines through plpy, but I'm not sure and that is why I'm asking the list. How far should such an PostgreSQL interface module go? What should its name be if full/semi-full interface is created? I was thinking simply py-pgsql as the package name, and the module name, of course, would be pgsql. What should the name be if it was only elog and SPI? py-pgspi? I'm leaning towards py-pgsql, a partial interface consisting of elog and SPI and perhaps a few other useful routines. But have the module as a package as to allow easy extensions to the package as subpackages.. From this interface, a DB-API 2.0 compatible SPI interface will come as well. My version has a short ways to go before it is ready for usage, but if you want to see what I've done, just drop me an e-mail. Comments? Criticisms? Feature suggestions? Anyone else doing significant work on plpython? -James pgp0.pgp Description: PGP signature
Re: [HACKERS] Win32 native port
Peter Eisentraut wrote: Bruce Momjian writes: As you can see from the new Compiling web page, I just normally compile under Unix, distclean, then Win32 compile via Samba. That isn't very efficient unless you have two machines or use something like vmware. One quick solution would be to add the bison/flex output files to the WIN32_DEV CVS tree. Do people want 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] Another small bug (pg_autovacuum)
Now that I have pg_autovacuum working I've bumped into another small bug. When pg_autovacuum goes to vacuum or analyze one of my tables it runs... analyze public.ConfigBackup Because ConfigBackup is mixed case it cannot find the relation. I fixed this by going to the function init_table_info and increasing the malloc for new_tbl-table_name by 2 and adding 's to either side of the table name. Is there anything wrong with this approach? Is there a config I can set to make this non-case sensitive? Thanks again for your time. --- Adam Kavan --- [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Stats Collector Error 7.4beta1 and 7.4beta2
Adam Kavan [EMAIL PROTECTED] writes: if (memcmp(fromaddr, pgStatAddr, fromlen)) continue; This is the very line that is giving me problems. I commented it out and recompiled and now the stats system works. Of course I have to assume that its bad to go around with out that check... Hmm. Could you look and see what the actual values are in each address? regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] tablelevel and rowlevel locks
[ pgsql-general removed from cc list, as this is quite inappropriate there ] Jenny - [EMAIL PROTECTED] writes: I am working on a project that involves displaying locking information about each lock taken, whether it be a row level or table leve llock. When dealing with struct LOCK (src/include/storage) i have noticed that postgreSQL creates a single LOCK struct for each table in the db. Like if i acquire 2 seperate row level locks on 2 seperate rows, both these locks are represented in the same struct LOCK datastructure . As has been pointed out to you several times already, the LOCK structures aren't used for row-level locks. The objects that you are looking at represent table-level locks. For example, after BEGIN; SELECT * FROM foo WHERE id IN (1,2) FOR UPDATE; there will be a table-level AccessShareLock on foo that was acquired (and not released) by the SELECT statement as a whole. If there actually were rows matching the WHERE clause, the locks on them are represented by modifying their tuple headers on-disk. There is nothing about individual rows in the LOCK table. Now, if you have modified the code with the intention of creating LOCK entries for row-level locks, then all I can say is you didn't do it right. The LockTag created to represent a row-level lock should be distinct from a table-level LockTag (or a page-level LockTag for that matter). If it is, the hash table will definitely store it as a separate object. 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: [HACKERS] Win32 native port
Dann Corbit wrote: You are making an assumption that the follwing sentence is only valid under conditions of the first. That is nowhere stated. That connection is only implied by your interpretation. Not at all. the phrase This means clearly refers to what went before. Even a trivial and absurd lawsuit can have disastrous consequences. Consider SCO verses IBM. Fine. You sit quaking with fear in your boots. I won't. BTW, according to my legal theory *I* own all the code to Postgres. Bizarre? Sure, but don't let that stop you worrying about it. One more thing - there is a Cygwin port of Postgres that *is* linked against Cygwin libraries - I haven't heard anybody suggesting that that has infected us with GPLing the code. Let's get real. andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Question about Scripting in Postgresql.
Here is the problem I have some key tables that I need to import some data into it.I can't go ahead and write insert into table value()for over 40 different tables and over 100s of rows and columns The reason that I have to write a script to enter the data into the tables is that what if I have to enter 1000 lines of data into 200 rows?? here is a piece of my script that works but not when I enter lets' say a char instead of integer. = copy accounts from stdin using delimiters ','; 1,pass,mac,,, 2,pass2,mac2,ip,test 0,pass2,mac2,ip,test2 \. === P.S: also I have used the tab delimiter. I have written a script to import some data into my database tables, with the delimiter ','. Now my question is sometime the data being sent to my tables might not match the data type or be corrupted and I receive an error message. One: how could I prevent that? Two: how can I proceed with importing the rest of the data into the next record even though some are corrupted,'cause I get intrupted as soon as there is an error in inserting the data? __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ---(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: [HACKERS] Stats Collector Error 7.4beta1 and 7.4beta2
At 06:49 PM 9/4/03 -0400, Tom Lane wrote: Hmm. Could you look and see what the actual values are in each address? regards, tom lane I don't really know the layout of these structures so I dumped them to a file and attached them. The first 16 bytes is from fromaddr and the second is from pgStatAddr. --- Adam Kavan --- [EMAIL PROTECTED] socketinfo Description: Binary data ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Stats Collector Error 7.4beta1 and 7.4beta2
Kurt Roeckx wrote: On Thu, Sep 04, 2003 at 05:01:54PM -0400, Jan Wieck wrote: Kurt Roeckx wrote: It could be useful to have a warning at the following line: if (memcmp(fromaddr, pgStatAddr, fromlen)) continue; That way you can rule out that that is a problem. Anyway, I still didn't see the error message he got in the first place. Maybe we're looking at the wrong thing? I think it's more this piece of code in postmaster/pgstat.c And what do you think I pasted? Hmmm ... good question ... How can I know what I think before I read what I write? Jan :-) Kurt -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Seqscan in MAX(index_column)
Bruce Momjian wrote: Greg Stark wrote: It has nothing to do with MVCC. It has to do with implementing this is hard in the general case. Think of examples like: select max(foo) group by bar; or select max(foo) where xyz = z; To do it properly max/min have to be special-cased and tightly integrated with other code to handle index scans and aggregates. As it currently stands they're implemented the same way as any other aggregate, which means they get to see all the records in the grouping. This is a frequently asked question, I'm surprised you didn't find stuff searching with google. There have been numerous long discussions on this topic not long ago. People are still trying to think about how to handle this better. The FAQ does have the example of using ORDER BY LIMIT 1 for MAX(). What we don't have a workaround for is COUNT(*). I think that will require some cached value that obeys MVCC rules of visibility. IMHO portability is an important point. People are used to MAX() and COUNT(*), and will be surprised that they need some special treatment. While the reasons for this are perfectly explainable, speeding up these aggregates with some extra effort would make porting a bit easier. Regards, Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Stats Collector Error 7.4beta1 and 7.4beta2
They are both structures of type sockaddr_in (sin_family 2 is AF_INET whereas sin_family 10 would've been AF_INET6), and all relevant fields of the structure look the same to me. The problem lies in the padding bytes that make sockaddr_in the same size as sockaddr. Since the static structure pgStatAddr is supposed to be initialized to nul bytes by the compiler and now does not contain those in the padding area, my guess would be that getsockaddr() is actually writing garbage into that padding area. This is a nasty change, as one cannot compare two addresses for equalness with memcmp() any more just because of sloppy programming in the IP stack. Well, the correct fix would be to compare only the relevant parts of the addresses, depending on the address family type. I personally wouldn't worry too much about removing the check entirely. If you got a hacker wasting his time and bandwidth with screwing up your statistic collector daemon by sending faked UDP packets to some guessed port number (it's only visible in the netstat output on your local machine), I think he's done with all the rest of his TODO for the day and you'll soon face other problems than that. Jan Adam Kavan wrote: At 06:49 PM 9/4/03 -0400, Tom Lane wrote: Hmm. Could you look and see what the actual values are in each address? regards, tom lane I don't really know the layout of these structures so I dumped them to a file and attached them. The first 16 bytes is from fromaddr and the second is from pgStatAddr. --- Adam Kavan --- [EMAIL PROTECTED] -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [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: [HACKERS] Stats Collector Error 7.4beta1 and 7.4beta2
Adam Kavan [EMAIL PROTECTED] writes: I don't really know the layout of these structures so I dumped them to a file and attached them. The first 16 bytes is from fromaddr and the second is from pgStatAddr. More legibly: 000 0200 8016 7f00 0001 010 0200 8016 7f00 0001 f001 The 7f01 is the IP loopback address, sure enough. I wonder what the f001 (or it might be little-endian 01f0) is. 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: [HACKERS] SET CONSTRAINTS and like named constraints
Stephan Szabo wrote: It looks like that right now if you have multiple constraints with the same name on different tables and some are deferrable and some are not, SET CONSTRAINTS name DEFERRED will fail when it reaches the not deferrable constraint. Is this the behavior we want, or do we want it to defer the deferrable ones with that name and possibly warn that some were not deferrable? We have this TODO: * Allow SET CONSTRAINTS to be qualified by schema/table -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Stats Collector Error 7.4beta1 and 7.4beta2
Kurt Roeckx [EMAIL PROTECTED] writes: Then it connects to itself. I don't get the logic behind that howver. At least on HPUX, the connect(2) man page saith If the socket is of type SOCK_DGRAM, connect() specifies the peer address to which messages are to be sent, and the call returns immediately. Furthermore, this socket can only receive messages sent from this address. The furthermore is what we are after. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] set constraints docs page
Kevin Brown wrote: Bruce Momjian wrote: Kevin Brown wrote: The two approaches aren't necessarily mutually exclusive (though SQL99 compliance on constraint names would obviously make it unnecessary to specify a tablename along with a constraint name), so I see little problem here. But the current arrangement is obviously untenable, because it allows you to create a situation (multiple constraints by the same name) that you can't reasonably extricate yourself from. Well, it seems if we want to continue to allow the same constraint name to be used by different tables in the same schema, we have to print the tablename in the error message. Would someone actually be looking for a standards-compliant error string? We have already extended the standard --- either we revert that, or we have to go the entire way and print the table name. If PG were configurable in terms of how it manages constraint names, then it would depend on how the DBA had the database configured. With it configured to disallow name collisions, it would obviously be unnecessary to report the table name, though I still think it would be useful (if only because it gives a little extra context to work with). But if it's configured to allow name collisions, then it doesn't make sense not to print the table name in an error message, because that's the only way to guarantee that the DBA can identify which constraint is being referred to. The problem as things stand now is that even if we printed the table name involved, the DBA is placed in a difficult position if the constraint in question isn't uniquely named -- which is the only case where printing the table name would really matter. That's because he can't actually refer to the constraint in any unique way short of playing with the system tables; he'd have to rename the constraint first before being able to really do something with it (is this even possible for him to do without manipulating system tables? Is there an ALTER CONSTRAINT?). Added to TODO: * Print table names with constraint names in error messages, or make constraint names unique within a schema -- 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: [HACKERS] set constraints docs page
Bruce Momjian wrote: Added to TODO: * Print table names with constraint names in error messages, or make constraint names unique within a schema Should the TODO also include adding ALTER TABLE x ALTER CONSTRAINT y RENAME TO z functionality if we don't make constraint names unique within a schema? -- Kevin Brown [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] SET CONSTRAINTS and like named constraints
On Thu, 4 Sep 2003, Bruce Momjian wrote: Stephan Szabo wrote: It looks like that right now if you have multiple constraints with the same name on different tables and some are deferrable and some are not, SET CONSTRAINTS name DEFERRED will fail when it reaches the not deferrable constraint. Is this the behavior we want, or do we want it to defer the deferrable ones with that name and possibly warn that some were not deferrable? We have this TODO: * Allow SET CONSTRAINTS to be qualified by schema/table I'd think the above is in addition to the TODO item. We should define the behavior for unqualified constraint names. I can see a few possibilities for the behavior of SET CONSTRAINTS DEFERRED a) The current behavior. If an unqualified constraint name matches multiple constraints and any of those constraints are non-deferrable it is an error, otherwise all matching constraints are deferred. b) The above behavior. If an unqualified constraint name matches multiple constraints and all of those constraints are non-deferrable it is an error, otherwise all matching deferrable constraints are deferred (possibly with a warning if any are non-deferrable). c) If an unqualified constraint name matches multiple constraints it is an error (presumably for set ... immediate as well). a is the easiest to do probably since it's what's there right now. It's also compatible with how we do things now. b is closer to what I think people might expect it to do and allows more than what we do now (so presumably the only people that would be bitten by it on upgrade are people that are getting errors right now). c is the safest option for preventing someone from doing something they don't want, but is the least compatible with what we have now. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] set constraints docs page
Kevin Brown wrote: Bruce Momjian wrote: Added to TODO: * Print table names with constraint names in error messages, or make constraint names unique within a schema Should the TODO also include adding ALTER TABLE x ALTER CONSTRAINT y RENAME TO z functionality if we don't make constraint names unique within a schema? Added to TODO: o Allow ALTER TABLE ... ALTER CONSTRAINT ... RENAME -- 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: [HACKERS] SET CONSTRAINTS and like named constraints
Stephan Szabo wrote: On Thu, 4 Sep 2003, Bruce Momjian wrote: Stephan Szabo wrote: It looks like that right now if you have multiple constraints with the same name on different tables and some are deferrable and some are not, SET CONSTRAINTS name DEFERRED will fail when it reaches the not deferrable constraint. Is this the behavior we want, or do we want it to defer the deferrable ones with that name and possibly warn that some were not deferrable? We have this TODO: * Allow SET CONSTRAINTS to be qualified by schema/table I'd think the above is in addition to the TODO item. We should define the behavior for unqualified constraint names. I can see a few possibilities for the behavior of SET CONSTRAINTS DEFERRED a) The current behavior. If an unqualified constraint name matches multiple constraints and any of those constraints are non-deferrable it is an error, otherwise all matching constraints are deferred. b) The above behavior. If an unqualified constraint name matches multiple constraints and all of those constraints are non-deferrable it is an error, otherwise all matching deferrable constraints are deferred (possibly with a warning if any are non-deferrable). c) If an unqualified constraint name matches multiple constraints it is an error (presumably for set ... immediate as well). a is the easiest to do probably since it's what's there right now. It's also compatible with how we do things now. b is closer to what I think people might expect it to do and allows more than what we do now (so presumably the only people that would be bitten by it on upgrade are people that are getting errors right now). c is the safest option for preventing someone from doing something they don't want, but is the least compatible with what we have now. Right, what we do when we reference an unqualified constraint name is to apply the command to all of them and abort if any of them fail. If you can get agreement to change that, I will add it to the TODO. -- 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
[HACKERS] psql \h alter scrolls of screen
When I do '\h alter' in psql, the content scrolls off my screen. Should we be using the pager for \h output? -- 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] TCP/IP with 7.4 beta2 broken?
Andrew Dunstan [EMAIL PROTECTED] writes: There's a lot of confusion around :-) Let me see if I can disentangle some of it. People seem to want two things: 1. if ip4 is being tunneled over ip6 as it is in most Linux distributions, match a corresponding 'host*' line with an ip4 address. 2. enable local connections of whatever flavor by default. Sounds right to me. Andreas has addressed item 1. I suggested an approach to item 2. The only alternative I can see is to allow ip4-only postmasters to recognize and silently drop ip6 'host*' lines. I don't like the idea of silently ignoring config lines - it seems dangerous to me. Suggestions of having initdb or something similar conditionally set the default pg_hba.conf also strike me as impractical and fragile. Bruce and I were just discussing this on the phone. It seems we have two basic approaches to problem #2. Either we hack the postmaster so that it will swallow IPv6 addresses in pg_hba.conf even without any real IPv6 support, or we make the default pg_hba.conf contents different. Neither of these is real pretty, but I am leaning to the second, because I agree with your feeling that silently ignoring config lines is a bad idea. I do not believe that there's anything fragile about having initdb make this adjustment. We can arrange for initdb to be aware of the HAVE_IPV6 compilation flag (its value can be inserted when initdb is made from initdb.sh, the same way some other configuration items are already inserted into the script). As far as I can see, HAVE_IPV6 is exactly what we want to look at to decide whether to put ::1 into pg_hba.conf. If we HAVE_IPV6, then the postmaster can parse ::1. Whether the kernel has IPv6 enabled doesn't matter --- if not, it would only mean that the postmaster will never actually see a connection from ::1; so the pg_hba.conf entry will never be matched. But it won't hurt anything. Conversely, if we don't HAVE_IPV6, we can't parse ::1 ... but we don't need to, even if the kernel has IPv6, because such a postmaster won't try to listen for AF_INET6 connections. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Seqscan in MAX(index_column)
The world rejoiced as [EMAIL PROTECTED] (Andreas Pflug) wrote: Bruce Momjian wrote: Greg Stark wrote: It has nothing to do with MVCC. It has to do with implementing this is hard in the general case. Think of examples like: select max(foo) group by bar; or select max(foo) where xyz = z; To do it properly max/min have to be special-cased and tightly integrated with other code to handle index scans and aggregates. As it currently stands they're implemented the same way as any other aggregate, which means they get to see all the records in the grouping. This is a frequently asked question, I'm surprised you didn't find stuff searching with google. There have been numerous long discussions on this topic not long ago. People are still trying to think about how to handle this better. The FAQ does have the example of using ORDER BY LIMIT 1 for MAX(). What we don't have a workaround for is COUNT(*). I think that will require some cached value that obeys MVCC rules of visibility. IMHO portability is an important point. People are used to MAX() and COUNT(*), and will be surprised that they need some special treatment. While the reasons for this are perfectly explainable, speeding up these aggregates with some extra effort would make porting a bit easier. The availability of cleverness with MAX()/MIN() is no grand surprise; it would be very nice to get some expansion of that to SELECT VALUE FROM TABLE WHERE (CRITERIA) ORDER BY VALUE DESCENDING LIMIT 1; But I'm _very_ curious as to what the anticipated treatment to collect COUNT() more efficiently would be. I would expect that it would only be able to get tuned much more if there's NO where clause, so that it could use some (magically-kept-up-to-date) stats on table size. I don't see any way to optimize COUNT when numbers of rows can continually vary. Storing stats somewhere will just make updates more expensive. And if those stats are for the table, that doesn't help me if I want COUNT(*) FROM TABLE WHERE UPDATED_ON BETWEEN NOW() - '1 day' and NOW(). -- (format nil [EMAIL PROTECTED] aa454 freenet.carleton.ca) http://cbbrowne.com/info/linuxdistributions.html Recursion is the root of computation since it trades description for time. -- Alan Perlis ---(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: [HACKERS] Seqscan in MAX(index_column)
Christopher Browne wrote: IMHO portability is an important point. People are used to MAX() and COUNT(*), and will be surprised that they need some special treatment. While the reasons for this are perfectly explainable, speeding up these aggregates with some extra effort would make porting a bit easier. The availability of cleverness with MAX()/MIN() is no grand surprise; it would be very nice to get some expansion of that to SELECT VALUE FROM TABLE WHERE (CRITERIA) ORDER BY VALUE DESCENDING LIMIT 1; But I'm _very_ curious as to what the anticipated treatment to collect COUNT() more efficiently would be. I would expect that it would only be able to get tuned much more if there's NO where clause, so that it could use some (magically-kept-up-to-date) stats on table size. I don't see any way to optimize COUNT when numbers of rows can continually vary. Storing stats somewhere will just make updates more expensive. And if those stats are for the table, that doesn't help me if I want COUNT(*) FROM TABLE WHERE UPDATED_ON BETWEEN NOW() - '1 day' and NOW(). Yes, count would only use the cached stats for non-WHERE clause COUNT(*). My idea is that if a transaction doing a COUNT(*) would first look to see if there already was a visible cached value, and if not, it would do the COUNT(*) and insert into the cache table. Any INSERT/DELETE would remove the value from the cache. As I see it, the commit of the INSERT/DELETE transaction would then auto-invalidate the cache at the exact time the transaction commits. This would allow MVCC visibility of the counts. A trickier idea would be for INSERT/DELETE to UPDATE the cached value. It might be possible to always have a valid cache value for COUNT(*). (COPY would also need to update the cache.) -- 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: [HACKERS] Seqscan in MAX(index_column)
On Thu, 2003-09-04 at 22:02, Bruce Momjian wrote: My idea is that if a transaction doing a COUNT(*) would first look to see if there already was a visible cached value, and if not, it would do the COUNT(*) and insert into the cache table. Any INSERT/DELETE would remove the value from the cache. As I see it, the commit of the INSERT/DELETE transaction would then auto-invalidate the cache at the exact time the transaction commits. This would allow MVCC visibility of the counts. But this means that some of the time (indeed, *much* of the time), COUNT(*) would require a seqscan of the entire table. Since at many sites that will take an enormous amount of time (and disk I/O), that makes this solution infeasible IMHO. In general, I don't think this is worth doing. -Neil ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Seqscan in MAX(index_column)
Neil Conway wrote: On Thu, 2003-09-04 at 22:02, Bruce Momjian wrote: My idea is that if a transaction doing a COUNT(*) would first look to see if there already was a visible cached value, and if not, it would do the COUNT(*) and insert into the cache table. Any INSERT/DELETE would remove the value from the cache. As I see it, the commit of the INSERT/DELETE transaction would then auto-invalidate the cache at the exact time the transaction commits. This would allow MVCC visibility of the counts. But this means that some of the time (indeed, *much* of the time), COUNT(*) would require a seqscan of the entire table. Since at many sites that will take an enormous amount of time (and disk I/O), that makes this solution infeasible IMHO. In general, I don't think this is worth doing. It is possible it isn't worth doing. Can the INSERT/DELETE incrementing/decrementing the cached count work reliabily? -- 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])
[HACKERS] TODO item: psql tab-completion
This TODO item has been completed as of CVS tip, right? Allow psql to do table completion for SELECT * FROM schema_part and table completion for SELECT * FROM schema_name. -Neil ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Another small bug (pg_autovacuum)
Ouch... sorry, my fault. I'll fix this tomorrow (Friday) and submit a patch, or if you want to submit a patch that would be fine. All you have to do is change the the sql statements to put quotes around the relation name. Thanks for catching this. Matthew T. O'Connor On Thu, 2003-09-04 at 18:39, Adam Kavan wrote: Now that I have pg_autovacuum working I've bumped into another small bug. When pg_autovacuum goes to vacuum or analyze one of my tables it runs... analyze public.ConfigBackup Because ConfigBackup is mixed case it cannot find the relation. I fixed this by going to the function init_table_info and increasing the malloc for new_tbl-table_name by 2 and adding 's to either side of the table name. Is there anything wrong with this approach? Is there a config I can set to make this non-case sensitive? Thanks again for your time. --- Adam Kavan --- [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html ---(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: [HACKERS] Another small bug (pg_autovacuum)
On Thu, 2003-09-04 at 18:39, Adam Kavan wrote: Now that I have pg_autovacuum working I've bumped into another small bug. When pg_autovacuum goes to vacuum or analyze one of my tables it runs... Also, has this been officially fixed? All I have heard so far is that you commented out the check and now now it works for you. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Seqscan in MAX(index_column)
Bruce Momjian [EMAIL PROTECTED] writes: Neil Conway wrote: In general, I don't think this is worth doing. It is possible it isn't worth doing. Can the INSERT/DELETE incrementing/decrementing the cached count work reliabily? I don't even see how the notion of a single cached value makes theoretical sense, when in principle every transaction may have a different idea of the correct answer. You could doubtless maintain a fairly good approximate total this way, and that would be highly useful for some applications ... but it isn't COUNT(*). regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Seqscan in MAX(index_column)
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Neil Conway wrote: In general, I don't think this is worth doing. It is possible it isn't worth doing. Can the INSERT/DELETE incrementing/decrementing the cached count work reliabily? I don't even see how the notion of a single cached value makes theoretical sense, when in principle every transaction may have a different idea of the correct answer. You could doubtless maintain a fairly good approximate total this way, and that would be highly useful for some applications ... but it isn't COUNT(*). With MVCC allowing multiple rows with only one visible, I thought the INSERT/DELETE system would work --- once the delete becomes visible, the change becomes visible. -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Seqscan in MAX(index_column)
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: You could doubtless maintain a fairly good approximate total this way, and that would be highly useful for some applications ... but it isn't COUNT(*). With MVCC allowing multiple rows with only one visible, I thought the INSERT/DELETE system would work --- once the delete becomes visible, the change becomes visible. Oh, you're imagining the cache as being a row in an ordinary table? I doubt that could work. Multiple transactions trying to update these rows would suffer from contention and deadlock problems, wouldn't they? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
