postgres.h or c.h includes a system header (such as stdio.h or
stdlib.h), there's no need to specifically include it in any of the .c
files in the backend.
Neil Conway
variation. To do this, set extra_float_digits to -3 in the geometry
test, and tweak the CIRCLE_TBL dataset to avoid values that suffer
from severe cancellation error (eg, circles that just touch an axis).
We still need two geometry 'expected' files to account for the
difference between platforms that display minus zero as '-0' and those
that just say '0', but with luck that's all we'll need.
"traditional" behavior, so the change should be transparent. Use the
command "\pset pager always" to turn it on. Anything else does the
normal toggle between "on" and "off"
Greg Sabino Mullane
in hopes of reducing platform-to-platform variations in its results.
This will cause the geometry regression test to start failing on some
platforms. I plan to update the test later today.
precision for float4, float8, and geometric types. Set it in pg_dump
so that float data can be dumped/reloaded exactly (at least on platforms
where the float I/O support is properly implemented). Initial patch by
Pedro Ferreira, some additional work by Tom Lane.
now)" item on the open items, and subsequent plpgsql function I sent in,
made me realize it was too hard to get the upper and lower bound of an
array. The attached creates two functions that I think will be very
useful when combined with the ability of plpgsql to return sets.
array_lower(array, dim_num)
- and -
array_upper(array, dim_num)
They return the value (as an int) of the upper and lower bound of the
requested dim in the provided array.
Joe Conway
not read until after we've read the port-specific header file. In
particular this should make it safer to #include system headers for
inet_aton; in general it seems that the port header file ought to be
in a position to set definitions before we do stuff based on having
a definition or not.
node now does its own grouping of the input rows, and has no need for a
preceding GROUP node in the plan pipeline. This allows elimination of
the misnamed tuplePerGroup option for GROUP, and actually saves more code
in nodeGroup.c than it costs in nodeAgg.c, as well as being presumably
faster. Restructure the API of query_planner so that we do not commit to
using a sorted or unsorted plan in query_planner; instead grouping_planner
makes the decision. (Right now it isn't any smarter than query_planner
was, but that will change as soon as it has the option to select a hash-
based aggregation step.) Despite all the hackery, no initdb needed since
only in-memory node types changed.
- First fixes a problem with a recent patch allowing setNull on updateable
resultsets
- Second removed toLower() calls on database object names. Leave it to
the caller to correctly pass lower, upper or mixed case. The driver
already has methods that the caller can use to determine that postgres
stores identifiers in lowercase. (unless the identifier was quoted when
created).
Modified Files:
jdbc/org/postgresql/jdbc1/AbstractJdbc1DatabaseMetaData.java
jdbc/org/postgresql/jdbc2/AbstractJdbc2ResultSet.java
a child table already has a matching column. Acquire appropriate
lock on child table; do the right thing with any CHECK constraints
attached to the new parent column.
where it's safe to do database access. Along the way, fix core dump
for 'DEFAULT' parameters to CREATE DATABASE. initdb forced due to
change in pg_proc entry.
(usually bison output files), not as standalone files. This hack
works around flex's insistence on including <stdio.h> before we are
able to include postgres.h; postgres.h will already be read before
the compiler starts to read the flex output file. Needed for largefile
support on some platforms.
core file to be produced for debugging, and avoids trying to run the
normal proc-exit cleanup hooks, which are likely to cause additional
problems if the system is hosed.
between signal handler and enable/disable code, avoid accumulation of
timing error due to trying to maintain remaining-time instead of
absolute-end-time, disable timeout before commit not after.
Only affects machines where MAXALIGN > 4, and is a boundary-condition
case even there, but still surprising that it's not been identified
before. Also reduce tuple chain move give-up messages from WARNING
to DEBUG1, since they are not unexpected conditions.
'empty declaration' warnings from compilers that care about such things.
Per discussion back before 7.2 release; we didn't do it then because
we'd already missed all the beta cycle ...
that tv_sec is signed; return a useful error message on timeout failure;
honor PGCONNECT_TIMEOUT environment variable in PQsetdbLogin; make code
obey documentation statement that timeout=0 means no timeout.
coercions, not implicit ones. For example, 'select abstime(1035497293)'
should succeed because there is an explicit binary coercion from int4
to abstime.
principled order; in particular ensure that all shared resources
are released before we release transaction locks. The code used
to release locks before buffer pins, which might explain an ancient
note I have about a bufmgr assertion failure I'd seen once several
years ago, and been unable to reproduce since. (Theory: someone
trying to drop a relation might be able to reach FlushRelationBuffers
before the last user of the relation had gotten around to dropping
his buffer pins.)
On Sat, Oct 19, 2002 at 12:11:32AM +0200, Peter Eisentraut wrote:
> $ ./clusterdb
> psql: could not connect to server: No such file or directory
> Is the server running locally and accepting
> connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
> psql: could not connect to server: No such file or directory
> Is the server running locally and accepting
> connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
> clusterdb: While clustering peter, the following failed:
> $
>
> This could probably handled a little more gracefully.
Yes, sorry. A patch for this is attached. Please apply.
Alvaro Herrera
item, if the page containing the current item is split while the indexscan
is stopped and holds no read-lock on the page. The current item might
move right onto a page that the indexscan holds no pin on. In the prior
code this would allow btbulkdelete to reach and possibly delete the item,
causing 'my bits moved right off the end of the world!' when the indexscan
finally resumes. Fix by chaining read-locks to the right during
_bt_restscan and requiring btbulkdelete to LockBufferForCleanup on every
page it scans, not only those with deletable items. Per my pghackers
message of 25-May-02. (Too bad no one could think of a better way.)
Also removed some unused files and fixed the which needed a small change
after the previous patch to build.xml.
Modified Files:
jdbc/Makefile jdbc/org/postgresql/core/Encoding.java
jdbc/org/postgresql/jdbc1/AbstractJdbc1Connection.java
Removed Files:
jdbc/utils/CheckVersion.java jdbc/utils/buildDriver
jdbc/utils/changelog.pl
whose conditions might yield NULL. The negated qual to attach to the
original query is properly 'x IS NOT TRUE', not 'NOT x'. This fix
produces correct behavior, but we may be taking a performance hit because
the planner is much stupider about IS NOT TRUE than it is about NOT
clauses. Future TODO: teach prepqual, other parts of planner how to
cope with BooleanTest clauses more effectively.
configure hasn't been run before trying to build.
Also cleaned up the README file and removed some obsolete files.
Modified Files:
jdbc/README jdbc/build.xml
Removed Files:
jdbc/CHANGELOG jdbc/Implementation jdbc/jdbc.jpx
SPI_prepare: they all save the prepared plan into topCxt, and so the
procCxt copy that's actually returned by SPI_prepare ought to be freed.
Diagnosis and plpython fix by Nigel Andrews, followup for other PLs
by Tom Lane.
in such a way that indexes on int8 columns would be used (by quoting the value)
caused other problems. Will need to wait for the backend to properly fix
the root problem.
Modified Files:
jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java
all utility statement types *except* a short list, per discussion a few
days ago. Add missing SetQuerySnapshot calls in VACUUM and REINDEX,
and guard against calling REINDEX DATABASE from a function (has same
problem as VACUUM).
rather than being reordered according to INSTEAD attribute for
implementation convenience.
Also, increase compiled-in recursion depth limit from 10 to 100 rewrite
cycles. 10 seems pretty marginal for situations where multiple rules
exist for the same query. There was a complaint about this recently,
so I'm going to bump it up. (Perhaps we should make the limit a GUC
parameter, but that's too close to being a new feature to do in beta.)
Ray Ontko 28-June-02. Also, fix prefix_selectivity for NAME lefthand
variables (it was bogusly assuming binary compatibility), and adjust
make_greater_string() to not call pg_mbcliplen() with invalid multibyte
data (this last per bug report that I can't find at the moment, but it
was in July '02).
> in the position that attislocal should be reset. I'll clean everything
> up and submit the patch I had originally made.
All right, this is it. This patch merely checks if child tables have
the column. If atttypid and atttypmod are the same, the attributes'
attinhcount is incremented; else the operation is aborted. If child
tables don't have the column, recursively add it.
attislocal is not touched in any case.
Alvaro Herrera
specifically ceil(), floor(), and sign(). There may be other functions
that need to be added, but this is a start. I've included some simple
regression tests.
Neil Conway
a column list. Bring its parsing of quoted names and quoted strings
somewhat up to speed --- I believe it now handles all non-error cases
the same way the backend would, but weird boundary conditions are not
necessarily done the same way.
been bit by the fact that the locale functions return pointers to
modifiable variables. I added some comments that might help us avoid
the mistake in future.
Create objects in public schema.
Make spacing/capitalization consistent.
Remove transaction block use for object creation.
Remove unneeded function GRANTs.
jdbc regression tests pass for both autocommit on and autocommit off
Modified Files:
jdbc/org/postgresql/jdbc1/AbstractJdbc1Connection.java
jdbc/org/postgresql/test/jdbc2/ConnectionTest.java
the start of the psql commandline. This is better than adding BEGIN/END
because it handles multiple queries well, and allows the return code for
psql to return the proper value.
command status at the interactive level. SPI_processed, etc are set
in the same way as the returned command status would have been set if
the same querystring were issued interactively. Per gripe from
Michael Paesold 25-Sep-02.
query that uses it. This ensures that triggers will be applied consistently
throughout a query even if someone commits changes to the relation's
pg_class.reltriggers field meanwhile. Per crash report from Laurette Cisneros.
While at it, simplify memory management in relcache.c, which no longer
needs the old hack to try to keep trigger info in the same place over
a relcache entry rebuild. (Should try to fix rd_att and rewrite-rule
access similarly, someday.) And make RelationBuildTriggers simpler and
more robust by making it build the trigdesc in working memory and then
CopyTriggerDesc() into cache memory.
ANALYZE is not quite clear when branches of the query are never
executed. So this tiny patch fixes that.
The patch is attached and can also be found at:
http://svana.org/kleptog/pgsql/pgsql-explain.patch
Martijn van Oosterhout
1) pltcl:
Add SPI_freetuptable() calls to avoid memory leaks (Me + Neil Conway)
Change sprintf()s to snprintf()s (Neil Conway)
Remove header files included elsewhere (Neil Conway)
2)plpython:
Add SPI_freetuptable() calls to avoid memory leaks
Cosemtic change to remove a compiler warning
Notes:
I have tested pltcl.c for
a) the original leak problem reported for the repeated call of spi_exec
in a TCL fragment
and
b) the subsequent report resulting from the use of spi_exec -array
in a TCL
fragment.
The plpython.c patch is exactly the same as that applied to make
revision 1.23,
the plpython_schema.sql and feature.expected sections of the patch are
also the
same as last submited, applied and subsequently reversed out. It remains
untested by me (other than via make check). However, this should be safe
provided PyString_FromString() _copies_ the given string to make a
PyObject.
Nigel J. Andrews
> > > > found in the postmaster and not included from elsewhere)
> >
> > shared libs on AIX need to be able to resolve all symbols at linkage time.
> > Those two symbols are in backend/utils/SUBSYS.o but not in the postgres
> > executable.
>
> They are defined in backend/utils/mb/conv.c and declared in
> include/mb/pg_wchar.h. They're also linked into the
> postmaster. I don't see anything unusual.
Attached is a patch to fix the mb linking problems on AIX. As a nice side effect
it reduces the duplicate symbol warnings to linking libpq.so and libecpg.so
(all shlibs that are not postmaster loadable modules).
Please apply to current (only affects AIX).
The _LARGE_FILES problem is unfortunately still open, unless Peter
has fixed it per his recent idea.
Zeugswetter Andreas SB SD
> > I'm looking at pg_dump/common.c:flagInhAttrs() and suspect that it can
> > be more or less rewritten completely, and probably should to get rigth
> > all the cases mentioned in the past attisinherited discussion. Is this
> > desirable for 7.3? It can probably be hacked around and the rewrite
> > kept for 7.4, but I think it will be much simpler after the rewrite.
>
> If it's a bug then it's fair game to fix in 7.3. But keep in mind that
> pg_dump has to behave at least somewhat sanely when called against older
> servers ... will your rewrite behave reasonably if the server does not
> offer attinhcount values?
Nah. I don't think it's worth it: I had forgotten that older versions
should be supported. I just left the code as is and added a
version-specific test.
This patch allows pg_dump to dump correctly local definition of columns.
In particular,
CREATE TABLE p1 (f1 int, f2 int);
CREATE TABLE p2 (f1 int);
CREATE TABLE c () INHERITS (p1, p2);
ALTER TABLE ONLY p1 DROP COLUMN f1;
CREATE TABLE p3 (f1 int);
CREATE TABLE c2 (f1 int) INHERITS (p3);
Will be dumped as
CREATE TABLE p1 (f2 int);
CREATE TABLE p2 (f1 int);
CREATE TABLE c (f1 int) INHERITS (p1, p2);
CREATE TABLE c2 (f1 int) INHERITS (p3);
(Previous version will dump
CREATE TABLE c () INHERITS (p1, p2)
CREATE TABLE c2 () INHERITS (p3) )
Alvaro Herrera
