Andreas Pflug

> * Fix oid2name and dbsize for tablespaces

I kept the same abbreviated letter -D, in hopes of maintaining some
modicum of backwards compatibility (though it's doubtful whether anyone
is really using scripts that invoke createdb -D ...)

but I'll leave that file alone so as not to mess up the doc patch
I trust Gavin is working on.)

> * Allow reporting of which objects are in which tablespaces
> * Allow database recovery where tablespaces can't be created
211a213,214
> 	o Add ALTER TABLESPACE to change location, name, owner
> 	o Allow objects to be moved between tablespaces

> * -Add the concept of dataspaces/tablespaces (Gavin)

There are various things left to do: contrib dbsize and oid2name modules
need work, and so does the documentation.  Also someone should think about
COMMENT ON TABLESPACE and maybe RENAME TABLESPACE.  Also initlocation is
dead, it just doesn't know it yet.

Gavin Sherry and Tom Lane.

reference pages.  Please apply.

Alvaro Herrera

same thread flags that will be used to compile thread.c.  Add comment to
make sure no one breaks it.

eliminating the former hard-wired convention about their names.  Allow
pg_cast entries to represent both type coercion and length coercion in
a single step --- this is represented by a function that takes an
extra typmod argument, just like a length coercion function.  This
nicely merges the type and length coercion mechanisms into something
at least a little cleaner than we had before.  Make use of the single-
coercion-step behavior to fix integer-to-bit coercion so that coercing
to bit(n) yields the rightmost n bits of the integer instead of the
leftmost n bits.  This should fix recurrent complaints about the odd
behavior of this coercion.  Clean up the documentation of the bit string
functions, and try to put it where people might actually find it.
Also, get rid of the unreliable heuristics in ruleutils.c about whether
to display nested coercion steps; instead require parse_coerce.c to
label them properly in the first place.

begin the shutdown checkpoint; there isn't anything left for them to do,
so we may as well ensure that they shut down sooner rather than later.
Per discussion.

<   in-progress when the server terminates abruptly
>   in-progress when the server terminated abruptly

<   in-progress when the server crashed
>   in-progress when the server terminates abruptly

< * Remove unreferenced table files and temp tables during database vacuum
<   or postmaster startup (Bruce)
> * Remove unreferenced table files created by transactions that were
>   in-progress when the server crashed
>

> * Remove unreferenced table files and temp tables during database vacuum
>   or postmaster startup (Bruce)

cidr type bit, the same as network_eq does.  This is needed for hash joins
and hash aggregation to work correctly on these types.  Per bug report
from Michael Fuhr, 2004-04-13.
Also, improve hash function for int8 as suggested by Greg Stark.

log_hostname is enabled, clean up documentation.

volatile, static, and register keywords before variables,
declared as VARCHAR.

Sergey N. Yatskevich

Bug is only latent given that sole caller is passing NBuffers, but it
could bite someone in the rear someday.

not holding the buffer's cntx_lock or io_in_progress_lock.  A recent
report from Litao Wu makes me wonder whether it is ever possible for
us to drop a buffer and forget to release its cntx_lock.  The Assert
does not fire in the regression tests, but that proves little ...

batch files anymore.

copied by the script that generates psql's help. (You can get the
spurious CRs if you use a CVS client on Windows that does line end
translation.)  Elsewhere, the patch should be totally benign.

This removes quite a number of the compile warnings I posted the other
day.

Andrew Dunstan

>> though - the GUC variable was not set in the child
>processes. So "show
>> lc_collate" would *always* return "C", for example. attached
>patch fixes
>> this.
>
>Hm.  Why were these vars not propagated by the regular
>mechanism for GUC
>variables (write_nondefault_variables or whatever it's called)?  If the
>problem is that it's not accepting PGC_INTERNAL values, then we need to
>fix it there not here, because otherwise we'll have to pass all the
>PGC_INTERNAL variables through the backend_variables file, which seems
>like a recipe for more of the same sort of bug.


Good point :-(

I think the problem is not only that it specifically does not deal with
PGC_INTERNAL variables. The problem is in the fact that
write_nondefault_variables is called *before* the locale is read
(because the locale is read from pg_control and not from any of the
"usual" ways to read it).

Attached patch is another stab at fixing it. It makes postmaster dump a
new copy of the file once it has started the database (before it accepts
any connections), which is when it will know about these parameters.
Also updates the reading code to set the context to the one where the
variable was originally set (PGC_POSTMASTER won't work for PGC_INTERNAL,
and the other way around).

We still pass lc_collate through the special file, because
set_config_option on lc_collate will speficially *not* call setlocale(),
and we need that call. But we no longer call set_config_option from
there.

Magnus Hagander