'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
into postgres.c; make sure it happens for all cases that seem to need it.
Perhaps it would be better to explicitly exclude just a few utility
statement types from setting a snapshot?
in our write/flush operation any WAL entries that got queued while we
were waiting to get the WALWriteLock. This improves throughput when
transactions are small enough that several can be committed per WAL
write (ie, per disk revolution).
discussion some weeks ago. Also, add a check that two types to be
binary-equivalenced match as to typlen, typbyval, and typalign; if
they don't then it's surely a mistake to equivalence them.
just the significant fields of FunctionCallInfoData, rather than MemSet'ing
the whole struct to zero. Unused positions in the arg[] array will
thereby contain garbage rather than zeroes. This buys back some of the
performance hit from increasing FUNC_MAX_ARGS. Also tweak tuplesort.c
code for more speed by marking some routines 'inline'. All together
these changes speed up simple sorts, like count(distinct int4column),
by about 25% on a P4 running RH Linux 7.2.
client
utilities (libpq.dll and psql.exe) for win32 (missing defines,
adjustments to
includes, pedantic casting, non-existent functions) per:
http://developer.postgresql.org/docs/postgres/install-win32.html.
It compiles cleanly under Windows 2000 using Visual Studio .net. Also
compiles clean and passes all regression tests (regular and contrib)
under Linux.
In addition to a review by the usual suspects, it would be very
desirable for someone well versed in the peculiarities of win32 to take
a look.
Joe Conway
be able to do that, but the ability seems to have got lost in the
shuffle). Add a -o nextOID switch for completeness. Improve the
documentation to explain how and why to use these switches.
so that precision of result is always at least as good as you'd get from
float8 arithmetic (ie, always at least 16 digits of accuracy). Per
pg_hackers discussion a few days ago.
Vacuum must not advance pg_database.datvacuumxid nor truncate CLOG
unless it's processed *all* tables in the database. Vacuums run by
unprivileged users don't count.
(Beats head against nearest convenient wall...)
no reason to worry about the tuple commit status bits until the tuple
is inserted in a relation by heapam.c. Also, improve comments for
heap_addheader().
VACUUM FULL tuple moves. Store full-width t_infomask in WAL, rather
than storing low 8 bits and expecting to be able to reconstruct upper
bits. While at it, remove redundant t_oid field from WAL headers
(the OID, if present, is now recorded in the data portion of the tuple).
WAL version number bumped --- this does not force an initdb, you can
instead run pg_resetxlog after a clean shutdown of the old postmaster.
let's say this patch superscedes the previous one.
I have also attached a patch addressing the similar memory leak problem in
plpython. This includes a slight adjustment of the tests in the source
directory. The patch also includes a cosmetic change to remove a compiler
warning although I think the change makes the code look worse though.
BTW, by my reckoning the memory leak would occur with prepared plans and
without. If that is not the case then I've been barking up the wrong tree.
Nigel J. Andrews
ProcKill instead, where we still have a PGPROC with which to wait on
LWLocks. This fixes 'can't wait without a PROC structure' failures
occasionally seen during backend shutdown (I'm surprised they weren't
more frequent, actually). Add an Assert() to LWLockAcquire to help
catch any similar mistakes in future. Fix failure to update MyProcPid
for standalone backends and pgstat processes.
executor should not return the tuple as successfully marked, because in
fact it's been deleted. Not clear that this case has ever been seen
in practice (I think you'd have to write a SELECT FOR UPDATE that calls
a function that deletes some row the SELECT will visit later...) but we
should be consistent. Also add comments to several other places that
got it right but didn't explain what they were doing.
up to
reaching the hard limit. After opening 16(=current REST_START value)
results via pg_exec, the next pg_exec tries to find an empty slot
forever :-( . In PgSetResultId file pgtclId.c in the for loop there
has to be done a break, if res_max ist reached. The piece of code
should look like
if (resid == connid->res_max)
{
resid = 0;
break; /* the break as to be added */
}
now everything works (double available results after reaching
RES_START up to reaching RES_HARD_MAX)
Gerhard Hintermayer
contains the correct statistics. This is a partial solution for the
problem of allowing concurrent CREATE INDEX commands: unless they commit
at nearly the same instant, the second one will see the first one's
pg_class updates as committed, and won't try to update again, thus
avoiding the 'tuple concurrently updated' failure.
even when dealing with a nailed-in-cache relation; otherwise, following
VACUUM truncation of a system catalog, other backends might have
unreasonably large values of these fields.
the SQL99 standard. (I'm not sure that the character-class features are
quite right, but that can be fixed later.) Document SQL99 and POSIX
regexps as being different features; provide variants of SUBSTRING for
each.
parse analysis and into the execution code (in tablecmds.c). This
eliminates a lot of unreasonably complex code that needed to have two
or more execution paths in case it was dealing with a not-yet-created
table column vs. an already-existing one. The execution code is always
dealing with already-created tables and so needs only one case. This
also eliminates some potential race conditions (the table wasn't locked
between parse analysis and execution), makes it easy to fix the gripe
about wrong referenced-column names generating a misleading error message,
and lets us easily add a dependency from the foreign-key constraint to
the unique index that it requires the referenced table to have. (Cf.
complaint from Kris Jurka 12-Sep-2002 on pgsql-bugs.)
Also, third try at building a deletion mechanism that is not sensitive
to the order in which pg_depend entries are visited. Adding the above-
mentioned dependency exposed the folly of what dependency.c had been
doing: it failed for cases where B depends on C while both auto-depend
on A. Dropping A should succeed in this case, but was failing if C
happened to be visited before B. It appears the only solution is two
separate walks over the dependency tree.
with OPAQUE. CREATE LANGUAGE, CREATE TRIGGER, and CREATE TYPE will all
accept references to functions declared with OPAQUE --- but they will
issue a NOTICE, and will modify the function entries in pg_proc to have
the preferred type-safe argument or result types instead of OPAQUE.
Per recent pghackers discussions.
> I see in your recent bytea-LIKE patch
>
> if (datatype != BYTEAOID && pg_database_encoding_max_length()
> 1)
> len = pg_mbcliplen((const unsigned char *) workstr, len,
len - 1);
> else
> len -= -1;
>
> Surely there's one too many minus signs in that last?
Joe Conway
> moment, but they used to be used; I think the correct response is to
> put back the missing counter increments, not rip out the counters.
Ok, fair enough. It's worth noting that they've been broken for a
while -- for example, the HashJoin counter increments were broken when
you comitted r1.20 of executor/nodeHashJoin.c in May of '99.
I've attached a revised patch that doesn't remove the counters (but
doesn't increment them either: I'm not sure of all the places where
the counter should be incremented).
Neil Conway
composite types. Add a couple more lsyscache.c routines to support this,
and make use of them in some other places that were doing lookups the
hard way.
ruleutils display is not such a great idea. For arguments of functions
and operators I think we'd better keep the historical behavior of showing
such casts explicitly, to ensure that the function/operator is reparsed
the same way when the rule is reloaded. This also makes the output of
EXPLAIN less obscurantist about exactly what's happening.
to be flexible about assignment casts without introducing ambiguity in
operator/function resolution. Introduce a well-defined promotion hierarchy
for numeric datatypes (int2->int4->int8->numeric->float4->float8).
Change make_const to initially label numeric literals as int4, int8, or
numeric (never float8 anymore).
Explicitly mark Func and RelabelType nodes to indicate whether they came
from a function call, explicit cast, or implicit cast; use this to do
reverse-listing more accurately and without so many heuristics.
Explicit casts to char, varchar, bit, varbit will truncate or pad without
raising an error (the pre-7.2 behavior), while assigning to a column without
any explicit cast will still raise an error for wrong-length data like 7.3.
This more nearly follows the SQL spec than 7.2 behavior (we should be
reporting a 'completion condition' in the explicit-cast cases, but we have
no mechanism for that, so just do silent truncation).
Fix some problems with enforcement of typmod for array elements;
it didn't work at all in 'UPDATE ... SET array[n] = foo', for example.
Provide a generalized array_length_coerce() function to replace the
specialized per-array-type functions that used to be needed (and were
missing for NUMERIC as well as all the datetime types).
Add missing conversions int8<->float4, text<->numeric, oid<->int8.
initdb forced.
(notify/SI-overrun interrupt) while it is in process of doing proc_exit,
it is possible for Async_NotifyHandler() to try to start a transaction
when one is already running. This leads to Asserts() or worse. I think
it may only be possible to occur when frontend synchronization is lost
(ie, the elog(FATAL) in SocketBackend() fires), but that is a standard
occurrence after error during COPY. In any case, I have seen this
failure occur during regression tests, so it is definitely possible.
and fixed a bug found by the regression test
Modified Files:
jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java
jdbc/org/postgresql/test/jdbc2/Jdbc2TestSuite.java
Added Files:
jdbc/org/postgresql/test/jdbc2/ServerPreparedStmtTest.java
fmgr.h - it's discouraged to access fcinfo directly but there is no
macro to get the number of arguments passed to the function. Checking
the number of arguments is often useful when you have a function which
can be called like:
func('arg');
func(null);
func();
all mapping to the same C function.
the macro has a function-like appearance to match the other PG_*
macros.
Lee Kindness.
>
>>::sigh:: Is it me or does it look like all
>>of pl/pgsql is schema un-aware (ie, all of the declarations). -sc
>
>
> Yeah. The group of routines parse_word, parse_dblword, etc that are
> called by the lexer certainly all need work. There are some
> definitional issues to think about, too --- plpgsql presently relies on
> the number of names to give it some idea of what to look for, and those
> rules are probably all toast now. Please come up with a sketch of what
> you think the behavior should be before you start hacking code.
Attached is a diff -c format proposal to fix this. I've also attached a short
test script. Seems to work OK and passes all regression tests.
Here's a breakdown of how I understand plpgsql's "Special word rules" -- I
think it illustrates the behavior reasonably well. New functions added by this
patch are plpgsql_parse_tripwordtype and plpgsql_parse_dblwordrowtype:
Joe Conway
> Hannu Krosing wrote:
>
>> It seems that my last mail on this did not get through to the list
>> ;(
>>
>> Please consider renaming the new builtin function
>> split(text,text,int)
>>
>> to something else, perhaps
>>
>> split_part(text,text,int)
>>
>> (like date_part)
>>
>> The reason for this request is that 3 most popular scripting
>> languages (perl, python, php) all have also a function with similar
>> signature, but returning an array instead of single element and the
>> (optional) third argument is limit (maximum number of splits to
>> perform)
>>
>> I think that it would be good to have similar function in (some
>> future release of) postgres, but if we now let in a function with
>> same name and arguments but returning a single string instead an
>> array of them, then we will need to invent a new and not so easy to
>> recognise name for the "real" split function.
>>
>
> This is a good point, and I'm not opposed to changing the name, but
> it is too bad your original email didn't get through before beta1 was
> rolled. The change would now require an initdb, which I know we were
> trying to avoid once beta started (although we could change it
> without *requiring* an initdb I suppose).
>
> I guess if we do end up needing an initdb for other reasons, we
> should make this change too. Any other opinions? Is split_part an
> acceptable name?
>
> Also, if we add a todo to produce a "real" split function that
> returns an array, similar to those languages, I'll take it for 7.4.
No one commented on the choice of name, so the attached patch changes
the name of split(text,text,int) to split_part(text,text,int) per
Hannu's recommendation above. This can be applied without an initdb if
current beta testers are advised to run:
update pg_proc set proname = 'split_part' where proname = 'split';
in the case they want to use this function. Regression and doc fix is
also included in the patch.
Joe Conway
> where more than one schema is in use, because it doesn't trouble to
> schema-qualify table names.
Ok, the following patch should solve this concern. It also tries to
connect as little times as possible (the previous one would connect one
time per table plus one per database; this one connects two times per
database).
Alvaro Herrera