>Try killing the postmaster itself in such a way as to produce a coredump
>(kill -ABORT ought to do) and get a backtrace from that.

The "gcore" command (on most modern unices) will generate a core dump of a 
running process without killing the process.  It seems that would be more
useful in this circumstance.

	-Michael Robinson


Mon, 8 May 2000 10:50:43 +0800 (+0800)
Michael Robinson <robinson@netrinsics.com>
Re: It happened again: Server hung up solid 

*sigh*

> gcore 87721
gcore: /proc/87721/file: No such file or directory



On Mon, 8 May 2000, Michael Robinson wrote:

> >Try killing the postmaster itself in such a way as to produce a coredump
> >(kill -ABORT ought to do) and get a backtrace from that.
> 
> The "gcore" command (on most modern unices) will generate a core dump of a 
> running process without killing the process.  It seems that would be more
> useful in this circumstance.
> 
> 	-Michael Robinson
> 

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 


Mon, 8 May 2000 00:41:03 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: Re: It happened again: Server hung up solid 
Are we still releasing 7.0 tomorrow?

> 
> *sigh*
> 
> > gcore 87721
> gcore: /proc/87721/file: No such file or directory
> 
> 
> 
> On Mon, 8 May 2000, Michael Robinson wrote:
> 
> > >Try killing the postmaster itself in such a way as to produce a coredump
> > >(kill -ABORT ought to do) and get a backtrace from that.
> > 
> > The "gcore" command (on most modern unices) will generate a core dump of a 
> > running process without killing the process.  It seems that would be more
> > useful in this circumstance.
> > 
> > 	-Michael Robinson
> > 
> 
> Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
> Systems Administrator @ hub.org 
> primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 
> 
> 


-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Sun, 7 May 2000 23:47:10 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Re: It happened again: Server hung up solid
On Sun, 7 May 2000, Bruce Momjian wrote:

> Are we still releasing 7.0 tomorrow?

I don't know ... this problem has me nervous, but I can't seem to
re-create it on the fly :(  It happened twice so far today, and I'm
working on improving logging to see if I can narrow it down ...

I would like to *at least* postpone until Wednesday to see if I can
recreate this between now and then ... will spend a good part of tomorrow
seeing if I can get a more decent amount of data logged, to narrow her
down ...

We still have to write up a release announcement (can someone summarize
the key features of v7.0?), so that gives us a little bit of time ...



 > 
> > 
> > *sigh*
> > 
> > > gcore 87721
> > gcore: /proc/87721/file: No such file or directory
> > 
> > 
> > 
> > On Mon, 8 May 2000, Michael Robinson wrote:
> > 
> > > >Try killing the postmaster itself in such a way as to produce a coredump
> > > >(kill -ABORT ought to do) and get a backtrace from that.
> > > 
> > > The "gcore" command (on most modern unices) will generate a core dump of a 
> > > running process without killing the process.  It seems that would be more
> > > useful in this circumstance.
> > > 
> > > 	-Michael Robinson
> > > 
> > 
> > Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
> > Systems Administrator @ hub.org 
> > primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 
> > 
> > 
> 
> 
> -- 
>   Bruce Momjian                        |  http://www.op.net/~candle
>   pgman@candle.pha.pa.us               |  (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: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 


Mon, 8 May 2000 01:08:00 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: Re: It happened again: Server hung up solid
> On Sun, 7 May 2000, Bruce Momjian wrote:
> 
> > Are we still releasing 7.0 tomorrow?
> 
> I don't know ... this problem has me nervous, but I can't seem to
> re-create it on the fly :(  It happened twice so far today, and I'm
> working on improving logging to see if I can narrow it down ...
> 
> I would like to *at least* postpone until Wednesday to see if I can
> recreate this between now and then ... will spend a good part of tomorrow
> seeing if I can get a more decent amount of data logged, to narrow her
> down ...

Isn't is something we can fix with a 7.0.1?  Seems many people are
already using 7.0 in production systems.  I just hate to see the date
slip again.

> 
> We still have to write up a release announcement (can someone summarize
> the key features of v7.0?), so that gives us a little bit of time ...

Well, you can take it off the top of the HISTORY file.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 8 May 2000 00:14:21 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Re: It happened again: Server hung up solid
On Mon, 8 May 2000, Bruce Momjian wrote:

> > On Sun, 7 May 2000, Bruce Momjian wrote:
> > 
> > > Are we still releasing 7.0 tomorrow?
> > 
> > I don't know ... this problem has me nervous, but I can't seem to
> > re-create it on the fly :(  It happened twice so far today, and I'm
> > working on improving logging to see if I can narrow it down ...
> > 
> > I would like to *at least* postpone until Wednesday to see if I can
> > recreate this between now and then ... will spend a good part of tomorrow
> > seeing if I can get a more decent amount of data logged, to narrow her
> > down ...
> 
> Isn't is something we can fix with a 7.0.1?  Seems many people are
> already using 7.0 in production systems.  I just hate to see the date
> slip again.

As I said, if we feel comfortable with this, no probs ... its not an issue
I'm going to push, since it is something that I'm finding relativley
difficult to recreate "at will" :(

> > We still have to write up a release announcement (can someone summarize
> > the key features of v7.0?), so that gives us a little bit of time ...
> 
> Well, you can take it off the top of the HISTORY file.

Great, will work this up tomorrow during the day :)  Thanks ...


Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 


Mon, 8 May 2000 01:30:18 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: Re: It happened again: Server hung up solid
> > Isn't is something we can fix with a 7.0.1?  Seems many people are
> > already using 7.0 in production systems.  I just hate to see the date
> > slip again.
> 
> As I said, if we feel comfortable with this, no probs ... its not an issue
> I'm going to push, since it is something that I'm finding relativley
> difficult to recreate "at will" :(
> 
> > > We still have to write up a release announcement (can someone summarize
> > > the key features of v7.0?), so that gives us a little bit of time ...
> > 
> > Well, you can take it off the top of the HISTORY file.
> 
> Great, will work this up tomorrow during the day :)  Thanks ...
> 

My feeling is that we can address this in 7.0.1, though our recent
pg_group fix could not be done in 7.0.1, but this doesn't seem like that
kind of problem.  Such problems are usually easily reproducible because
they represent problems with the system catalogs.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 8 May 2000 00:31:08 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Re: It happened again: Server hung up solid
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>>>> Are we still releasing 7.0 tomorrow?
>> 
>> I don't know ... this problem has me nervous, but I can't seem to
>> re-create it on the fly :(  It happened twice so far today, and I'm
>> working on improving logging to see if I can narrow it down ...
>> 
>> I would like to *at least* postpone until Wednesday to see if I can
>> recreate this between now and then ... will spend a good part of tomorrow
>> seeing if I can get a more decent amount of data logged, to narrow her
>> down ...

> Isn't is something we can fix with a 7.0.1?  Seems many people are
> already using 7.0 in production systems.  I just hate to see the date
> slip again.

That's my feeling too.  Whatever this is, it seems to be in the
postmaster not the backend.  We've hardly changed the postmaster since
6.5.3, so I suspect the problem has existed for a good while and is of
low probability.  (I have no explanation why Marc's suddenly getting
bit, but if it weren't low-probability we'd surely have more reports
than just his, no?)

Almost certainly, we will need a 7.0.1 in a few weeks, once 7.0 gets out
there and starts getting pounded on by people outside the circle of
usual suspects (sorry, been watching _Casablanca_ again).  If we delay
7.0 until we can figure out what this bug is all about, we might be
sitting on it for days or weeks.  Let's push 7.0 out the door and let
some other work go on in parallel while we try to figure out this one.

Marc, if you see it happen again could you give me a call before you
restart?  I'd like to telnet in and poke at it a little myself.
(Wait a sec, is this happening on hub, or somewhere else?)

			regards, tom lane

Mon, 08 May 2000 02:32:24 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Re: It happened again: Server hung up solid 
On Mon, 8 May 2000, The Hermit Hacker wrote:

> 
> *sigh*
> 
> > gcore 87721
> gcore: /proc/87721/file: No such file or directory

Accroding to TFM:

  The process identifier, pid, must be given on the command line.  If no
  executable image is specified, gcore will use ``/proc/<pid>/file''.

So you might try:

gcore /path_to_postmaster/postmaster 87721

or something close to that.

Vince.

> 
> 
> 
> On Mon, 8 May 2000, Michael Robinson wrote:
> 
> > >Try killing the postmaster itself in such a way as to produce a coredump
> > >(kill -ABORT ought to do) and get a backtrace from that.
> > 
> > The "gcore" command (on most modern unices) will generate a core dump of a 
> > running process without killing the process.  It seems that would be more
> > useful in this circumstance.
> > 
> > 	-Michael Robinson
> > 
> 
> Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
> Systems Administrator @ hub.org 
> primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 
> 
> 

-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net
 128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking
        Online Campground Directory    http://www.camping-usa.com
       Online Giftshop Superstore    http://www.cloudninegifts.com
==========================================================================




Mon, 8 May 2000 06:10:25 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
Re: Re: It happened again: Server hung up solid 
On Mon, 8 May 2000, Tom Lane wrote:

> Marc, if you see it happen again could you give me a call before you
> restart?  I'd like to telnet in and poke at it a little myself.
> (Wait a sec, is this happening on hub, or somewhere else?)

We built a Dual-PIII server to handle just database server, so I can give
you access to it ... 



Mon, 8 May 2000 08:46:29 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: Re: It happened again: Server hung up solid 
Thus spake The Hermit Hacker
> > Marc, if you see it happen again could you give me a call before you
> > restart?  I'd like to telnet in and poke at it a little myself.
> > (Wait a sec, is this happening on hub, or somewhere else?)
> 
> We built a Dual-PIII server to handle just database server, so I can give
> you access to it ... 

Are you talking about the new database server for Trends?  If so I should
mention that I had to restart it this morning.  Sorry, I didn't poke
around in it before doing so.  Clients couldn't log in and I couldn't wait.

I should mention that I did have to kill -9 it.  A simple kill didn't work.
I then cleared out the lock file and restarted it and connections seem to
be working again.

-- 
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.

Mon, 8 May 2000 08:09:31 -0400 (EDT)
darcy@druid.net (D'Arcy J.M. Cain)
Re: Re: It happened again: Server hung up solid
On Mon, 8 May 2000, D'Arcy J.M. Cain wrote:

> Thus spake The Hermit Hacker
> > > Marc, if you see it happen again could you give me a call before you
> > > restart?  I'd like to telnet in and poke at it a little myself.
> > > (Wait a sec, is this happening on hub, or somewhere else?)
> > 
> > We built a Dual-PIII server to handle just database server, so I can give
> > you access to it ... 
> 
> Are you talking about the new database server for Trends?  If so I
> should mention that I had to restart it this morning.  Sorry, I didn't
> poke around in it before doing so.  Clients couldn't log in and I
> couldn't wait.
> 
> I should mention that I did have to kill -9 it.  A simple kill didn't
> work. I then cleared out the lock file and restarted it and
> connections seem to be working again.

That's the server ... and that's the key problem ... there are apps
running on here that are such that delaying the restart, when it requires
it, is very difficult :(

D'Arcy, when it happens again, and if you catch it before me, can you run:

	gcore -s bin/postmaster <pid>

on it as the pgsql user before restarting it?  I just tested it here and
it dump'd core nicely ... I'm hoping it does the same if/when the
postmaster itself hangs *cross fingers*

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 


Mon, 8 May 2000 09:22:08 -0300 (ADT)
The Hermit Hacker <scrappy@HUB.ORG>
Re: Re: It happened again: Server hung up solid
Thus spake The Hermit Hacker
> D'Arcy, when it happens again, and if you catch it before me, can you run:
> 
> 	gcore -s bin/postmaster <pid>
> 
> on it as the pgsql user before restarting it?  I just tested it here and
> it dump'd core nicely ... I'm hoping it does the same if/when the
> postmaster itself hangs *cross fingers*

Will do.

-- 
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.

Mon, 8 May 2000 08:44:00 -0400 (EDT)
darcy@druid.net (D'Arcy J.M. Cain)
Re: Re: It happened again: Server hung up solid
The Hermit Hacker <scrappy@hub.org> writes:
> We still have to write up a release announcement (can someone summarize
> the key features of v7.0?), so that gives us a little bit of time ...

Man, there's a lot of stuff in the HISTORY file, isn't there?
The list at the top isn't too bad:

   Foreign Keys
          Foreign keys are now implemented, with the exception of PARTIAL
          MATCH foreign keys. Many users have been asking for this
          feature, and we are pleased to offer it.
          
   Optimizer Overhaul
          Continuing on work started a year ago, the optimizer has been
          overhauled, allowing improved query execution and better
          performance with less memory usage.
          
   Updated psql
          psql, our interactive terminal monitor, has been updated with a
          variety of new features. See the psql manual page for details.
          
   Upcoming Features
          In 7.1, we plan to have outer joins, storage for very long
          rows, and a write-ahead logging system.

Some other things that might be worth mentioning:

    Date/time datatypes cleaned up
	  We have brought the date/time datatypes into compliance with
	  the SQL standard, replacing the old partially-implemented SQL
	  date/time types with full-featured implementations.  The
	  default display format for date/time data has also changed
	  to be ISO style.  This may create a few compatibility issues
	  for old applications.  [Thomas may want to rewrite this item...]

    Query length limits removed
	  There is no longer any fixed limit on the length of a query
	  string.  (The block-size limit on the length of a stored row
	  still exists, but we hope to fix that in 7.1.)

    Removal of 8-argument limit on index keys and functions
	  The maximum number of keys in an index or arguments to a
	  function is now configurable, with default limit of 16,
	  rather than the old hard-coded limit of 8.

    Sorts and hashes now work for >2GB of data
	  Temporary files can now be split in the same way that oversize
	  relations are, so that data volume is only limited by
	  available disk space and not by OS limits on the size of an
	  individual file.

It wouldn't be hard to make this list a *lot* longer, but...

You should also make a point of the literally hundreds of smaller
features, bug fixes, and performance improvements that are in this
release.

			regards, tom lane

Mon, 08 May 2000 15:10:51 -0400
Tom Lane <tgl@sss.pgh.pa.us>
7.0 key features
>    Upcoming Features
>           In 7.1, we plan to have outer joins, storage for very long
>           rows, and a write-ahead logging system.

Oh BTW, *are* we still planning outer joins for 7.1?  I thought the plan
was to push out the querytree redesign to 7.2, and try to have a fairly
short release cycle for 7.1 instead, with TOAST and WAL as the
centerpiece attractions.

			regards, tom lane

Mon, 08 May 2000 15:17:57 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: 7.0 key features 
    Query length limits removed
  There is no longer any fixed limit on the length of a query
  string.  (The block-size limit on the length of a stored row
 still exists, but we hope to fix that in 7.1.)
  

Is the row length limit 8k? If not, what is the row length limit?

Thanks!

- Mitch



Mon, 8 May 2000 15:24:49 -0400
"Mitch Vincent" <mitch@huntsvilleal.com>
Re: 7.0 key features
"Mitch Vincent" <mitch@huntsvilleal.com> writes:
> Is the row length limit 8k? If not, what is the row length limit?

Well, it's BLCKSZ less some overhead --- BLCKSZ is 8K in a stock
installation ...

			regards, tom lane

Mon, 08 May 2000 15:24:53 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: 7.0 key features 
On Mon, 8 May 2000, Mitch Vincent wrote:

>     Query length limits removed
>   There is no longer any fixed limit on the length of a query
>   string.  (The block-size limit on the length of a stored row
>  still exists, but we hope to fix that in 7.1.)
>   
> 
> Is the row length limit 8k? If not, what is the row length limit?

Right now, the tuple length is still at 8k ... Jan's TOAST implementation
is designed to finally rid us of that as well ...



Mon, 8 May 2000 16:27:07 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: 7.0 key features
Mitch Vincent wrote:
> 
>     Query length limits removed
>   There is no longer any fixed limit on the length of a query
>   string.  (The block-size limit on the length of a stored row
>  still exists, but we hope to fix that in 7.1.)
> 
> 
> Is the row length limit 8k? If not, what is the row length limit?

8k by default, max is 32K if you recompile-

> 
> Thanks!
> 
> - Mitch

Mon, 08 May 2000 22:39:43 +0300
Hannu Krosing <hannu@tm.ee>
Re: 7.0 key features
Vince Vielhaber wrote:
> 
> On Mon, 8 May 2000, D'Arcy J.M. Cain wrote:
> 
> > It would kind of have to be, wouldn't it, if the row it had to fit in
> > had that limit?
> 
> BLOBs aren't.  Or did I miss something somewhere?  I've always understood
> the text datatype to be simply a text version of a BLOB.

Not yet in Postgres

> Not necessarily in Postgres, but elsewhere.

Maybe elsewere.

In postgres it will be a new kind of (B)LOB, different from current LOs.

Current LOs are again separate from TEXT even ODBC and JDBC use them for 
other BLOB support.

---------------
Hannu

Mon, 08 May 2000 22:47:09 +0300
Hannu Krosing <hannu@tm.ee>
Re: 7.0 key features
On Mon, 8 May 2000, Tom Lane wrote:

> "Mitch Vincent" <mitch@huntsvilleal.com> writes:
> > Is the row length limit 8k? If not, what is the row length limit?
> 
> Well, it's BLCKSZ less some overhead --- BLCKSZ is 8K in a stock
> installation ...

A text datatype isn't limited to that too, is it?

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net
 128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking
        Online Campground Directory    http://www.camping-usa.com
       Online Giftshop Superstore    http://www.cloudninegifts.com
==========================================================================




Mon, 8 May 2000 16:16:47 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
Re: 7.0 key features 
Thus spake Vince Vielhaber
> On Mon, 8 May 2000, Tom Lane wrote:
> 
> > "Mitch Vincent" <mitch@huntsvilleal.com> writes:
> > > Is the row length limit 8k? If not, what is the row length limit?
> > 
> > Well, it's BLCKSZ less some overhead --- BLCKSZ is 8K in a stock
> > installation ...
> 
> A text datatype isn't limited to that too, is it?

It would kind of have to be, wouldn't it, if the row it had to fit in
had that limit?

-- 
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.

Mon, 8 May 2000 16:33:02 -0400 (EDT)
darcy@druid.net (D'Arcy J.M. Cain)
Re: 7.0 key features
On Mon, 8 May 2000, D'Arcy J.M. Cain wrote:

> Thus spake Vince Vielhaber
> > On Mon, 8 May 2000, Tom Lane wrote:
> > 
> > > "Mitch Vincent" <mitch@huntsvilleal.com> writes:
> > > > Is the row length limit 8k? If not, what is the row length limit?
> > > 
> > > Well, it's BLCKSZ less some overhead --- BLCKSZ is 8K in a stock
> > > installation ...
> > 
> > A text datatype isn't limited to that too, is it?
> 
> It would kind of have to be, wouldn't it, if the row it had to fit in
> had that limit?

BLOBs aren't.  Or did I miss something somewhere?  I've always understood
the text datatype to be simply a text version of a BLOB.  Not necessarily
in Postgres, but elsewhere.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net
 128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking
        Online Campground Directory    http://www.camping-usa.com
       Online Giftshop Superstore    http://www.cloudninegifts.com
==========================================================================




Mon, 8 May 2000 16:39:30 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
Re: 7.0 key features
This brings me to another question. Hopefully there isn't a 8k (max 32k)
limit on TEXT fields -- I'll assume there isn't a limit on TEXT fields for
the purpose of this email..

What do you guys think of storing whole text files (normally stored in a
flat file) in the database for searching purposes? Would a search on an
indexed TEXT field be slow as mud?

I'll try it on my home machine for kicks, just wanted to get some
theoretical opinions...

Thanks!

- Mitch

"The only real failure is quitting."

> > Is the row length limit 8k? If not, what is the row length limit?
>
> 8k by default, max is 32K if you recompile-



Mon, 8 May 2000 16:51:20 -0400
"Mitch Vincent" <mitch@huntsvilleal.com>
TEXT question... Was  7.0 key features
Mitch Vincent wrote:
> 
> This brings me to another question. Hopefully there isn't a 8k (max 32k)
> limit on TEXT fields -- 

No, they currently just have to fit in a record ;)

They will be stored (optionally) separately in future (7.1)

> 
> What do you guys think of storing whole text files (normally stored in a
> flat file) in the database for searching purposes? Would a search on an
> indexed TEXT field be slow as mud?

Depends on search ;)

like "a%" may not be too slow (unless the indexes on text field will be 
disallowed initially, as has been mentioned some times)

PG does not yet have a native full-text index. There is a suboptimal
implementation using triggers and extra tables in contrib.

----------
Hannu

Tue, 09 May 2000 00:49:21 +0300
Hannu Krosing <hannu@tm.ee>
Re: TEXT question... Was  7.0 key features
Thus spake Vince Vielhaber
> > > > Well, it's BLCKSZ less some overhead --- BLCKSZ is 8K in a stock
> > > > installation ...
> > > 
> > > A text datatype isn't limited to that too, is it?
> > 
> > It would kind of have to be, wouldn't it, if the row it had to fit in
> > had that limit?
> 
> BLOBs aren't.  Or did I miss something somewhere?  I've always understood
> the text datatype to be simply a text version of a BLOB.  Not necessarily
> in Postgres, but elsewhere.

You mean text FILES, not datatype.  There is a base type called text
which has to fit in the row so it is naturally limited to the row size.

-- 
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.

Mon, 8 May 2000 18:15:47 -0400 (EDT)
darcy@druid.net (D'Arcy J.M. Cain)
Re: 7.0 key features
> >    Upcoming Features
> >           In 7.1, we plan to have outer joins, storage for very long
> >           rows, and a write-ahead logging system.
> 
> Oh BTW, *are* we still planning outer joins for 7.1?  I thought the plan
> was to push out the querytree redesign to 7.2, and try to have a fairly
> short release cycle for 7.1 instead, with TOAST and WAL as the
> centerpiece attractions.

Oops, you are right.  At the time I wrote this, we were going to do a
normal period 7.1.

I have updated the HISTORY and release.sgml to say 7.1 _or_ 7.2.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Mon, 8 May 2000 19:53:16 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Re: 7.0 key features
> Man, there's a lot of stuff in the HISTORY file, isn't there?
> The list at the top isn't too bad:

Ack! I didn't realize that there was a plain text HISTORY file, since
it *should* come from the SGML sources. I had changed the wording, and
eliminated the prediction for features in the next release (that
should appear on the web site imho, not in the release docs).

Check the release notes (INSTALL and release.htm) for the latest
wording.

Let me see if I can get the HISTORY file replaced with something
fresh; however, it is not a show-stopper so if you've already done the
build don't worry about it.

                     - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Tue, 09 May 2000 05:30:10 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: 7.0 key features
> > Man, there's a lot of stuff in the HISTORY file, isn't there?
> > The list at the top isn't too bad:
> 
> Ack! I didn't realize that there was a plain text HISTORY file, since
> it *should* come from the SGML sources. I had changed the wording, and
> eliminated the prediction for features in the next release (that
> should appear on the web site imho, not in the release docs).

I have been changing both each time.  History does not generate
directly from SGML because it needs to be one big file with proper
breaks between sections.

I left the prediction in because this is not a big-feature release, and
I wanted people to know what we were planning.  This is the first
release where we have definate plans for new features in the next
release.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 9 May 2000 08:20:00 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: 7.0 key features
> I left the prediction in because this is not a big-feature release, and
> I wanted people to know what we were planning.  This is the first
> release where we have definate plans for new features in the next
> release.

Seems most appropriate to put this info on the web site, where it is
less formal and more easily changed/updated/removed. We already could
be mentioning the TOAST work, etc etc as ongoing projects and outer
joins are in that category too.

Vince, is there a place where we could put this kind of stuff?
Somewhere in the developer's lounge area? Perhaps a summary page of
ongoing projects and then links to specific pages for each project
where necessary?

                     - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Tue, 09 May 2000 13:37:46 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: 7.0 key features
On Tue, 9 May 2000, Thomas Lockhart wrote:

> > I left the prediction in because this is not a big-feature release, and
> > I wanted people to know what we were planning.  This is the first
> > release where we have definate plans for new features in the next
> > release.
> 
> Seems most appropriate to put this info on the web site, where it is
> less formal and more easily changed/updated/removed. We already could
> be mentioning the TOAST work, etc etc as ongoing projects and outer
> joins are in that category too.
> 
> Vince, is there a place where we could put this kind of stuff?
> Somewhere in the developer's lounge area? Perhaps a summary page of
> ongoing projects and then links to specific pages for each project
> where necessary?

Already is:  http://www.Postgresql.org/projects/index.html   Jan's
been maintaining it.  The projects on that page aren't necessarily
planned for the next release tho (what's there now very well might 
be but that's not the intent of the page), so we may want to have
a more specific list pointing there.

BTW, I'm currently waiting on some graphics (already have some) to 
put the Developer's Corner and User's Lounge online.  With some out
of town travel coming up I may not be able to get it online till 
the beginning of June tho.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: vev@michvhf.com    http://www.pop4.net
 128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking
        Online Campground Directory    http://www.camping-usa.com
       Online Giftshop Superstore    http://www.cloudninegifts.com
==========================================================================




Tue, 9 May 2000 10:01:09 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
Re: 7.0 key features