[HACKERS] Not released yet, but could someone take a quick peak ...
ftp://ftp.postgresql.org/pub/source/v7.1.2 ...
Just want a second opinion before I announce more publicly ...
Thanks ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Not released yet, but could someone take a quick peak...
broken how? I just connected into it ...
On Tue, 22 May 2001, Karl DeBisschop wrote:
The Hermit Hacker wrote:
ftp://ftp.postgresql.org/pub/source/v7.1.2 ...
Just want a second opinion before I announce more publicly ...
I'd check. But the postgresql ftp site appears to be broken for the past
few days.
--
Karl
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(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] Plans for solving the VACUUM problem
On Sun, 20 May 2001, Vadim Mikheev wrote: 1. Space reclamation via UNDO doesn't excite me a whole lot, if we can make lightweight VACUUM work well. Sorry, but I'm going to consider background vacuum as temporary solution only. As I've already pointed, original PG authors finally became disillusioned with the same approach. How could they become disillusioned with it, when they never tried it? I know of no evidence that any version of PG has had backgroundable (non-blocking-to-other-transactions) VACUUM, still less within-relation space recycling. They may have become disillusioned with the form of VACUUM that they actually had (ie, the same one we've inherited) --- but please don't call that the same approach I'm proposing. Pre-Postgres'95 (original) versions had vacuum daemon running in background. I don't know if that vacuum shrinked relations or not (there was no shrinking in '95 version), I know that daemon had to do some extra work in moving old tuples to archival storage, but anyway as you can read in old papers in the case of consistent heavy load daemon was not able to cleanup storage fast enough. And the reason is obvious - no matter how optimized your daemon will be (in regard to blocking other transactions etc), it will have to perform huge amount of IO just to find space available for reclaiming. Certainly, doing VACUUM this way is an experiment that may fail, or may require further work before it really works well. But I'd appreciate it if you wouldn't prejudge the results of the experiment. Why not, Tom? Why shouldn't I say my opinion? Last summer your comment about WAL, may experiment that time, was that it will save just a few fsyncs. It was your right to make prejudment, what's wrong with my rights? And you appealed to old papers as well, BTW. If its an experiment, shouldn't it be done outside of the main source tree, with adequate testing in a high load situation, with a patch released to the community for further testing/comments, before it is added to the source tree? From reading Vadim's comment above (re: pre-Postgres95), this daemonized approach would cause a high I/O load on the server in a situation where there are *alot* of UPDATE/DELETEs happening to the database, which should be easily recreatable, no? Or, Vadim, am I misundertanding? ---(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] Upgrade issue (again).
On Thu, 17 May 2001, Lamar Owen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 16 May 2001 19:05, The Hermit Hacker wrote: On Wed, 16 May 2001, Lamar Owen wrote: I am loathe to even bring this up, but with two messages today about it, I am going to be short and sweet: We don't have a reasonable upgrade path. ASCII dump-install new-initdb-restore is not a reasonable upgrade. Furthermore, the dump/restore cycle is a pain in the neck when tables get larger than a few hundred megabytes. Personally ... I just upgraded 13 gig worth of databases using dump/restore, didn't have to end a single file, in less then 1.5hrs from start to finish ... *shrug* And 1.5 hours of downtime wasn't a problem? *raised eyebrow* :-) Or did you migrate to a different box running the new version? Or were you running more than one version on the one box? Some don't have that choice as easy, nor are they as experienced as you and I. Nor do they desire that much downtime. Wasn't a problem ... I pre-warned all our clients, some of which make such heavy use of the DB that we have to run vacuum on it every few hours, and, to them, the benefits outweigh'd the brief bit of downtime ... *shrug* ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Upgrade issue (again).
On Wed, 16 May 2001, Lamar Owen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I am loathe to even bring this up, but with two messages today about it, I am going to be short and sweet: We don't have a reasonable upgrade path. ASCII dump-install new-initdb-restore is not a reasonable upgrade. It is confusing to the newbie, and should be fixed. We used to have an upgrade path in pg_upgrade - -- but it no longer works (but it was most definitely a fine effort for its time, Bruce!). Furthermore, the dump/restore cycle is a pain in the neck when tables get larger than a few hundred megabytes. It's worse when the newer version won't properly restore from the old dump -- and you have to edit, potentially by hand, a multi-gigabyte dump to get it to restore. Personally ... I just upgraded 13 gig worth of databases using dump/restore, didn't have to end a single file, in less then 1.5hrs from start to finish ... *shrug* ---(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] pg_index.indislossy
On Mon, 14 May 2001, Bruce Momjian wrote: Bruce Momjian wrote: Can someone tell me what we use indislossy for? IIRC it means that if you get something by this index you must check again in the actual data I think that at least the GIST intarray (actually intset) methods use it. So you probably should _not_ remove it ;) I did a search and found it used only a few places. I do not see it used as part of GIST. My rememberance is that it is involved in partial indexes, where you index only certain values in a column. It was an old idea that was never working in PostgreSQL. Let's avoid removing things for the sake of removing them ... might be an old idea that, if someone takes the time to research, might prove useful ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] bug in JOIN or COUNT or ... ?
Sorry, worst Subject I've ever come up with, but this is one of those I
haven't got a clue how to describe emails ...
Simple query:
SELECT distinct s.gid, s.created, i.title
FROM status s LEFT JOIN images i ON (s.gid = i.gid AND i.active), personal_data
pd, relationship_wanted rw
WHERE s.active AND s.status != 0
AND s.gid = 17111
AND (s.gid = pd.gid AND pd.gender = 0)
AND (s.gid = rw.gid AND rw.gender = 0 );
Produces:
gid |created | title
---++
17111 | 2000-10-19 15:20:46-04 | image1
17111 | 2000-10-19 15:20:46-04 | image2
17111 | 2000-10-19 15:20:46-04 | image3
(3 rows)
Great, what I expect ...
But:
SELECT distinct s.gid, s.created, count(i.title) AS images
FROM status s LEFT JOIN images i ON (s.gid = i.gid AND i.active), personal_data
pd, relationship_wanted rw
WHERE s.active AND s.status != 0
AND s.gid = 17111
AND (s.gid = pd.gid AND pd.gender = 0)
AND (s.gid = rw.gid AND rw.gender = 0 )
GROUP BY s.gid, s.created;
Produces:
/tmp/psql.edit.70.62491: 7 lines, 353 characters.
gid |created | images
---++
17111 | 2000-10-19 15:20:46-04 | 15
(1 row)
So why is it counting 12 more images then are actually found/exist:
testdb=# select title from images where gid = 17111;
title
image1
image3
image2
(3 rows)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(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] bug in JOIN or COUNT or ... ?
On Sat, 12 May 2001, Tom Lane wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
So why is it counting 12 more images then are actually found/exist:
Hm. Could we see the EXPLAIN output for both of those?
without count:
NOTICE: QUERY PLAN:
Unique (cost=8.66..8.67 rows=1 width=37)
- Sort (cost=8.66..8.66 rows=1 width=37)
- Nested Loop (cost=0.00..8.65 rows=1 width=37)
- Nested Loop (cost=0.00..6.52 rows=1 width=33)
- Nested Loop (cost=0.00..4.26 rows=1 width=29)
- Index Scan using status_gid on status s
(cost=0.00..2.23 rows=1 width=12)
- Index Scan using images_gid on images i
(cost=0.00..2.02 rows=1 width=17)
- Index Scan using personal_data_gid on personal_data pd
(cost=0.00..2.25 rows=1 width=4)
- Index Scan using relationship_wanted_gid on relationship_wanted rw
(cost=0.00..2.11 rows=1 width=4)
EXPLAIN
with count:
NOTICE: QUERY PLAN:
Unique (cost=8.68..8.69 rows=1 width=37)
- Sort (cost=8.68..8.68 rows=1 width=37)
- Aggregate (cost=8.66..8.67 rows=1 width=37)
- Group (cost=8.66..8.67 rows=1 width=37)
- Sort (cost=8.66..8.66 rows=1 width=37)
- Nested Loop (cost=0.00..8.65 rows=1 width=37)
- Nested Loop (cost=0.00..6.52 rows=1 width=33)
- Nested Loop (cost=0.00..4.26 rows=1
width=29)
- Index Scan using status_gid on status
s (cost=0.00..2.23 rows=1 width=12)
- Index Scan using images_gid on images
i (cost=0.00..2.02 rows=1 width=17)
- Index Scan using personal_data_gid on
personal_data pd (cost=0.00..2.25 rows=1 width=4)
- Index Scan using relationship_wanted_gid on
relationship_wanted rw (cost=0.00..2.11 rows=1 width=4)
EXPLAIN
regards, tom lane
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [HACKERS] bug in JOIN or COUNT or ... ?
On Sat, 12 May 2001, Tom Lane wrote: Ah, I see it: your join against relationship_wanted isn't unique. globalmatch=# select count(*) from personal_data pd globalmatch-# where pd.gid = 17111 AND pd.gender = 0; count --- 1 (1 row) globalmatch=# select count(*) from relationship_wanted rw globalmatch-# where rw.gid = 17111 AND rw.gender = 0; count --- 5 (1 row) globalmatch=# So that inflates the number of rows coming out of the join by 5. Okay, then I'm lost ... why wouldn't that show up without the COUNT()? I doubt doubt your analysis, I just want to understand why ... ---(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] bug in JOIN or COUNT or ... ?
On Sat, 12 May 2001, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: So that inflates the number of rows coming out of the join by 5. Okay, then I'm lost ... why wouldn't that show up without the COUNT()? I doubt doubt your analysis, I just want to understand why ... You had DISTINCT on your query, which hid the duplicated rows from you. But that happens *after* aggregate processing, so it doesn't hide the dups from COUNT(). A, okay, that makes sense ... thanks for taking the time to check it for me ... and explaining what I was missing ... ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] REL7_1_STABLE tag/branch
it is a branch ... for lack of a better way to work it:
symbolic names:
REL7_1_STABLE: 1.106.0.2
REL7_1_BETA: 1.79
REL7_1_BETA3: 1.86
REL7_1_BETA2: 1.86
REL7_1: 1.102
REL7_0_PATCHES: 1.70.0.2
REL7_0: 1.70
REL6_5_PATCHES: 1.52.0.2
REL6_5: 1.52
REL6_4: 1.44.0.2
release-6-3: 1.33
SUPPORT: 1.1.1.1
PG95-DIST: 1.1.1
the big long numbers (1.106.0.2) denote branches ... the shorter ones
(1.79) simple tags along the main trunk ...
On Fri, 11 May 2001, Bruce Momjian wrote:
Can someone confirm that REL7_1_STABLE is a branch and not a tag? I am
having trouble doing 'cvs log -rREL7_1_STABLE' and wanted to make sure
everything was set up properly. I can 'cvs update/commit' fine.
It is my understanding that it should be a branch.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(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] 7.1.2 release
On Thu, 10 May 2001, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: Isn't this only critical for those that are using it? Does it affect those that don't use plpgsql? No, but I think it's pretty critical for those that do ... So, why not create a quick patch for those that need it, and let those with the capability pull from CVS/CVSup ... that is why we have them setup ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 7.1.2 release
On Thu, 10 May 2001, Bruce Momjian wrote: Are we releasing tomorrow. I will stamp the CVS STABLE branch tonight as 7.1.2. Not that I'm aware of ... I heard mention something about a couple of fixes, but we *just* put out 7.1.1 ... If ppl are affected by the bugs, use cvsup and set yoru tag to REL7_1_STABLE to download the latest STABLE code ... or use anon-cvs ... ---(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] 7.1.2 release
On Thu, 10 May 2001, Tom Lane wrote: Hiroshi Inoue [EMAIL PROTECTED] writes: I agree with you because the bug is very critical. Yes, I'd like to get that plpgsql bug fix out as soon as possible. Isn't this only critical for those that are using it? Does it affect those that don't use plpgsql? ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Shared library versions
On Wed, 9 May 2001, Peter Eisentraut wrote: We did not bump the shared library versions before the 7.1 release. Maybe we should do this before 7.1.2 goes out. Ummm ... unless there are any changes that would require someone to recompile their apps between v7.1.1 and v7.1.2, I don't think so ... they we are just creating potential problems for those upgrading from v7.1/v7.1.1 to the latest stable, where there are no changes ... If we were to do it, it would have to be on the v7.x, not v7.x.y ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Shared library versions
On Wed, 9 May 2001, Bruce Momjian wrote: We did not bump the shared library versions before the 7.1 release. Maybe we should do this before 7.1.2 goes out. I thought I did that long ago for 7.1, or I should have anyway. I don't see the commits either. Seems we can't do it in a minor release. Will have to wait for 7.2, but since there really wasn't much API change in 7.1, I think we are OK. Not sure if we should update them if there are no API changes, or were there? IMHO, it should only be changed if there are incompatibilities between releases ... we modify the API, mainly ... anything more then that, and we're making ppl recompile to pull in libraries that only unlying code has changed, but not the API ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Shared library versions
On Wed, 9 May 2001, Peter Eisentraut wrote: I'm talking about the minor number. The only thing that effects is that executables would pick up the new version if they have the old one in the path as well, no potential problems. Okay, but, what does that buy you? One overwrites the old library, the other creates one that will over-ride the old library ... either way, you are using the new library, no? ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Re: [GENERAL] v7.1.1 Branched, Packaged and Released ...
takes Vince a day or two to catch up ... yes, we are officially released,
and Tom just dump'd some major stats changes into HEAD ...
On Mon, 7 May 2001, Tatsuo Ishii wrote:
Does this mean that we have officially released 7.1.1? I could not
find any statements regarding 7.1.1 on the web pages...
--
Tatsuo Ishii
This is just a quick announcement that we have now branched off v7.1.x
from the main development tree, and are starting to dive into development
of v7.2 ...
There have been several changes since v7.1 was released, including:
Fix for numeric MODULO operator (Tom)
pg_dump fixes (Philip)
pg_dump can dump 7.0 databases (Philip)
readline 4.2 fixes (Peter E)
JOIN fixes (Tom)
AIX, MSWIN, VAX,N32K fixes (Tom)
Multibytes fixes (Tom)
Unicode fixes (Tatsuo)
Optimizer improvements (Tom)
Fix for whole tuples in functions (Tom)
Fix for pg_ctl and option strings with spaces (Peter E)
ODBC fixes (Hiroshi)
EXTRACT can now take string argument (Thomas)
Python fixes (Darcy)
With more details available in the ChangeLog file ...
This release does not require a dump/restore from v7.1, it is purely a
maintaince release ...
Any bugs please report them to [EMAIL PROTECTED] ...
RPMs and DEBs should be available soon ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] v7.1.1 Branched, Packaged and Released ...
This is just a quick announcement that we have now branched off v7.1.x
from the main development tree, and are starting to dive into development
of v7.2 ...
There have been several changes since v7.1 was released, including:
Fix for numeric MODULO operator (Tom)
pg_dump fixes (Philip)
pg_dump can dump 7.0 databases (Philip)
readline 4.2 fixes (Peter E)
JOIN fixes (Tom)
AIX, MSWIN, VAX,N32K fixes (Tom)
Multibytes fixes (Tom)
Unicode fixes (Tatsuo)
Optimizer improvements (Tom)
Fix for whole tuples in functions (Tom)
Fix for pg_ctl and option strings with spaces (Peter E)
ODBC fixes (Hiroshi)
EXTRACT can now take string argument (Thomas)
Python fixes (Darcy)
With more details available in the ChangeLog file ...
This release does not require a dump/restore from v7.1, it is purely a
maintaince release ...
Any bugs please report them to [EMAIL PROTECTED] ...
RPMs and DEBs should be available soon ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: CVSup not working!
most odd ... its set to start on rebooted, but either it went down on its
own, or didn't ... restarted now, let me know if its not working ...
On Fri, 4 May 2001, Thomas Lockhart wrote:
cvsup -L 2 postgres.cvsup
Parsing supfile postgres.cvsup
Connecting to postgresql.org
Cannot connect to postgresql.org: Connection refused
Will retry at 22:31:23
...
Me too. Marc, could you take a peek at it? cvsupd seems to be gone or
port blocked or ??
- Thomas
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [HACKERS] 7.1.1
On Fri, 4 May 2001, Bruce Momjian wrote: I see by the messages that 7.1.1 is in the final packaging. Anyone know when it will be released? Only Marc knows. :-) Tomorrow aft ... sorry, got tied up with a client finishing his server move to v7.1 this afternoon, and we hit problems with a programmer who didn't realize that telling the scripts to connect to a specific host was a good idea :) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] 7.1.1
thnks :)
On Fri, 4 May 2001, Bruce Momjian wrote:
OK, I have updated the file dates for a release tomorrow.
On Fri, 4 May 2001, Bruce Momjian wrote:
I see by the messages that 7.1.1 is in the final packaging. Anyone know
when it will be released?
Only Marc knows. :-)
Tomorrow aft ... sorry, got tied up with a client finishing his server
move to v7.1 this afternoon, and we hit problems with a programmer who
didn't realize that telling the scripts to connect to a specific host was
a good idea :)
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] v7.1.1 branched and released on Tuesday ...
On Mon, 30 Apr 2001, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: Does anyone have any outstanding fixes for v7.1.x that they want to see in *before* we do this release? Any points unresolved that anyone knows about that we need to look at? FWIW, I've finished committing all the bug fixes I have pending. There are several worrisome unresolved bug reports, but AFAIK none are for reproducible conditions, and I don't think we can make any more progress on them without more information. I doubt we should hold up the 7.1.1 release while waiting to see if we get any. We do have that not-quite-done QNX4 port patch in hand. Perhaps we should give Bernd another day to respond to the comments on that and squeeze it into 7.1.1. How about I do another end of week release? Give Bernd until Friday to sort through the patch with everyone without it being rushed ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Thanks, naming conventions, and count()
doesn't this defeat the reasons for going to numerics? is there a reason
why its such a difficult thing to do a SELECT oid on pg_database and
pg_class to get this information? that's what I've been doing when I need
to know *shrug*
On Sun, 29 Apr 2001, Bruce Momjian wrote:
First off I just wanted to give a big 'thank you' to all the
developers and contributors who have made PostgreSQL what it is
today. I haven't come across a single thing since my first
experience with it a few years ago that hasn't been corrected,
sped up, or otherwise postively enhanced!
In working with 7.1 over the past couple weeks, I've noted the
following mods may add to usability and speed:
o v7.1 changed the database naming convention to be all numeric;
I suggest having
the DB engine create symbolic links when creating a new DB
and subsequent tables. For instance, in creating a database
'foo' with table 'bar' the /path/to/pgsql/data/base folder
will have a new folder named something like '18720'; this
folder could also have a symbolic link to 'foo'. Then in the
'18720' folder rather than just having numeric files for each
table, pk, index, etc. there could be symbolic links
following the naming convention 'bar', 'pk_foo_pkey',
'field1_foo_ukey', 'field2_foo_key'.
Maybe this would work best as configurable flag that could
be set during compilation or in the conf file.
I think this is an excellent idea, and will add it to the TODO list. We
agonized over moving to numeric names, and we couldn't think of a good
way to allow administrators to know that table matched what files. The
big problem is that there is no good way to make the symlinks reliable
because in a crash, the symlink could point to a table creation that got
rolled back or the renaming of a table that got rolled back. I think
symlinks with some postmaster cleanup script that fixed bad symlinks
would be great for 7,2.
I have added this to the TODO list. If someone objects, I will remove
it:
* Add tablename symlinks for numeric file names
o count() should use index scans for tables with a PK; scans
would be on the PK index;
even after running 'vacuum analyze' such a query still uses
a sequential scan. For instance, select count(*) from bar
and even select(pk_name) from bar both use sequential scans.
Likewise, scans on fields with indexes should use the index.
The problem here is that now we don't have commit status in the index
rows, so they have to check the heap for every row. One idea is to
update the index status on an index scan, and if we can do that, we can
easily use the index. However, the table scan is pretty quick.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [HACKERS] Thanks, naming conventions, and count()
On Sun, 29 Apr 2001, Bruce Momjian wrote: doesn't this defeat the reasons for going to numerics? is there a reason why its such a difficult thing to do a SELECT oid on pg_database and pg_class to get this information? that's what I've been doing when I need to know *shrug* Yes, but you can't do that if you can't start the database or can't connect for some reason. If people don't think it is worthwhile, we can delete the TODO item. Okay, what does being able to ls the directory give you if you can't start the database? the only thing I do it for is to figure out whicih tables are taking up so much disk space, or which databases ... For example, when someone has trouble figuring out which directory is which database, they can just ls and look at the symlinks. Seems like a nice feature. Ya, but I thought that the reason for going numeric had to do with being transaction safe ... something about being able to safely RENAME a table, if my recollection remotely comes close ... as soon as you start throwing around symlinks, do we break that once more? what about if someone wants to physically move a table to a seperate file system, which is something that has been suggested as a way around the fact that all files are in the same subdirectory? You have a symlink to the symlink? I don't know the answers to these questions, which is why I'm asking them ... if this is something safe to do, and doesn't break us again, then sounds like a good idea to me too ... ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Thanks, naming conventions, and count()
On Sun, 29 Apr 2001, Bruce Momjian wrote: I don't know the answers to these questions, which is why I'm asking them ... if this is something safe to do, and doesn't break us again, then sounds like a good idea to me too ... I was suggesting the symlinks purely for admin convenience. The database would use only the numeric names. Except that the database would have to maintain those links ... now you've given something ppl are relying on being there, but, for some reason, a symlink wasn't created, so they think their table doesn't exist? I can even think of a situation, as unlikely as it can be, where this could happen ... run out of inodes on the file system ... last inode used by the table, no inode to stick the symlink onto ... its a remote situation, but I've personally had it happen ... I'd personally prefer to see some text file created in the database directory itself that contains the mappings ... so that each time there is a change, it just redumps that data to the dext file ... less to maintain overall ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Thanks, naming conventions, and count()
On Sun, 29 Apr 2001, Bruce Momjian wrote: I can even think of a situation, as unlikely as it can be, where this could happen ... run out of inodes on the file system ... last inode used by the table, no inode to stick the symlink onto ... If you run out of inodes, you are going to have much bigger problems than symlinks. Sort file creation would fail too. its a remote situation, but I've personally had it happen ... I'd personally prefer to see some text file created in the database directory itself that contains the mappings ... so that each time there is a change, it just redumps that data to the dext file ... less to maintain overall ... Yes, I like that idea, but the problem is that it is hard to update just one table in the file. You sort of have to update the entire file each time a table changes. That is why I liked symlinks because they are per-table, but you are right that the symlink creation could fail because the new table file was never created or something, leaving the symlink pointing to nothing. Not sure how to address this. Is there a way to update a flat file when a single table changes? Why not just dump the whole file? That way, if a previosu dump failed for whatever reason, the new dump would correct that omission ... Then again, why not some sort of 'lsdb' command that looks at where it is and gives you info as appropriate? if in data/base, then do a connect to template1 using postgres so that you can dump and parse the raw data from pg_database ... if in a directory, you should be able to connect to that database in a similar way to grab the contents of pg_class ... no server would need to be running for this to work, and if it was readonly, it should be workable if a server is running, no? ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Thanks, naming conventions, and count()
On Sun, 29 Apr 2001, Bruce Momjian wrote: Yes, I like that idea, but the problem is that it is hard to update just one table in the file. You sort of have to update the entire file each time a table changes. That is why I liked symlinks because they are per-table, but you are right that the symlink creation could fail because the new table file was never created or something, leaving the symlink pointing to nothing. Not sure how to address this. Is there a way to update a flat file when a single table changes? Why not just dump the whole file? That way, if a previosu dump failed for whatever reason, the new dump would correct that omission ... Yes, you can do that, but it is only updated during a dump, right? Makes it hard to use during the day, no? Then again, why not some sort of 'lsdb' command that looks at where it is and gives you info as appropriate? I want to do that for oid2name. I had the plan layed out, but never got to it. if in data/base, then do a connect to template1 using postgres so that you can dump and parse the raw data from pg_database ... if in a directory, you should be able to connect to that database in a similar way to grab the contents of pg_class ... no server would need to be running for this to work, and if it was readonly, it should be workable if a server is running, no? I think parsing the file contents is too hard. The database would have to be running and I would use psql. I don't know, I recovered someone's database using a raw connection ... wasn't that difficult once I figured out the format *shrug* the following gets the oid,relname's for a database in the format: echo select oid,relname from pg_class | postgres -L -D /usr/local/pgsql/data eceb | egrep oid|relname then just parse the output using a simple perl script: 1: oid = 163338 (typeid = 26, len = 4, typmod = -1, byval = t) 2: relname = auth_info_uid_key (typeid = 19, len = 32, typmod = -1, byval = f) 1: oid = 163341 (typeid = 26, len = 4, typmod = -1, byval = t) 2: relname = auth_info_id(typeid = 19, len = 32, typmod = -1, byval = f) 1: oid = 56082 (typeid = 26, len = 4, typmod = -1, byval = t) 2: relname = auth_info (typeid = 19, len = 32, typmod = -1, byval = f) the above won't work on a live database, did try that, so best is to test for a connection first, and this would be a fall back ... but you'd at least have a live *and* non live way of parsing the data *shrug* ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] v7.1 error ... SELECT converted to a COPY?
Okay, maybe this query isn't quite as simple as I think it is, but does
this raise any flags for anyone? How did I get into a COPY? It appears
re-creatable, as I've done it twice so far ...
eceb=# select e.idnumber,e.password from egi e, auth_info a where e.idnumber !=
a.idnumber;
Backend sent D message without prior T
Backend sent D message without prior T
Backend sent D message without prior T
Backend sent D message without prior T
Backend sent D message without prior T
Backend sent D message without prior T
Backend sent D message without prior T
Enter data to be copied followed by a newline.
End with a backslash and a period on a line by itself.
\.
Unknown protocol character 'J' read from backend. (The protocol character is the
first character the backend sends in response to a query it receives).
PQendcopy: resetting connection
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] v7.1 error ... SELECT converted to a COPY?
On Mon, 30 Apr 2001, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: Okay, maybe this query isn't quite as simple as I think it is, but does this raise any flags for anyone? How did I get into a COPY? It appears re-creatable, as I've done it twice so far ... eceb=# select e.idnumber,e.password from egi e, auth_info a where e.idnumber != a.idnumber; Backend sent D message without prior T Backend sent D message without prior T At a guess, you're running out of memory on the client side for the SELECT results (did you really want a not-equal rather than equal constraint there!?) Yup, want to figure out which ones are in the egi table that I hadn't transfer'd over yet ... tried it with a NOT IN ( SELECT ... ) combination, but an explain of that showed two sequential searches on the tables, so am working on fixing that ... ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] The new, the improved ... FTS Searching of Mailing List Archives
Morning all ...
I'm going to do a broader announcement in a couple of days, but
Oleg and his gang have just finished setting up their Mailing List
Searching software ...
If you go to fts.postgresql.org, it is like night-day as far as
the old searching is concerned ...
We have some more configuration work to do on it, to improve
performance, but if anyone has used the old interface, performance now is
such that even without much tuning on the backend, you no longer have time
for coffee between searches :)
Try it, let us know of any bugs, and we'll do a bigger
announcement in a couple of days to the rest of the community ...
Vince, can you fix the search links to point to this, as far as
the mailing list searches are concerned? docs are still in udmsearch for
now ...
*Major* thanks to Oleg and his group for making this available
to the community ... now searching is a useful function :)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: The new, the improved ... FTS Searching of Mailing List Archives
Actually, default appears to be the last month worth of messages ... check
your date range :)
On Fri, 27 Apr 2001, Vince Vielhaber wrote:
On Fri, 27 Apr 2001, The Hermit Hacker wrote:
Morning all ...
I'm going to do a broader announcement in a couple of days, but
Oleg and his gang have just finished setting up their Mailing List
Searching software ...
If you go to fts.postgresql.org, it is like night-day as far as
the old searching is concerned ...
We have some more configuration work to do on it, to improve
performance, but if anyone has used the old interface, performance now is
such that even without much tuning on the backend, you no longer have time
for coffee between searches :)
Try it, let us know of any bugs, and we'll do a bigger
announcement in a couple of days to the rest of the community ...
Vince, can you fix the search links to point to this, as far as
the mailing list searches are concerned? docs are still in udmsearch for
now ...
*Major* thanks to Oleg and his group for making this available
to the community ... now searching is a useful function :)
It *is* alot quicker. I did a search for scrappy on All Lists and
it came back in 0.151 secs. But it only found 104 matches, have you
been that quiet Marc?
I'll add it over the weekend.
Vince.
--
==
Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net
56K Nationwide Dialup from $16.00/mo at Pop4 Networking
Online Campground Directoryhttp://www.camping-usa.com
Online Giftshop Superstorehttp://www.cloudninegifts.com
==
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(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] The new, the improved ... FTS Searching of MailingList Archives
On Fri, 27 Apr 2001, Bruce Momjian wrote: Vince, can you fix the search links to point to this, as far as the mailing list searches are concerned? docs are still in udmsearch for now ... *Major* thanks to Oleg and his group for making this available to the community ... now searching is a useful function :) And something to add to 7.2! Huh? *raised eyebrow* This is a standalone application that they've donated to the project ... nothing that can be added to any of our distributions ... ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] The new, the improved ... FTS Searching of MailingList Archives
On Fri, 27 Apr 2001, Bruce Momjian wrote: On Fri, 27 Apr 2001, Bruce Momjian wrote: Vince, can you fix the search links to point to this, as far as the mailing list searches are concerned? docs are still in udmsearch for now ... *Major* thanks to Oleg and his group for making this available to the community ... now searching is a useful function :) And something to add to 7.2! Huh? *raised eyebrow* This is a standalone application that they've donated to the project ... nothing that can be added to any of our distributions ... Isn't the text indexing something that can go into the distribution? to the best of my knowledge, everything they had for public consumption was added to v7.1, but Oleg would be better for that ... to get fts.postgresql.org, there was nothing special I had to do as far as the backend was concerned *shrug* ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Split of tree on May 1
On Fri, 27 Apr 2001, Bruce Momjian wrote: We have discussed splitting the tree on May 1 to start 7.2 development. If no one objects, we will stay with that schedule. Please see other thread where we are actually discussing this ... if you have anything to add to that thread please do so ... ---(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] WAL feature
On Fri, 27 Apr 2001, Mikheev, Vadim wrote: Row reuse without vacuum Yes, it will help to remove uncommitted rows. Same question as I asked Bruce ... how? :) I wasn't trying to be fascisious(sp?) when I asked, I didn't realize the two were connected and am curious as to how :) ---(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] WAL feature
On Fri, 27 Apr 2001, Bruce Momjian wrote: How? I guess other hosts could read the WAL to find out what changed. I wonder if that would get around one of the issues I had brought up a ways back concerning replication and stuff like sequences ... Row reuse without vacuum How? Didn't even see these as being related ... It may be. Not sure. Neither am I ... Vadim seems to think so, so am curious as to how ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
RE: [HACKERS] WAL feature
On Fri, 27 Apr 2001, Mikheev, Vadim wrote: Row reuse without vacuum Yes, it will help to remove uncommitted rows. Same question as I asked Bruce ... how? :) I wasn't trying to be fascisious(sp?) when I asked, I didn't realize the two were connected and am curious as to how :) After implementing UNDO operation (we have only REDO now) transactions will roll back their changes on abort and so free space occupied by inserted rows. Ahhh, okay, so this isn't reusing space on delete/update, so much as avoiding writing to the table until the transaction is committed? ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] v7.1.1 branched and released on Tuesday ...
As Tom's mentioned the other day, we're looking at doing up v7.1.1 on
Tuesday, and starting in on v7.2 ...
Does anyone have any outstanding fixes for v7.1.x that they want to see in
*before* we do this release? Any points unresolved that anyone knows
about that we need to look at?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(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] refusing connections based on load ...
On Thu, 26 Apr 2001, Vince Vielhaber wrote: On Wed, 25 Apr 2001, The Hermit Hacker wrote: On Wed, 25 Apr 2001, Vince Vielhaber wrote: On Wed, 25 Apr 2001, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: Autoconf has a 'LOADAVG' check already, so what is so problematic about using that to enabled/disable that feature? Because it's tied to a GNU getloadavg.c implementation, which we'd have license problems with using. It's part of the standard C library in FreeBSD. Any other platforms have it built in? As has been mentioned, Solaris and Linux also have it ... But what's in FreeBSD's standard library isn't GNU. Wouldn't matter if it was, its part of the OSs standard library ... unless you mean to pull it in and use it with the distribution, which I think might be a bad idea ... if we pull anything in, sendmail's would be best ... FreeBSD's will have had anything required for non-FreeBSD systems yanked out, if it was ever there, while sendmail's already has all the 'hooks' in it ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: refusing connections based on load ...
On Tue, 24 Apr 2001, Nathan Myers wrote: On Tue, Apr 24, 2001 at 11:28:17PM -0300, The Hermit Hacker wrote: I have a Dual-866, 1gig of RAM and strip'd file systems ... this past week, I've hit many times where CPU usage is 100%, RAM is 500Meg free and disks are pretty much sitting idle ... Assuming strip'd above means striped, it strikes me that you might be much better off operating the drives independently, with the various tables, indexes, and logs scattered each entirely on one drive. have you ever tried to maintain a database doing this? PgSQL is definitely not designed for this sort of setup, I had symlinks goign everywhere,a nd with the new numbering schema, this is even more difficult to try and do :) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] refusing connections based on load ...
On Wed, 25 Apr 2001, Peter Eisentraut wrote: Tom Lane writes: A conncurrent-xacts limit isn't perfect of course, but I think it'd be pretty good, and certainly better than anything based on the available load-average numbers. The concurrent transaction limit would allow you to control the absolute load of the PostgreSQL server, but we can already do that and it's not what we're after here. The idea behind the load average based approach is to make the postmaster respect the situation of the overall system. Additionally, the concurrent transaction limit would only be useful on setups that have a lot of idle transactions. Those setups exist, but not everywhere. To me, both of these approaches are in the if you don't like it, don't use it category. Agreed ... by default, the loadavg method could be set to zero, to ignore ... I don't care if I'm off by 1min before I catch the increase, the fact is that I have caught it, and prevent any new ones coming in until it drops off again ... Make it two variables: transla rejectla if transla is hit, restrict on transactions, letting others connect, but putting them on hold while the la drops again ... if it goes above rejectla, refuse new connections altogether ... so now I can set something like: transla = 8 rejectla = 16 but if loadavg goes above 16, I want to get rid of what is causing the load to rise *before* adding new variables to the mix that will cause it to rise higher ... and your arg about permissions (Tom's, not Peter's) is moot in at least 3 of the major systems (Linux, *BSD and Solaris) as there is a getloadavg() function in all three for doing this ... ---(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] refusing connections based on load ...
On Wed, 25 Apr 2001, Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: The idea behind the load average based approach is to make the postmaster respect the situation of the overall system. That'd be great if we could do it, but as I pointed out, the available stats do not allow us to do it very well. I think this will create a lot of portability headaches for no real gain. If it were something we could just do and forget, I would not object --- but the porting issues will create a LOT more work than I think this can possibly be worth. The fact that the work is distributed and will mostly be incurred by people other than the ones advocating the change doesn't improve matters. As I mentioned, getloadavg() appears to be support on 3 of the primary platforms we work with, so I'd say for most installations, portability issues aren't an issue ... Autoconf has a 'LOADAVG' check already, so what is so problematic about using that to enabled/disable that feature? If ( loadavg available on OSenabled in postgresql.conf ) operate on it } else ( loadavg not available on OS enabled ) noop with a WARN level error that its not available } ---(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] refusing connections based on load ...
On Wed, 25 Apr 2001, Vince Vielhaber wrote: On Wed, 25 Apr 2001, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: Autoconf has a 'LOADAVG' check already, so what is so problematic about using that to enabled/disable that feature? Because it's tied to a GNU getloadavg.c implementation, which we'd have license problems with using. It's part of the standard C library in FreeBSD. Any other platforms have it built in? As has been mentioned, Solaris and Linux also have it ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] refusing connections based on load ...
On Wed, 25 Apr 2001, Tom Lane wrote: I'm still concerned about portability issues, and about whether load average is really the right number to be looking at, however. Its worked for Sendmail for how many years now, and the code is there to use, with all portability issues resolved for every platform they use ... and a growing number of platforms appear to have the mechanisms already built into their C libraries ... ---(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
[HACKERS] OUTER JOIN vs UNION ... faster?
Got a query that looks like:
SELECT card_info.main_cat, category_details.sub_cat_flag,count(*)
FROM send0,card_info,category_details
WHERE send0.card_id=card_info.card_id
AND category_details.mcategory='e-cards'
AND card_info.main_cat=category_details.category
AND send_date = '2001/04/08'
AND send_date = '2001/05/14' group by 1,2
UNION ALL
SELECT card_info.main_cat, category_details.sub_cat_flag,count(*)
FROM send1,card_info,category_details where send1.card_id=card_info.card_id
AND category_details.mcategory='e-cards'
AND card_info.main_cat=category_details.category
AND send_date = '2001/04/08'
AND send_date = '2001/05/14' group by 1,2
UNION ALL
SELECT card_info.main_cat, category_details.sub_cat_flag,count(*)
FROM send2,card_info,category_details where send2.card_id=card_info.card_id
AND category_details.mcategory='e-cards'
AND card_info.main_cat=category_details.category
AND send_date = '2001/04/08'
AND send_date = '2001/05/14' group by 1,2
UNION ALL
SELECT card_info.main_cat, category_details.sub_cat_flag,count(*)
FROM send3,card_info,category_details where send3.card_id=card_info.card_id
AND category_details.mcategory='e-cards'
AND card_info.main_cat=category_details.category
AND send_date = '2001/04/08'
AND send_date = '2001/05/14' group by 1,2
UNION ALL
SELECT card_info.main_cat, category_details.sub_cat_flag,count(*)
FROM send4,card_info,category_details where send4.card_id=card_info.card_id
AND category_details.mcategory='e-cards'
AND card_info.main_cat=category_details.category
AND send_date = '2001/04/08'
AND send_date = '2001/05/14' group by 1,2
UNION ALL
SELECT card_info.main_cat, category_details.sub_cat_flag,count(*)
FROM send5,card_info,category_details where send5.card_id=card_info.card_id
AND category_details.mcategory='e-cards'
AND card_info.main_cat=category_details.category
AND send_date = '2001/04/08'
AND send_date = '2001/05/14' group by 1,2
UNION ALL
SELECT card_info.main_cat, category_details.sub_cat_flag,count(*)
FROM send6,card_info,category_details where send6.card_id=card_info.card_id
AND category_details.mcategory='e-cards'
AND card_info.main_cat=category_details.category
AND send_date = '2001/04/08'
AND send_date = '2001/05/14' group by 1,2
UNION ALL
SELECT card_info.main_cat, category_details.sub_cat_flag,count(*)
*Really* dreading the thought of changing it to an OUTER JOIN, and am
wondering if there would be a noticeable speed difference between going
from the UNION above to an OUTER JOIN, or should they be about the same?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] refusing connections based on load ...
Apparently so under Solaris ...
hestia:/ uname -a
SunOS hestia 5.7 Generic_106542-12 i86pc i386 i86pc
C Library Functionsgetloadavg(3C)
NAME
getloadavg - get system load averages
SYNOPSIS
#include sys/loadavg.h
int getloadavg(double loadavg[], int nelem);
DESCRIPTION
How hard would it be to knock up code that, by default, ignores loadavg,
but if, say, set in postgresql.conf:
loadavg = 4
it will just refuse connections?
On Tue, 24 Apr 2001, Peter Eisentraut wrote:
Tom Lane writes:
The Hermit Hacker [EMAIL PROTECTED] writes:
sendmail does it now, and, apparently relatively portable across OSs ...
sendmail expects to be root. It's unlikely (and very undesirable) that
postgres will be installed with adequate privileges to read /dev/kmem,
which is what it'd take to run the sendmail loadaverage code on most
platforms...
This program:
#include stdio.h
int main()
{
double la[3];
if (getloadavg(la, 3) == -1)
perror(getloadavg);
printf(%f %f %f\n, la[0], la[1], la[2]);
return 0;
}
works unprivileged on Linux 2.2 and FreeBSD 4.3. Rumour[*] also has it
that there is a way to do this on Solaris and HP-UX 9. So I think that
covers enough users to be worthwhile.
[*] - Autoconf AC_FUNC_GETLOADAVG
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: Re: refusing connections based on load ...
On Wed, 25 Apr 2001, Lincoln Yeoh wrote: At 10:59 PM 23-04-2001 -0700, Nathan Myers wrote: On Tue, Apr 24, 2001 at 12:39:29PM +0800, Lincoln Yeoh wrote: Why not be more deterministic about refusing connections and stick to reducing max clients? If not it seems like a case where you're promised something but when you need it, you can't have it. The point is that number of connections is a very poor estimate of system load. Sometimes a connection is busy, sometimes it's not. Actually I use number of connections to estimate how much RAM I will need, not for estimating system load. Because once the system runs out of RAM, performance drops a lot. If I can prevent the system running out of RAM, it can usually take whatever I throw at it at near the max throughput. I have a Dual-866, 1gig of RAM and strip'd file systems ... this past week, I've hit many times where CPU usage is 100%, RAM is 500Meg free and disks are pretty much sitting idle ... It turns out, in this case, that vacuum was in order (i vacuum 12x per day now instead of 6), so that now it will run with 300 simultaneous connections, but with a loadavg of 68 or so, 300 connections are just building on each other to slow the rest down :( ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] refusing connections based on load ...
Anyone thought of implementing this, similar to how sendmail does it? If load n, refuse connections? Basically, if great to set max clients to 256, but if load hits 50 as a result, the database is near to useless ... if you set it to 256, and 254 idle connections are going, load won't rise much, so is safe, but if half of those processes are active, it hurts ... so, if it was set so that a .conf variable could be set so that max connection == 256 *or* load n to refuse connections, you'd hvae best of both worlds ... sendmail does it now, and, apparently relatively portable across OSs ... okay, just looked at the code, and its kinda painful, but its in src/conf.c, as a 'getla' function ... If nobody is working on something like this, does anyone but me feel that it has merit to make use of? I'll play with it if so ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] refusing connections based on load ...
On Mon, 23 Apr 2001, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: sendmail does it now, and, apparently relatively portable across OSs ... sendmail expects to be root. It's unlikely (and very undesirable) that postgres will be installed with adequate privileges to read /dev/kmem, which is what it'd take to run the sendmail loadaverage code on most platforms... Actually, not totally accurate ... sendmail has a 'RunAs' option for those that don't wish to have it run as root, and still works for the loadavg stuff, to the best of my knowledge (its an option I haven't played with yet) ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] refusing connections based on load ...
other then a potential buffer overrun, what would be the problem with:
open(kmem)
read values
close(kmem)
?
I would think it would be less taxing to the system then doing a system()
call, but still effectively as safe, no?
On Mon, 23 Apr 2001, Tom Lane wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
On Mon, 23 Apr 2001, Tom Lane wrote:
sendmail expects to be root.
Actually, not totally accurate ... sendmail has a 'RunAs' option for those
that don't wish to have it run as root,
True, it doesn't *have* to be root, but the loadavg code still requires
privileges beyond those of mere mortals (as does listening on port 25,
last I checked).
On my HPUX box:
$ ls -l /dev/kmem
crw-r- 1 binsys 3 0x01 Jun 10 1996 /dev/kmem
so postgres would have to run setuid bin or setgid sys to read the load
average. Either one is equivalent to giving an attacker the keys to the
kingdom (overwrite a few key /usr/bin/ executables and wait for root to
run one...)
On Linux and BSD it seems to be more common to put /dev/kmem into a
specialized group kmem, so running postgres as setgid kmem is not so
immediately dangerous. Still, do you think it's a good idea to let an
attacker have open-ended rights to read your kernel memory? It wouldn't
take too much effort to sniff passwords, for example.
Basically, if we do this then we are abandoning the notion that Postgres
runs as an unprivileged user. I think that's a BAD idea, especially in
an environment that's open enough that you might feel the need to
load-throttle your users. By definition you do not trust them, eh?
A less dangerous way of approaching it might be to have an option
whereby the postmaster invokes 'uptime' via system() every so often
(maybe once a minute?) and throttles on the basis of the results.
The reaction time would be poorer, but security would be a whole lot
better.
regards, tom lane
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] refusing connections based on load ...
On 23 Apr 2001, Ian Lance Taylor wrote: Tom Lane [EMAIL PROTECTED] writes: On Linux and BSD it seems to be more common to put /dev/kmem into a specialized group kmem, so running postgres as setgid kmem is not so immediately dangerous. Still, do you think it's a good idea to let an attacker have open-ended rights to read your kernel memory? It wouldn't take too much effort to sniff passwords, for example. On Linux you can get the load average by doing `cat /proc/loadavg'. On NetBSD you can get the load average via a sysctl. On those systems and others the uptime program is neither setuid nor setgid. Good call ... FreeBSD has it also, and needs no special privileges ... just checked, and the sysctl command isn't setuid/setgid anything, so I'm guessing that using sysctl() to pull these values shouldn't create any security issues on those systems that support it ? ---(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
[HACKERS] idle processes in v7.1 ... not killable?
I tried to do a 'kill pid' like I would have in v7.0.3, doesn't affect
it ... so, how to get rid of idle process that have been sitting around
for a long time, without having to shutdown the database itself?
pgsql 64484 0.0 1.0 15352 10172 p4- ISat08PM 0:00.15 postmaster: hordemgr
horde 216.126.85.170 idle (postgres)
pgsql 64760 0.0 1.0 15352 10420 p4- ISat08PM 0:00.21 postmaster: hordemgr
horde 216.126.85.170 idle (postgres)
pgsql 94615 0.0 0.8 15336 8488 p4- ISun12AM 0:00.09 postmaster: hordemgr
horde 216.126.85.86 idle (postgres)
pgsql 99711 0.0 0.9 15336 9688 p4- ISun01AM 0:00.14 postmaster: hordemgr
horde 216.126.85.188 idle (postgres)
pgsql 99810 0.0 0.9 15352 9124 p4- ISun01AM 0:00.12 postmaster: hordemgr
horde 216.126.85.188 idle (postgres)
pgsql1768 0.0 0.8 15336 8112 p4- ISun01AM 0:00.09 postmaster: hordemgr
horde 216.126.85.86 idle (postgres)
pgsql8781 0.0 1.1 15368 11016 p4- ISun09AM 0:00.23 postmaster: hordemgr
horde 216.126.85.30 idle (postgres)
pgsql 29503 0.0 1.1 15352 11052 p4- ISun10AM 0:00.23 postmaster: hordemgr
horde 216.126.85.30 idle (postgres)
pgsql 29930 0.0 1.0 15352 10556 p4- ISun11PM 0:00.15 postmaster: hordemgr
horde 216.126.85.100 idle (postgres)
pgsql 29985 0.0 1.0 15352 10192 p4- ISun11PM 0:00.14 postmaster: hordemgr
horde 216.126.85.100 idle (postgres)
pgsql 57446 0.0 0.6 15336 6784 p4- IMon09AM 0:00.06 postmaster: hordemgr
horde 216.126.85.243 idle (postgres)
pgsql 57961 0.0 0.7 15336 6884 p4- IMon09AM 0:00.06 postmaster: hordemgr
horde 216.126.85.243 idle (postgres)
pgsql 98541 0.0 0.8 15352 8756 p4- IMon11AM 0:00.10 postmaster: hordemgr
horde 216.126.85.13 idle (postgres)
pgsql 98601 0.0 0.7 15336 6796 p4- IMon11AM 0:00.06 postmaster: hordemgr
horde 216.126.85.13 idle (postgres)
pgsql 16510 0.0 0.7 15352 7624 p4- IMon01PM 0:00.07 postmaster: hordemgr
horde 216.126.85.196 idle (postgres)
pgsql 17052 0.0 0.7 15352 6936 p4- IMon01PM 0:00.06 postmaster: hordemgr
horde 216.126.85.196 idle (postgres)
pgsql 86741 0.0 0.6 15336 6660 p4- IMon10PM 0:00.06 postmaster: hordemgr
horde 216.126.85.119 idle (postgres)
pgsql8388 0.0 0.6 15336 6484 p4- ITue12AM 0:00.05 postmaster: hordemgr
horde 216.126.85.95 idle (postgres)
pgsql 27186 0.0 1.0 15368 10880 p4- ITue09AM 0:00.24 postmaster: hordemgr
horde 216.126.85.184 idle (postgres)
pgsql 27512 0.0 0.9 15352 9616 p4- ITue09AM 0:00.15 postmaster: hordemgr
horde 216.126.85.184 idle (postgres)
pgsql 91723 0.0 1.0 15368 10364 p4- ITue12PM 0:00.16 postmaster: hordemgr
horde 216.126.85.194 idle (postgres)
pgsql 45351 0.0 0.6 15336 5952 p4- I10:03AM 0:00.04 postmaster: hordemgr
horde 216.126.85.186 idle (postgres)
pgsql 35967 0.0 0.5 15336 4960 ?? I 8:53AM 0:00.03 postmaster: hordemgr
horde 216.126.84.1 idle (postgres)
pgsql 36678 0.0 0.0 1008 312 p4 R+8:55AM 0:00.00 grep hordemgr
pgsql 45200 0.0 0.7 15356 6828 p4- I10:03AM 0:00.06 postmaster: hordemgr
horde 216.126.85.186 idle (postgres)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] idle processes in v7.1 ... not killable?
Okay, I *swear* I tried both 'kill pid' and 'kill -TERM pid' this
morning before I sent this out .. just tried it again and it worked :(
*shrug*
On Thu, 19 Apr 2001, Tom Lane wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
I tried to do a 'kill pid' like I would have in v7.0.3, doesn't affect
it ...
Huh? Doesn't kill default to -TERM on your machine? That works fine
for me ...
regards, tom lane
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(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] CVS server ailing?
try now?
On Thu, 19 Apr 2001, Peter Eisentraut wrote:
What did you do to the CVS server? It takes hours to update a single
file, half a day to run cvs diff. This has been like that for about 48
hours.
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Another news story in need of 'enlightenment'
I can't seem to get at the original anymore, but we talked to Dr.
Soparkar, and is posted a 'followup' of the article to:
http://linuxtoday.com/news_story.php3?ltsn=2001-04-16-009-21-PS-EL-HE-0038
Since I can't seem to get to the original on dqindia.com, I can't comment
on what's changed ...
On Wed, 18 Apr 2001, D'Arcy J.M. Cain wrote:
Thus spake Lamar Owen
This one probably needs the 'iron hand and the velvet paw' touch. The
iron hand to pound some sense into the author, and the velvet paw to
make him like having sense pounded into him. Title of article is 'Open
Source Databases Won't Fly' --
http://www.dqindia.com/content/enterprise/datawatch/101041201.asp
I'm not sure there was even a point in there. The article was rambling
and undirected. Completely apart from any content, this just seemed like
a badly written article. I'm not sure that it even merits consideration
in this forum.
I guess anyone can be published on the net.
--
D'Arcy J.M. Cain darcy@{druid|vex}.net | Democracy is three wolves
http://www.druid.net/darcy/| and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(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] Re: [BUGS] three VERY minor things with 7.1 final
On Tue, 17 Apr 2001, Tom Lane wrote: David George [EMAIL PROTECTED] writes: I just built the postgresql 7.1 final and the configure script is still checking for sfio. Not a major big deal, but I need to remove the sfio check from configure.in, run autoconf, and then configure to fix it. If you remember sfio on Sparc Solaris 7 was causing a segfault when psql would display its output. Hmm. Digging in the CVS logs and pghackers archives, it seems that configure started checking for sfio in response to Michael Richards' unsubstantiated claim that FreeBSD 2.2.5 requires it to be used (http://www.postgresql.org/mhonarc/pgsql-hackers/1998-04/msg00363.html). Can anyone confirm or deny that? Marc had previously expressed some interest as well (thread starting at http://www.postgresql.org/mhonarc/pgsql-hackers/1998-04/msg00219.html) but the outcome of that thread didn't seem to suggest that it's a must-have item. Damn, now *that* is an old thread ... I can't see any reason why it would be required for FreeBSD, as its only a port for the OS, not part of it ... I'm tempted to rip out the configure check for sfio, but if it's only broken on some systems and really is useful on others, then we have to try to figure out how to tell if it's broken :-( Pull it, as far as I'm conerned ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: 7.1 RPMs
On Sun, 15 Apr 2001, Thomas Lockhart wrote: Do we need to start thinking about an RPM mailing list? Seems there is lots of traffic. The delete key is your friend. So is procmail, if you just can't stand to see the letters "R", "P", and "M" too close together ;) I'm not a big fan of the trend to fork off a mailing list anytime more than a few messages on a single topic come through. The synergy and cross-pollination that we get by having us all see various topics wrt development far outweigh the minor annoyance to some on having to delete topics they don't find interesting. As an example, RPM building is only a part of the general packaging of PostgreSQL, but it illustrates issues which anyone touching configuration or Makefiles should be aware of. So forcing "those Linux people" onto some specialty list weakens the knowledge base we all could draw from. All imho of course... agreed, that's why I was kinda thinking maybe some sort of 'build' list ... something that deals with configure, makefile and packaging issues ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] CRN article
So, to sum up ... the article did a good job of representing Great Bridge,
did a great injustice (a slap in the face, so to say) to the PostgreSQL
community as a whole, so Great Bridge has no intention of correcting the
situation?
Just to clarify your position, of course ...
On Sun, 15 Apr 2001, Ned Lilly wrote:
Folks,
By now, I imagine a number of people have seen the piece on the
Computer Reseller News website about Great Bridge and PostgreSQL.
While I think we're all happy to see the increased visibility for
PostgreSQL (especially as compared to the Oracles of the world),
it's fair to say the article wasn't perfect. As Nathan Myers
observed in another post, they rarely are. ;-)
I thought the reporter did a good job of talking about Great
Bridge's business model and how we work with resellers and
third-party software developers (which after all is the focus of the
magazine). Sure, there were some minor errors of fact, like the
confusion over PostgreSQL's Berkeley origins, and the use of the
word "licensing."
But of greater concern to us, and the reason I'm writing this note,
is the lack of clarity about the open source community that has
built, and continues to build this software. Great Bridge is one
company, one member of a large community, and a relative newcomer to
the party. We employ several leading PostgreSQL developers, and
give back to the project in many ways, but at the end of the day,
we're still only a very small part of the larger project - which
precedes us by many years, and could very easily survive us as
well. We are *a* marketing channel for PostgreSQL (not *the*
channel), provide services around the software, and release a
QA-certified distribution (bundled with other tools and
applications), but we know that it's not *our* software. It's
everyone's, and I'm sorry the article didn't adequately represent
that reality.
Having said that, I'd ask everyone to take a deep breath, as Nathan
suggested, and realize that it's still early in the adoption cycle
for open source in the larger business world and the mass media.
There will continue to be nuances that seem blindingly obvious to
us, but slip right through the reporting and editing process in the
trade press. That's ok, as long as we correct those errors, as
delicately as possible ;-)
We all have a shared stake in PostgreSQL being more widely used and
appreciated, and how we respond to things like this will go a long
way toward furthering that goal. You can all be justifiably proud
of the work that's gone into PostgreSQL, leading up to the terrific
7.1 release; a big part of Great Bridge's job as a marketing
organization is to make sure the world finds out about it - an
ongoing job that we take very seriously.
If anyone has any questions about Great Bridge's position on this
kind of stuff, please feel free to email me off-list.
Thanks,
Ned
--
Ned Lilly e: [EMAIL PROTECTED]
Vice Presidentw: www.greatbridge.com
Evangelism / Hacker Relationsv: 757.233.5523
Great Bridge, LLCf: 757.233.
---(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
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(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] Fast Forward (fwd)
On Sat, 14 Apr 2001, Nathan Myers wrote: This is probably a good time to point out that this is the _worst_ _possible_ response to erroneous reportage. The perception by readers will not be that the reporter failed, but that PostgreSQL advocates are rabid weasels who don't appreciate favorable attention, and are favorable attention?? dangerous to write anything about. You can bet this reporter and her editor will treat the topic very circumspectly (i.e. avoid it) in the future. woo hoo, if that is the result, then I think Vince did us a great service, not dis-service ... Most reporters are ignorant, most reporters are lazy, and many are both. It's part of the job description. Getting angry about it is like getting angry at birds for fouling their cage. Their job is to regurgitate what they're given, and quickly. They have no time to learn the depths, or to write coherently about it, or even to check facts. Out of all the articles on PgSQL that I've read over the years, this one should have been shot before it hit the paper (so to say) ... it was the most blatantly inaccurate article I've ever read ... It will be harder than the original mailings, but I urge each who wrote to write again and apologize for attacking her. In a way, I think you are right .. I think the attack was aimed at the wrong ppl :( She obviously didn't get *any* of her information from ppl that belong *in* the Pg community, or that have any knowledge of how it works, or of its history :( ---(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] Fast Forward (fwd)
the thing that pissed me off the most, and set me off, was the totally
blatant errors ... we've had other articles written, with a GB slant to
them, that didn't get my feathers in a ruffle ... the fact that they
*talked* with GB, got quotes from them and some of their partners, and
*still* got the facts wrong, is what got me heated ...
On Sun, 15 Apr 2001, Bruce Momjian wrote:
Here's my response to the inaccurate article cmp produced. After
chatting with Marc I decided to post it myself.
Since I know Ned reads this list, I formally request that he also
insists PUBLICALLY that cmp correct their inaccuracies. I'm rather
disappointed (for lack of a more descriptive word) that Bruce has not
already done so.
OK, I read the article. Seems there are two major mistakes. First,
they equate Great Bridge with PostgreSQL, and second, they don't know
the history of PostgreSQL.
If they fixed those two mistakes, the article would be OK. Seems like
they have already been contacted and hopefully they will correct this.
(Not sure how they do that.)
In reading the article, I have to ask myself, "How upset would I be if
they had equated PostgreSQL, Inc or another company with PostgreSQL?"
Well, I certainly wouldn't like it, and would try to get it corrected.
However, I wouldn't consider it a major problem. The press makes
mistakes like this all the time, and this press outlet is just too small
to worry about.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Upgrade complete ... all went smooth ...
Just as an FYI for those considering the shift ... I just upgraded all of
my databases over to v7.1 from v7.0.3 and it was smooth as silk. The only
problems were having to compile and load a few modules from contrib that
some of my clients were using ...
Took about an hour and a half to do 100 databases ..
Very impressive ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(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] Re: 7.1 RPMs
If someone wants to come up with an idea for name, i think that the whole
Win camp could be seperated also ...
pgsql-windows and pgsql-rpm ?
as far as newsgroups are concerned, they would both fall under ports:
comp.databases.postgresql.ports.linux.rpm
comp.databases.postgresql.ports.windows
I'm willing to create, as long as ppl are willing to use *shrug*
On Sat, 14 Apr 2001, Bruce Momjian wrote:
Do we need to start thinking about an RPM mailing list? Seems there is
lots of traffic.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
[HACKERS] Name - number ...
77 databases in data/base directory ... all number'd ...
select * from pg_database;
doesn't give me the reference to which directory is which database ... so
what table do we need to join on to get this information?
thanks ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: 7.1 RPMs
On Sat, 14 Apr 2001, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: If someone wants to come up with an idea for name, i think that the whole Win camp could be seperated also ... pgsql-windows and pgsql-rpm ? A windows list seems like a good idea. But I'm not sure that a separate list for RPMs is a good idea. In the first place, it's fuzzy: is it to be used just for RPM packaging discussion, or is it going to draw off --- for example --- all bug reports from people who happen to have installed from RPM instead of source? I suppose the former is intended, but it's not going to be clear to people. I think we've already got too many lists with fuzzy boundaries. In the second place, the RPM packaging discussion is quite sporadic; I think the traffic would be nil except at times when Lamar is working on new RPMs. That's why I wasn't sure how to classify the RPM one ... I like Lamar's suggestion of pgsql-cygwin though ... sound reasonable? ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: 7.1 RPMs
On Sat, 14 Apr 2001, Peter Eisentraut wrote: Bruce Momjian writes: Do we need to start thinking about an RPM mailing list? Seems there is lots of traffic. The traffic naturally peaks around release time, and this time especially because yours truly messed up the whole build system that the packagers were so careful to work around. I trust that in a few weeks we'll enter a new quiet period. My vote is that technical packaging discussions should go on -hackers just like a makefile discussion. Why not a "pgsql-build", or something like that, list? Where build/make file discussions can take place? Vs server issues? I'd really like to find some way of reducing traffic on -hackers like we did with -interfaces ... if we can come up with a good list for it ... pgsql-build (or a better name?) could be for RPM discussions, just as easy as Makefile/Configure discussions ... ---(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] Name - number ...
d'oh, should have extended my query ...
select oid,* from pg_database;
gives the directory name ...
thanks :)
On Sat, 14 Apr 2001, Bruce Momjian wrote:
77 databases in data/base directory ... all number'd ...
select * from pg_database;
doesn't give me the reference to which directory is which database ... so
what table do we need to join on to get this information?
thanks ...
Info is in pg_class.relfilenode. Now the big question is where do
database names go. My guess is pg_database.oid.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(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] Re: 7.1 RPMs
On Sat, 14 Apr 2001, Peter Eisentraut wrote: The Hermit Hacker writes: I like Lamar's suggestion of pgsql-cygwin though ... sound reasonable? We have pgsql-ports, which isn't seeing too much traffic as it is. Seems like the cygwin people hang out there anyway. Ya, well, there is alot of traffic on -hackers that should probably be over there anyway *shrug* ---(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] Re: 7.1 RPMs
On Sat, 14 Apr 2001, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: I like Lamar's suggestion of pgsql-cygwin though ... sound reasonable? Yes, that's probably better than pgsql-windows ... Done ... ---(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] Hey guys, check this out.
there is little, to nothing, factual about that whole article ...
"Great Bridge essentially gives away its open-source database application
at little cost..."
- thannk god I can get it completely for free, eh?
"Great Bridge executives say their licensing costs for the software..."
- someone want to tell me when they started charging licensing
costs?
"...nearly 25 years ago"
- I thought it was around '85? That's only 15 years ...
"Version 7.1, due to ship at the end of June..."
- should I pull what we've released? *raised eyebrow*
"...is the marketing and channel arm for PostgreSQL"
- they are?
I wonder, is Great Bridge going to step up and correct the *several*
mis-conceptions that have been touted in their name? There were alot of
quotes from GB in there, so I wonder ... ?
On Sat, 14 Apr 2001, Lamar Owen wrote:
http://www.crn.com/Sections/Fast_Forward/fast_forward.asp?ArticleID=25670
Marc will be pleased to note that the PostgreSQL project came out of the
FreeBSD project, and is Great Bridge's database. Gotta love
journalistic license.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Hey guys, check this out.
okay, I didn't get a copy of it ... :(
On Sun, 15 Apr 2001, Vince Vielhaber wrote:
I rarely sign a note as the webmaster, I like to keep a low profile.
I just sent the witch a note and made it a point to let her know who
I am - and BCCd Marc. He can cross post it if he wishes. I also sent
it to the editor of that rag.
Vince.
On Sun, 15 Apr 2001, The Hermit Hacker wrote:
there is little, to nothing, factual about that whole article ...
"Great Bridge essentially gives away its open-source database application
at little cost..."
- thannk god I can get it completely for free, eh?
"Great Bridge executives say their licensing costs for the software..."
- someone want to tell me when they started charging licensing
costs?
"...nearly 25 years ago"
- I thought it was around '85? That's only 15 years ...
"Version 7.1, due to ship at the end of June..."
- should I pull what we've released? *raised eyebrow*
"...is the marketing and channel arm for PostgreSQL"
- they are?
I wonder, is Great Bridge going to step up and correct the *several*
mis-conceptions that have been touted in their name? There were alot of
quotes from GB in there, so I wonder ... ?
On Sat, 14 Apr 2001, Lamar Owen wrote:
http://www.crn.com/Sections/Fast_Forward/fast_forward.asp?ArticleID=25670
Marc will be pleased to note that the PostgreSQL project came out of the
FreeBSD project, and is Great Bridge's database. Gotta love
journalistic license.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
--
==
Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net
56K Nationwide Dialup from $16.00/mo at Pop4 Networking
Online Campground Directoryhttp://www.camping-usa.com
Online Giftshop Superstorehttp://www.cloudninegifts.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
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Tag'd, packaged and ready to go ...
Well folks, I just fixed the CVS tags (renamed REL7_1 to REL7_1_BETA and
moved REL7_1 to today) and packaged up the release ... this is it, any new
fixes go into v7.1.1 ... :)
I'm preparing a formal PR/Announce, and will send that out later on this
evening, but want to give some of the mirror sites a chance to update
before doing such ...
If anyone wants to grab a copy of this, make sure there are no outstanding
issues with the packaging itself, please do ...
There are no changes between rc4 and full release, except that D'Arcy
removed a 'beta' comment from the Python interface ... so if you are
running rc4 now, no need to upgrade ...
Unless any major disagreements, I'd like to scheduale v7.1.1 now, for May
1st, at which time I'll do our normal branch for v7.2 ... so, if you are
sitting on any *bug fixes* for v7.1, plesae start shoving them in
effective this email ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Anyone have any good addresses ... ?
On Fri, 13 Apr 2001, Bruce Momjian wrote: Here is what we've always sent to to date ... anyone have any good ones to add? Addresses : [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Do we do freshmeat? Yup ... just submit'd the update ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Anyone have any good addresses ... ?
email added, thanks ...
On 13 Apr 2001, Matthew Rice wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
Here is what we've always sent to to date ... anyone have any good ones
to add?
I think that this is still the moderator's address for comp.os.linux.announce:
[EMAIL PROTECTED]
--
matthew rice [EMAIL PROTECTED] starnix inc.
tollfree: 1-87-pro-linuxthornhill, ontario, canada
http://www.starnix.com professional linux services products
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Anyone have any good addresses ... ?
Freshmeat updated, Linuxtoday bookmarked ... thanks ;)
On 13 Apr 2001, Trond Eivind [iso-8859-1] Glomsrød wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
On 13 Apr 2001, Trond Eivind [iso-8859-1] Glomsrød wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
Here is what we've always sent to to date ... anyone have any good ones
to add?
Addresses : [EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED]
Freshmeat, linuxtoday. If the release includes RPMs for Red Hat Linux,
redhat-announce is also a suitable location.
do you have email addresses fo freshmeat/linuxtoday? I have 6 web sites
that I have bookmarked for announces also, so if you have a good web URL,
I'll take those too ...
Seems to be web based (painful):
http://freshmeat.net/faq/view/20/
http://linuxtoday.com/contribute.php3
--
Trond Eivind Glomsrød
Red Hat, Inc.
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
[HACKERS] Going from 7.0.3 - 7.1 ...
Theoretically, should one be able to do:
pg_dumpall db.out
remove 7.0.3 bin, lib, data, etc
install 7.1 bin, lib, etc
initdb 7.1
psql template1 db.out
Basically, has anyone actually tried *that* yet and can report on whether
or not it works?
I'm just about to try it here, on 2gig of data, but if others have
experience with this, that would be great ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] HOLD THE PRESSES!! ... pg_dump from v7.0.3 can't import to v7.1?
v7.0.3 database:
trends_acctng=# \d
List of relations
Name | Type | Owner
-+---+---
accounts| table | pgsql
admin | table | pgsql
calls | table | pgsql
comments| table | pgsql
cookies | table | pgsql
credit_card | table | pgsql
credits | table | pgsql
logs| table | pgsql
personal| table | pgsql
radhist | table | pgsql
radlog | table | pgsql
remote_host | table | pgsql
static_ip | table | pgsql
users | table | pgsql
(14 rows)
v7.1 database:
trends_acctng=# \d
List of relations
Name | Type | Owner
--+--+-
buy | table| jeff
buy_bid_seq | sequence | jeff
clients_c_id_seq | sequence | jeff
cppvad_clients | table| jeff
cppvad_clients_cc_id_seq | sequence | jeff
cppvad_info | table| jeff
cppvad_info_cid_seq | sequence | jeff
download | table| jeff
download_dlid_seq| sequence | jeff
exchange | table| jeff
exchange_exid_seq| sequence | jeff
gallery | table| scrappy
listing | table| area902
listing_lid_seq | sequence | area902
ndict10 | table| pgsql
ndict11 | table| pgsql
ndict12 | table| pgsql
ndict16 | table| pgsql
ndict2 | table| pgsql
ndict3 | table| pgsql
ndict32 | table| pgsql
ndict4 | table| pgsql
ndict5 | table| pgsql
ndict6 | table| pgsql
ndict7 | table| pgsql
ndict8 | table| pgsql
ndict9 | table| pgsql
projects | table| scrappy
thepress | table| jeff
thepress_id_seq | sequence | jeff
ticket | table| pgsql
ticket_comments | table| pgsql
ticket_ticket_id_seq | sequence | pgsql
ticket_times | table| pgsql
(34 rows)
all I did was use pg_dumpall from v7.0.3 to dump to a text file, and
"psql template1 dumpfile" to load it back in again ...
obviously this doesn't work like it has in the past?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(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
[HACKERS] Re: HOLD THE PRESSES!! ... pg_dump from v7.0.3 can't import to v7.1?
No errors, nothing ... here is the backend: %bin/postmaster -D /usr/local/pgsql/data DEBUG: database system was shut down at 2001-04-10 15:04:08 ADT DEBUG: CheckPoint record at (0, 1522068) DEBUG: Redo record at (0, 1522068); Undo record at (0, 0); Shutdown TRUE DEBUG: NextTransactionId: 615; NextOid: 18720 DEBUG: database system is in production state DEBUG: copy: line 445, XLogWrite: new log file created - consider increasing WAL_FILES DEBUG: XLogWrite: new log file created - consider increasing WAL_FILES DEBUG: XLogWrite: new log file created - consider increasing WAL_FILES DEBUG: MoveOfflineLogs: remove and I ran the restore in 'script' to save everything, and as: psql -q template1 pg_dumpall.out and there are no errors in the resultant file ... For all intensive purposes, the restore *looked* clean ... but, going back and looking at the dump file, the dump wasn't clean *puzzled look* I'm going to have to look at this some more, but its pg_dumpall in v7.0.3 that is dumping the wrong data, not the restore :( all 77 databases got dump'd as the same database: You are now connected to database wind. wind=# \d List of relations Name | Type | Owner --+--+- buy | table| jeff buy_bid_seq | sequence | jeff clients_c_id_seq | sequence | jeff cppvad_clients | table| jeff cppvad_clients_cc_id_seq | sequence | jeff cppvad_info | table| jeff cppvad_info_cid_seq | sequence | jeff download | table| jeff download_dlid_seq| sequence | jeff exchange | table| jeff exchange_exid_seq| sequence | jeff gallery | table| scrappy listing | table| area902 listing_lid_seq | sequence | area902 ndict10 | table| pgsql ndict11 | table| pgsql ndict12 | table| pgsql ndict16 | table| pgsql ndict2 | table| pgsql ndict3 | table| pgsql ndict32 | table| pgsql ndict4 | table| pgsql ndict5 | table| pgsql ndict6 | table| pgsql ndict7 | table| pgsql ndict8 | table| pgsql ndict9 | table| pgsql projects | table| scrappy thepress | table| jeff thepress_id_seq | sequence | jeff ticket | table| pgsql ticket_comments | table| pgsql ticket_ticket_id_seq | sequence | pgsql ticket_times | table| pgsql (34 rows) wind=# \connect viper You are now connected to database viper. viper=# \d List of relations Name | Type | Owner --+--+- buy | table| jeff buy_bid_seq | sequence | jeff clients_c_id_seq | sequence | jeff cppvad_clients | table| jeff cppvad_clients_cc_id_seq | sequence | jeff cppvad_info | table| jeff cppvad_info_cid_seq | sequence | jeff download | table| jeff download_dlid_seq| sequence | jeff exchange | table| jeff exchange_exid_seq| sequence | jeff gallery | table| scrappy listing | table| area902 listing_lid_seq | sequence | area902 ndict10 | table| pgsql ndict11 | table| pgsql ndict12 | table| pgsql ndict16 | table| pgsql ndict2 | table| pgsql ndict3 | table| pgsql ndict32 | table| pgsql ndict4 | table| pgsql ndict5 | table| pgsql ndict6 | table| pgsql ndict7 | table| pgsql ndict8 | table| pgsql ndict9 | table| pgsql projects | table| scrappy thepress | table| jeff thepress_id_seq | sequence | jeff ticket | table| pgsql ticket_comments | table| pgsql ticket_ticket_id_seq | sequence | pgsql ticket_times | table| pgsql (34 rows) neat ... On Tue, 10 Apr 2001, Joel Burton wrote: On Tue, 10 Apr 2001, The Hermit Hacker wrote: all I did was use pg_dumpall from v7.0.3 to dump to a text file, and "psql template1 dumpfile" to load it back in again ... obviously this doesn't work like it has in the past? Marc -- Was there an error message during restore? I've been dumping/restoring w/7.1 since long before beta, w/o real problems, b
Re: [HACKERS] Re: HOLD THE PRESSES!! ... pg_dump from v7.0.3 can'timport to v7.1?
On Wed, 11 Apr 2001, Peter Eisentraut wrote: The Hermit Hacker writes: okay, not sure how we should document this, but apparently pg_dumpall doesn't work as the man page at: http://www.postgresql.org/users-lounge/docs/7.0/user/app-pgdumpall.htm appears to suggest: Now, I swore I did a 'setenv PGHOST db.hub.org' to get around it, and it still failed, but now its working ... most confusing :( But, still, pg_dumpall doesn't appear to accept the -h option in v7.0.3 Exactly right. Options to pg_dumpall are only "pg_dump options", which means things like -o or -d. But pg_dumpall also runs a few psqls, which don't see any of this. Okay, but, according to the man page, -h host *is* a pg_dump option ... pg_dump [ dbname ] pg_dump [ -h host ] [ -p port ] [ -t table ] [ -a ] [ -c ] [ -d ] [ -D ] [ -i ] [ -n ] [ -N ] [ -o ] [ -s ] [ -u ] [ -v ] [ -x ] [ dbname ] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Split Distro
On Mon, 9 Apr 2001, Henshall, Stuart - WCP wrote: When I downlaod a full tarball I want it all, I'm greedy like that. ;) If it is to be split up as standard I believe problems will arise with different versions being used together (by me most likley...). Also IMHO it will not necessarily be relised the docs have not been down loaded which means refering to older docs if there was a previous installation, or not finding any if no previous install. Also to prevent confusion it might be usefull to have the split distro in its own sub directory (eg Postgresql-7.1-Split-Distro, or somesuch), as when I first looked in on the download directory it was not imediatly obvious there was one main tarball and the rest where a split version rather than a main one with optional stuff (which is not my favoured option). Well, unless you have a broken client, the first thing you get when you enter the directory that the files are in is: = Information regarding the split distribution In the various download directories you will find alongside files with names like postgresql-XXX.tar.gz (where XXX is a version number) smaller files with the names postgresql-base-XXX.tar.gz postgresql-opt-XXX.tar.gz postgresql-docs-XXX.tar.gz postgresql-test-XXX.tar.gz The file named "postgresql-XXX.tar.gz" is the full source distribution. Each of the other four "tarballs" contains a subset of the files from the full distribution, for downloading convenience. If you download all four of them and unpack them into the same directory you will get exactly what you would have gotten had you downloaded the full distribution. The -base package is the only one that is required for successful installation. It contains the server and the essential client interfaces. The -opt package contains all parts whose compilation needs to be enabled explicitly. This includes the C++, JDBC, ODBC, Perl, Python, and Tcl interfaces, as well as multibyte support. The -docs package contains the documentation in HTML format (man pages are in -base) and the documentation sources. You don't need to download this package if you intend to browse the documentation on the web. Finally, the -test package contains the regression test suite. (Note, this scheme is new as of version 7.1RC4. Previous versions used a different, incompatible split where all subpackages where required.) === ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Truncation of char, varchar types
After v7.1 is released ... ?
On Mon, 9 Apr 2001, Peter Eisentraut wrote:
Excessively long values are currently silently truncated when they are
inserted into char or varchar fields. This makes the entire notion of
specifying a length limit for these types kind of useless, IMO. Needless
to say, it's also not in compliance with SQL.
How do people feel about changing this to raise an error in this
situation? Does anybody rely on silent truncation? Should this be
user-settable, or can those people resort to using triggers?
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(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] RPM upgrade caveats going from a beta version to RC
On Sat, 7 Apr 2001, Lamar Owen wrote: One quick note -- since 'R' 'b', the RC RPM's must be forced to install with --oldpackage, as RPM does a simple strcmp of version numbers -- 7.1RC3 7.1beta1, for instance. Just force it with --oldpackage if you have a 7.1beta RPM already installed. Huh? I always thought that ASCII R was greater then b ... *confused* in the future, would it help to have 7.2Beta? Or am I missing something? :) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] RPM upgrade caveats going from a beta version to RC
On Sun, 8 Apr 2001, Oliver Elphick wrote: The Hermit Hacker wrote: On Sat, 7 Apr 2001, Lamar Owen wrote: One quick note -- since 'R' 'b', the RC RPM's must be forced to install with --oldpackage, as RPM does a simple strcmp of version numbers -- 7.1RC3 7.1beta1, for instance. Just force it with --oldpackage if you have a 7.1beta RPM already installed. Huh? I always thought that ASCII R was greater then b ... *confused* in the future, would it help to have 7.2Beta? Or am I missing something? :) R = 82 b = 98 so b comes after R, and `blank' comes before either! Therefore 7.1 7.1RC 7.1beta ! As I suggested in another mail, let us switch to using even minor numbers for releases and odd ones for development: That means the final release of 7.1 will be called 7.2. Bugfix releases will then be 7.2.x. Meanwhile new development versions will be 7.3.x which will finally be released as 7.4, and so on... Not in this life time ... we are not going to move to a Linux-like development cycle ... *groan* ---(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] Re: A more useful way to split the distribution
On Sun, 8 Apr 2001, Peter Eisentraut wrote: I wrote: Since people suddenly seem to be suffering from bandwidth concerns I have devised a new distribution split to address this issue. I propose the following four sub-tarballs: * postgresql-XXX.base.tar.gz3.3 MB * postgresql-XXX.opt.tar.gz 1.7 MB * postgresql-XXX.docs.tar.gz1.9 MB * postgresql-XXX.test.tar.gz1.0 MB Since we're going to make a change, I'd like to change the names to postgresql-base-XXX.tar.gz etc. to align them with existing practice (cf. RPMs, GCC download). Dots should be used for format-identifying extensions. Go for it ... more a visual change then anything ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] RPM upgrade caveats going from a beta version to RC
On Sun, 8 Apr 2001, Oliver Elphick wrote: The Hermit Hacker wrote:or development: That means the final release of 7.1 will be called 7.2. Bugfix releases will then be 7.2.x. Meanwhile new development versions will be 7.3.x which will finally be released as 7.4, and so on... Not in this life time ... we are not going to move to a Linux-like development cycle ... *groan* Harrumph!! Well, pick some scheme that gives a rational set of numbers for distributions. The current one is only good for installation by hand! We do, we follow the scheme as used by ... the BSD camp :) Be thankful we don't go all the way and use 7.2-RELEASE too :) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] A more useful way to split the distribution
this only represents since 8:30am this morning ...
/source/v7.0.3/postgresql-7.0.3.support.tar.gz = 9
/source/v7.0.3/postgresql-7.0.3.test.tar.gz = 3
/source/v7.0.3/postgresql-7.0.3.docs.tar.gz = 10
/source/v7.0.3/postgresql-7.0.3.tar.gz = 22
/source/v7.0.3/postgresql-7.0.3.base.tar.gz = 9
on a side note, we almost have as many downloads of psqlodbc in that time
period:
/odbc/psqlodbc_home.html = 15
/odbc/versions/psqlodbc-07_01_0002.zip = 4
/odbc/versions/psqlodbc-07_01_0003.zip = 4
/odbc/versions/psqlodbc-07_01_0004.zip = 18
so it isn't a "fictitous crowd" that is going with the smaller chunks ...
its about 30% on a very small sample ...
On Sun, 8 Apr 2001, Peter Eisentraut wrote:
Christopher Sawtell writes:
For me and I expect many other folk on the edge of civilization it is a
total PITA to have to fiddle around and download many separate tarball
files. What I want is to be able to start a d/l going and then come back
when it's finished and know that I have _everything_ I actually need to
have a working and documented product in one shot.
Right. The only reason for splitting the distribution is to cater to the
fictitious crowd with "bandwidth problems" or those that explicitly know
that they don't need the rest. There will still be a canonical full
tarball with everything, or at least I will not put my name to something
that abolishes it. In fact, I didn't like the idea of the split tarballs
in the first place, I'm merely changing the split to something more
useful.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: RC3 ...
On Sat, 7 Apr 2001, Lamar Owen wrote: The Hermit Hacker wrote: Okay, unless someone can come up with a really good argument *for* why docs has to be included as part of the main tar file, I'm going to change the distributin generating script so that it generates a .src.tar.gz file seperate from the .doc.tar.gz file, which will make .src.tar.gz ~6Meg instead of the 8meg we are currently forcing ppl to download ... Peter E, is there anything part of the configure/make procedure that *requires* pgsql/doc to be there else it will break? If so, can you possibly put it as a test "if docs exists, deal with it, else ignore"? We're going to do this at this point in the release cycle? IOW, is there going to be an RC4 with this new packaging, or is the first-off tarball with new packaging going to be the *final* 7.1 release *raised eyebrow*? there will be an RC4, I'm just waiting to hear back from Peter E as to whether there is anything in the build process we even risk breaking ... we've been doing the whole split thing for the past release or two as it is (the FreeBSD ports collection using the individual packages instead of the great big one) so from a packaging perspective, its well tested ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] A more useful way to split the distribution
Oh, I definitely like this ... and get rid of the *large* file, which will
save all the mirrors a good deal of space over time ...
On Sun, 8 Apr 2001, Peter Eisentraut wrote:
Since people suddenly seem to be suffering from bandwidth concerns I have
devised a new distribution split to address this issue. I propose the
following four sub-tarballs:
* postgresql-XXX.base.tar.gz 3.3 MB
Everything not in one of the ones below.
* postgresql-XXX.opt.tar.gz 1.7 MB
Everything not needed unless you use one of the following configure
options: --with-CXX --with-tcl --with-perl --with-python --with-java
--enable-multibyte --enable-odbc, plus some other not-really-needed
things.
The exact directory list is
src/bin/: pgaccess pgtclsh pg_encoding
src/interfaces: odbc libpq++ libpgtcl perl5 python jdbc
src/pl/: plperl tcl
src/backend/utils/mb contrib/retep src/tools build.xml
* postgresql-XXX.docs.tar.gz 1.9 MB
doc/postgres.tar.gz doc/src doc/TODO.detail doc/internals.ps
(Note man pages are in .base.)
* postgresql-XXX.test.tar.gz 1.0 MB
src/test
All this is proportionally about the same as right now, except that each
tarball except base would now be truly optional. So someone that only
wants to use, say, PHP and psql only needs to download the base package.
Patch below. Yes/no/maybe?
--- GNUmakefile.in Sun Apr 8 01:14:23 2001
+++ GNUmakefile2Sun Apr 8 01:19:55 2001
@@ -60,7 +60,7 @@
dist: $(distdir).tar.gz
ifeq ($(split-dist), yes)
-dist: $(distdir).base.tar.gz $(distdir).docs.tar.gz $(distdir).support.tar.gz
$(distdir).test.tar.gz
+dist: $(distdir).base.tar.gz $(distdir).docs.tar.gz $(distdir).opt.tar.gz
$(distdir).test.tar.gz
endif
dist:
-rm -rf $(distdir)
@@ -68,15 +68,22 @@
$(distdir).tar: distdir
$(TAR) chf $@ $(distdir)
+opt_files := $(addprefix src/bin/, pgaccess pgtclsh pg_encoding) \
+ $(addprefix src/interfaces/, odbc libpq++ libpgtcl perl5 python jdbc) \
+ $(addprefix src/pl/, plperl tcl) \
+ src/backend/utils/mb contrib/retep src/tools build.xml
+
+docs_files := doc/postgres.tar.gz doc/src doc/TODO.detail doc/internals.ps
+
$(distdir).base.tar: distdir
- $(TAR) -c $(addprefix --exclude $(distdir)/, doc src/test src/interfaces
src/bin) \
+ $(TAR) -c $(addprefix --exclude $(distdir)/, $(docs_files) $(opt_files)
src/test) \
-f $@ $(distdir)
$(distdir).docs.tar: distdir
- $(TAR) cf $@ $(distdir)/doc
+ $(TAR) cf $@ $(addprefix $(distdir)/, $(docs_files))
-$(distdir).support.tar: distdir
- $(TAR) cf $@ $(distdir)/src/interfaces $(distdir)/src/bin
+$(distdir).opt.tar: distdir
+ $(TAR) cf $@ $(addprefix $(distdir)/, $(opt_files))
$(distdir).test.tar: distdir
$(TAR) cf $@ $(distdir)/src/test
===snip
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [HACKERS] A more useful way to split the distribution
as soon as Peter commits the changes, I'll do up an RC4 with the new
format so that everyone can test it ...
On Sat, 7 Apr 2001, Lamar Owen wrote:
The Hermit Hacker wrote:
Oh, I definitely like this ... and get rid of the *large* file, which will
save all the mirrors a good deal of space over time ...
You gonna make a set of RC3 or 4 tarballs along these lines to test? I
want to try a build with this split before doing too much else -- well,
actually, I just want to make sure I get it right before release, as I'd
like to not have but a couple of days before an RPM release after the
announcement.
Sounds like a plan.
I'm going to upload a set of RC3 RPM's tonight -- there are changes that
I need people to comment upon.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: RC3 ...
On Sat, 7 Apr 2001, Peter Eisentraut wrote: The Hermit Hacker writes: Okay, unless someone can come up with a really good argument *for* why docs has to be included as part of the main tar file, Because people want to read the documentation. get postgresql.src.tar.gz get postgresql.docs.tar.gz instead of just get postgresql.tar.gz for those that want to download the docs, same amount of time ... for those that don't want it, it sames them 2meg of download time ... I'm curious as to how many ppl would actually download those docs ... I know that I'd never do so, as I'm never on the same machine that the server is running from, so just hit the web site ... so, for those that do, we are giving them one extra step, and for those that don't, saving them time and bandwidth ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] release dates and announcements ?
Hi Peter ...
The problem this cycle has been that as soon as a package is ready
for announce, ppl have been cropping up with bugs that need to be fixed,
so we don't bother announcing it ... except to -hackers ...
We are currently at Release Candidate 3, with an RC4 most likely
going out tomorrow evening, which will also be announced to -announce as
the 'final release before release' ...
... and, if all goes well, the full relesae will be out on Friday
of this coming week ...
On Thu, 5 Apr 2001, Peter Galbavy wrote:
We are just (as per other queries recently) building a new system
using postgresql as the backend database. 7.1 seems like it is going
give us a number of essential fixes and useful features that make it
worth waiting a while.
As I have not seen announcements of the beta and RC cuts on
pgsql-announce, I would assume the development schedule is a more
closed thing than general chatter here, BUT is there an target
timetable for 7.1 (more that "when its ready" and subsequent 7.1.1
type releases ?
This information would help us decide whether to use an RC as a
development platform, moving to release later when we are ready to
test final work.
Also, would it be possible to announce alpha/beta/RC releases to
pgsql-announce ?
rgds,
--
Peter Galbavy
Knowledge Matters Ltd
http://www.knowledge.com/
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Re: RC3 ...
On Fri, 6 Apr 2001, Thomas Lockhart wrote: The docs are ready for shipment. Even better ... Okay, let's let this sit as RC3 for the next week... I'll go ahead and start generating hardcopy, though I understand that it is no longer allowed into the shipping tarball :( At 2Meg, is there a reason why we include any of the docs as part of the standard tar ball? It shouldn't be required to compile, so should be able to be left out of the main tar ball and downloaded seperately as required .. thereby shrinking the distribution to 6Meg from its current 8 ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: RC3 ...
On Fri, 6 Apr 2001, Bruce Momjian wrote: On Fri, 6 Apr 2001, Thomas Lockhart wrote: The docs are ready for shipment. Even better ... Okay, let's let this sit as RC3 for the next week... I'll go ahead and start generating hardcopy, though I understand that it is no longer allowed into the shipping tarball :( At 2Meg, is there a reason why we include any of the docs as part of the standard tar ball? It shouldn't be required to compile, so should be able to be left out of the main tar ball and downloaded seperately as required .. thereby shrinking the distribution to 6Meg from its current 8 ... Can we drop TODO.detail from the tarball too? No need to include that, I think. The web site has nice links to it now. Uncompressed it is 1.314 megs. Definitely, I think TODO.detail should be refer'd to by the TODO file, but not included in the distribution itself ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: RC3 ...
On Fri, 6 Apr 2001, Tom Lane wrote: At 2Meg, is there a reason why we include any of the docs as part of the standard tar ball? It shouldn't be required to compile, so should be able to be left out of the main tar ball and downloaded seperately as required .. thereby shrinking the distribution to 6Meg from its current 8 ... Can we drop TODO.detail from the tarball too? No need to include that, I think. The web site has nice links to it now. Uncompressed it is 1.314 megs. That strikes me as an awfully web-centric view of things. Not everyone has an always-on high-speed Internet link. If you want to make the docs and TODO.detail be a separate chunk of the split distribution, that's fine with me. But I don't agree with removing them from the full tarball. OTOH, if Marc was only thinking of removing the pre-built docs from the tarball, I don't object to that. I'm not sure why those weren't distributed as separate tarballs from the get-go. I just say that the doc sources are part of the source distribution... But, why? That sounds like a highly DSL-centric view of things *grin* If someone really wants docs, what hurts a second GET ftp call? ---(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] Re: RC3 ...
On Fri, 6 Apr 2001, Bruce Momjian wrote: That strikes me as an awfully web-centric view of things. Not everyone has an always-on high-speed Internet link. If you want to make the docs and TODO.detail be a separate chunk of the split distribution, that's fine with me. But I don't agree with removing them from the full tarball. OTOH, if Marc was only thinking of removing the pre-built docs from the tarball, I don't object to that. I'm not sure why those weren't distributed as separate tarballs from the get-go. I just say that the doc sources are part of the source distribution... But, why? That sounds like a highly DSL-centric view of things *grin* If someone really wants docs, what hurts a second GET ftp call? A major issue is that we don't regenerate docs for 7.1.1 or later, so the 7.1 docs carry for all the 7.1.X releases. That would seem to argue for a separate tarball for docs so people don't redownload the docs again for 7.1.1. Okay, unless someone can come up with a really good argument *for* why docs has to be included as part of the main tar file, I'm going to change the distributin generating script so that it generates a .src.tar.gz file seperate from the .doc.tar.gz file, which will make .src.tar.gz ~6Meg instead of the 8meg we are currently forcing ppl to download ... Peter E, is there anything part of the configure/make procedure that *requires* pgsql/doc to be there else it will break? If so, can you possibly put it as a test "if docs exists, deal with it, else ignore"? ---(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] RC3 ... anyone have anything left outstanding?
Okay, unless I hear different from anyone out there, I'm goin to roll RC3
when I get to work tomorrow, and announce it before I leave (to give it
some time to propogate to the mirrors) ...
On Thu, 5 Apr 2001, Tom Lane wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
Thomas? Did I miss your patch for the 'WITH TIMEZONE' regression test?
Still not there in CVS ...
Does anyone else have anything left outstanding that should hold me off
from doing an RC3 tomorrow?
Other than a better answer for the horology test, I think we are good
to go. The main thing that was still bothering me was Konstantin
Solodovnikov's report of database corruption. I just committed a fix
for the primary cause of that problem: turns out he was triggering a
random transfer of control inside plpgsql. (Calling through a
previously freed function pointer is uncool...) I'm guessing that the
ensuing corruption of the database can be blamed on whatever bit of code
managed to misexecute before the backend crashed completely. This is
plausible because he reports that he only saw corruption in perhaps one
out of every several hundred repetitions of the crash --- it makes sense
that you'd need to mistransfer just so to result in writing junk XLOG
entries or whatever was the direct cause of the data corruption.
Vadim is still poking at the test case Konstantin sent, but I'll bet
he won't be able to reproduce any corruption. The effects of jumping
through an overwritten function pointer would be exceedingly
system-specific.
regards, tom lane
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
[HACKERS] All's quiet ... RC3 packaging ...
I packaged up an RC2 over the weekend, and pretty much as soon as I had it
packaged and in place, before I could announce it, there were several
patches thrown in ... so, I left it there, let anyone who happened to see
it pick it up, but didn't announce it ...
Everything has been quiet, as far as patches are concerned, for the past
24+hrs ... I'd like to roll (and actually announce) an solid RC3 tonight,
with announce first thing tomorrow morning, unless anyone has anythign
they aer sitting on?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(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] All's quiet ... RC3 packaging ...
On Wed, 4 Apr 2001, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: Everything has been quiet, as far as patches are concerned, for the past 24+hrs ... I'd like to roll (and actually announce) an solid RC3 tonight, with announce first thing tomorrow morning, unless anyone has anythign they aer sitting on? I think we've got to remove that failing horology test before we wrap RC3. can we comment out the test for now, so that its still in there, but not tested? or is there absolutely non way that we can fix that in the long term? ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
RE: [HACKERS] All's quiet ... RC3 packaging ...
On Wed, 4 Apr 2001, Mikheev, Vadim wrote: Everything has been quiet, as far as patches are concerned, for the past 24+hrs ... I'd like to roll (and actually announce) an solid RC3 tonight, with announce first thing tomorrow morning, unless anyone has anythign they aer sitting on? We still have opened report about losing files after backend crash... No new input from Konstantin -:( if not easily recreateable, we can leave that one as somethign for v7.1.1 ... I'll run some tests... then again, if it is easily recreatable ... :) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: All's quiet ... RC3 packaging ...
On Wed, 4 Apr 2001, Thomas Lockhart wrote: I've got patches for the regression tests to work around the "time with time zone" DST problem. Will apply to the tree asap, and will post a message when that is done. Sounds cool ... I'll scheduale an RC3 then, around that bug being fixed ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
