Thread: TODO updates

The following TODO items seem to be taken care of in current sources,
but aren't marked done in TODO:

PARSER

* INSERT INTO ... SELECT with AS columns matching result columns problem
* UNION with LIMIT fails
* CREATE TABLE x AS SELECT 1 UNION SELECT 2 fails
* CREATE TABLE test(col char(2) DEFAULT user) fails in length restriction
* mismatched types in CREATE TABLE ... DEFAULT causes problems [default]
* SELECT COUNT('asdf') FROM pg_class WHERE oid=12 crashes

URGENT

* Eliminate limits on query length

(Not quite done, but close enough to put a dash on it...)

TYPES

* Allow compression of large fields or a compressed field type

Jan just created a compressed text type, so this is partly done.
We speculated a little about adding a lower-level mechanism that would
compress whole tuples, so maybe this item should be replaced by one
mentioning that idea (it wouldn't belong in the TYPES section though).

MISC

* Allow subqueries in target list

* Overhaul mdmgr/smgr to fix double unlinking and double opens, cleanup

Is this one done, or do we still have issues there?  I think it's a lot
better than it used to be, anyway...

SOURCE CODE

* Make configure --enable-debug add -g on compile line
        regards, tom lane

> The following TODO items seem to be taken care of in current sources,
> but aren't marked done in TODO:

Thanks. I have trouble figuring out which fixes I hear about go with
which items.  I also forget they are on there.


> 
> PARSER
> 
> * INSERT INTO ... SELECT with AS columns matching result columns problem
> * UNION with LIMIT fails
> * CREATE TABLE x AS SELECT 1 UNION SELECT 2 fails
> * CREATE TABLE test(col char(2) DEFAULT user) fails in length restriction
> * mismatched types in CREATE TABLE ... DEFAULT causes problems [default]
> * SELECT COUNT('asdf') FROM pg_class WHERE oid=12 crashes

Thanks.  Done.

> 
> URGENT
> 
> * Eliminate limits on query length
> 
> (Not quite done, but close enough to put a dash on it...)

Marked.

> 
> TYPES
> 
> * Allow compression of large fields or a compressed field type
> 
> Jan just created a compressed text type, so this is partly done.
> We speculated a little about adding a lower-level mechanism that would
> compress whole tuples, so maybe this item should be replaced by one
> mentioning that idea (it wouldn't belong in the TYPES section though).

Marked.  Let someone ask for tuple compression.

> 
> MISC
> 
> * Allow subqueries in target list

Marked.

> 
> * Overhaul mdmgr/smgr to fix double unlinking and double opens, cleanup
> 
> Is this one done, or do we still have issues there?  I think it's a lot
> better than it used to be, anyway...

Marked.

> 
> SOURCE CODE
> 
> * Make configure --enable-debug add -g on compile line

Marked.

Thanks.  Updated.

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

one of the things I remember seeing discussed, and wonder about current
status on:
removal of the whole pg_vlock requirement on vacuum?

last I recall, MVCC eliminated that requirement, and also made it easier
to do a vacuum on 'live tables'?

On Mon, 22 Nov 1999, Bruce Momjian wrote:

> > The following TODO items seem to be taken care of in current sources,
> > but aren't marked done in TODO:
> 
> Thanks. I have trouble figuring out which fixes I hear about go with
> which items.  I also forget they are on there.
> 
> 
> > 
> > PARSER
> > 
> > * INSERT INTO ... SELECT with AS columns matching result columns problem
> > * UNION with LIMIT fails
> > * CREATE TABLE x AS SELECT 1 UNION SELECT 2 fails
> > * CREATE TABLE test(col char(2) DEFAULT user) fails in length restriction
> > * mismatched types in CREATE TABLE ... DEFAULT causes problems [default]
> > * SELECT COUNT('asdf') FROM pg_class WHERE oid=12 crashes
> 
> Thanks.  Done.
> 
> > 
> > URGENT
> > 
> > * Eliminate limits on query length
> > 
> > (Not quite done, but close enough to put a dash on it...)
> 
> Marked.
> 
> > 
> > TYPES
> > 
> > * Allow compression of large fields or a compressed field type
> > 
> > Jan just created a compressed text type, so this is partly done.
> > We speculated a little about adding a lower-level mechanism that would
> > compress whole tuples, so maybe this item should be replaced by one
> > mentioning that idea (it wouldn't belong in the TYPES section though).
> 
> Marked.  Let someone ask for tuple compression.
> 
> > 
> > MISC
> > 
> > * Allow subqueries in target list
> 
> Marked.
> 
> > 
> > * Overhaul mdmgr/smgr to fix double unlinking and double opens, cleanup
> > 
> > Is this one done, or do we still have issues there?  I think it's a lot
> > better than it used to be, anyway...
> 
> Marked.
> 
> > 
> > SOURCE CODE
> > 
> > * Make configure --enable-debug add -g on compile line
> 
> Marked.
> 
> Thanks.  Updated.
> 
> -- 
>   Bruce Momjian                        |  http://www.op.net/~candle
>   maillist@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 

The Hermit Hacker <scrappy@hub.org> writes:
> one of the things I remember seeing discussed, and wonder about current
> status on:
>     removal of the whole pg_vlock requirement on vacuum?

I have that on my to-do list; as far as I know it's a trivial code
change, but I just haven't gotten to it.  Maybe I'll try it tonight.
        regards, tom lane

On Mon, 22 Nov 1999, Tom Lane wrote:

> The Hermit Hacker <scrappy@hub.org> writes:
> > one of the things I remember seeing discussed, and wonder about current
> > status on:
> >     removal of the whole pg_vlock requirement on vacuum?
> 
> I have that on my to-do list; as far as I know it's a trivial code
> change, but I just haven't gotten to it.  Maybe I'll try it tonight.

is this something that could safely be back-patched into v6.5.x's tree?
have at least one project that could really use the ability to vacuum a
database without the tables being locked :)

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

The Hermit Hacker <scrappy@hub.org> writes:
>>>> removal of the whole pg_vlock requirement on vacuum?
>> 
>> I have that on my to-do list; as far as I know it's a trivial code
>> change, but I just haven't gotten to it.  Maybe I'll try it tonight.

> is this something that could safely be back-patched into v6.5.x's tree?

Well, mumble.  We could probably back-patch the ability to run more than
one vacuum at a time, since that'd be local to vacuum.c.  But I think
that'd encourage people to run vacuum in parallel with *other* database
activities, something we know is not very safe in 6.5!  That whole
set of changes I made to enforce more careful locking was mainly
motivated by Oleg's examples of crashes when system table changes were
made in parallel with vacuuming of the system tables.

In short, I think it'd be a risky thing to do.  I'm not even 100%
confident that it will work reliably in current sources; I'll check
it out before I commit it, but I won't be really comfortable until
we've had a beta-test cycle on it...
        regards, tom lane