an oversize message, per suggestion from Oliver Jowett. I'm a bit
dubious that this is a real problem, since the client likely doesn't
have any more space available than the server, but it's not hard to
make it behave according to the protocol intention.
* Allow a database in tablespace t1 with tables created in tablespace t2
to be used as a template for a new database created with default
tablespace t2
All objects in the default database tablespace must have default tablespace
specifications. This is because new databases are created by copying
directories. If you mix default tablespace tables and tablespace-specified
tables in the same directory, creating a new database from such a mixed
directory would create a new database with tables that had incorrect
explicit tablespaces. To fix this would require modifying pg_class in the
newly copied database, which we don't currently do.
>
> * Allow a database in tablespace t1 with tables created in tablespace t2
> to be used as a template for a new database created with default
> tablespace t2
>
> All objects in the default database tablespace must have default tablespace
> specifications. This is because new databases are created by copying
> directories. If you mix default tablespace tables and tablespace-specified
> tables in the same directory, creating a new database from such a mixed
> directory would create a new database with tables that had incorrect
> explicit tablespaces. To fix this would require modifying pg_class in the
> newly copied database, which we don't currently do.
This does not disable the bgwriter process: it still has to wake up often
enough to collect fsync requests from backends in a timely fashion. But
it responds to the recent gripe about not being able to prevent the disk
from being spun up constantly.
specifies a new default tablespace and the template database already has
some tables in that tablespace. There isn't any way to solve this fully
without modifying the clone database's pg_class contents, so for now the
best we can do is issue a better error message.
only covered the case of assigning "", and failed to recognize that
actually setlocale(LC_MESSAGES,...) does not work at all on this platform.
Magnus Hagander, some code prettification by Tom Lane.
just stick a list-link into struct PGnotify instead. Result is a smaller
faster and more robust library (mainly because we reduce the number of
malloc's and free's involved in notify processing), plus less pollution
of application link-symbol namespace.
exportable functions. The .def files are removed from CVS, but will
still be present in distribution tarballs, since we can't assume that
Windows boxes will have sed.
pins at end of transaction, and reduce AtEOXact_Buffers to an Assert
cross-check that this was done correctly. When not USE_ASSERT_CHECKING,
AtEOXact_Buffers is a complete no-op. This gets rid of an O(NBuffers)
bottleneck during transaction commit/abort, which recent testing has shown
becomes significant above a few tens of thousands of shared buffers.
(if any) currently waited for by LockBufferForCleanup(), which is all
that we were using it for anymore. Saves some space and eliminates
proportional-to-NBuffers slowdown in UnlockBuffers().
http://archives.postgresql.org/pgsql-hackers/2004-10/msg00464.php.
This fix is intended to be permanent: it moves the responsibility for
calling SetBufferCommitInfoNeedsSave() into the tqual.c routines,
eliminating the requirement for callers to test whether t_infomask changed.
Also, tighten validity checking on buffer IDs in bufmgr.c --- several
routines were paranoid about out-of-range shared buffer numbers but not
about out-of-range local ones, which seems a tad pointless.
"make", even if nothing had changed. With this patch, it's only relinked
if it's actually updated.
//Magnus
PS. Yes, the old buildrule for the .rc file is still needed, as it's
used by pgevent.rc (or any other binary in the future that would need
it's own .rc file)
Magnus Hagander
1. Two minor cleanups:
- We don't need to call hv_exists+hv_fetch; we should just check the
return value of hv_fetch.
- newSVpv("undef",0) is the string "undef", not a real undef.
2. This should fix the bug Andrew Dunstan described in a recent -hackers
post. It replaces three bogus "eval_pv(key, 0)" calls with newSVpv,
and eliminates another redundant hv_exists+hv_fetch pair.
3. plperl_build_tuple_argument builds up a string of Perl code to create
a hash representing the tuple. This patch creates the hash directly.
4. Another minor cleanup: replace a couple of av_store()s with av_push.
5. Analogous to #3 for plperl_trigger_build_args. This patch removes the
static sv_add_tuple_value function, which does much the same as two
other utility functions defined later, and merges the functionality
into plperl_hash_from_tuple.
I have tested the patches to the best of my limited ability, but I would
appreciate it very much if someone else could review and test them too.
(Thanks to Andrew and David Fetter for their help with some testing.)
Abhijit Menon-Sen
Tom Lane