| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
since there is no need to worry about damaged pages when we are going to
overwrite them anyway from the WAL. Per recent discussion.
|
|
This should prevent some obscure cases of 'variable not in subplan target
lists', although actual failures have only been reported against 7.4 in
which the bug is much easier to trigger.
|
|
so that they do not prevent the postmaster from deleting the shmem segment
during crash recovery.
|
|
octal escape all octets outside the range 0x20 to 0x7e. This fixes
the problem pointed out by Sergey Yatskevich here:
http://archives.postgresql.org/pgsql-bugs/2003-11/msg00140.php
|
|
reported by Andrea Grassi.
|
|
7.3.5 will build out-of-the-box on Solaris.
|
|
rule into the rule.sql since it affects the latter if run in paralell.
Jan
|
|
rule split the query into one INSERT and one UPDATE where the UPDATE
then hit's the just created row without modifying the key fields again.
In this special case, the new key slipped in totally unchecked.
Jan
|
|
This is not 100% backward compatible as formerly a double quoted
type name containing a dot could be used. But I don't think may people
use dot's in the name of user defined types.
Jan
|
|
the pg_catalog schema. Per bug report some months back from Jochem van Dieten.
|
|
subquery that didn't previously have one. We have traditionally made
the caller of ResolveNew responsible for updating the hasSubLinks flag
of the outermost query, but this fails to account for hasSubLinks in
subqueries. Fix ResolveNew to handle this. We might later want to
change the calling convention of ResolveNew so that it can fix the
outer query too, simplifying callers. But I went with the localized
fix for now. Per bug report from J Smith, 20-Oct-03.
|
|
in the schema search path. Otherwise pg_dump doesn't correctly dump
scenarios where a custom opclass is created in 'public' and then used
by indexes in other schemas.
|
|
Hi There's a bug in the clusterdb script where it looks like the arguments
to the psql command are being passed in the wrong order, so it fails when
you run it on a database that is not on localhost.
Here's the output from the command:
133 anands-Computer:bin/scripts> clusterdb -h wooster -U rr granada
psql: warning: extra option wooster ignored
psql: warning: extra option -U ignored
psql: warning: extra option rr ignored
psql: warning: extra option -F: ignored
psql: warning: extra option -P ignored
psql: warning: extra option format=unaligned ignored
psql: warning: extra option -t ignored
psql: warning: extra option -c ignored
psql: warning: extra option SELECT nspname, pg_class.relname,
pg_class_2.relname FROM pg_class, pg_class AS pg_class_2 JOIN pg_namespace
ON (pg_namespace.oid=relnamespace), pg_index WHERE
pg_class.oid=pg_index.indrelid AND pg_class_2.oid=pg_index.indexrelid AND
pg_index.indisclustered AND pg_class.relowner=(SELECT usesysid FROM
pg_user WHERE usename=current_user) ignored
psql: FATAL: user "-h" does not exist
I'm attaching a patch that fixes the problem. The diff was run on
postgresql 7.3.4
Thanks a lot.
Anand Ranganathan
|
|
discussion on hackers.
Jan
|
|
_SPI_begin_call. Per gripe from Tomasz Myrta.
|
|
per bug report from Arthur Ward, who also tested this patch.
|
|
|
|
From Karel Zak.
|
|
|
|
|
|
|
|
at all, it just means 'no data available yet'.
|
|
|
|
vulnerability. This fix completely removes the ability (hack) of being able
to bind a list of values in an in clause. It was demonstrated that by allowing
that functionality you open up the possibility for certain types of
sql injection attacks. The previous fix attempts all focused on preventing
the insertion of additional sql statements (the semi-colon problem:
xxx; any new sql statement here). But that still left the ability to
change the where clause on the current statement or perform a subselect
which can circumvent applicaiton security logic and/or allow you to call
any stored function.
Modified Files:
Tag: REL7_3_STABLE
jdbc/org/postgresql/Driver.java.in
jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java
|
|
in HAVE_INT64_TIMESTAMP cases, including two potential stack smashes
when more than six fractional digits were supplied. Per bug report
from Philipp Reisner.
|
|
and send() very well at all; and in any case we can't use retval==0
for EOF due to race conditions. Make the same fixes in the backend as
are required in libpq.
|
|
|
|
bottom. Otherwise we fail to moveright when the root page was split while
we were "in flight" to it. This is not a significant problem when the root
is above the leaf level, but if the root was also a leaf (ie, a single-page
index just got split) we may return the wrong leaf page to the caller,
resulting in failure to find a key that is in fact present. Bug has existed
at least since 7.1, probably forever.
|
|
|
|
|
|
* Repair breakage in timestamp-to-date conversion for dates before 2000
|
|
|
|
and Dmitry Tkach
Modified Files:
Tag: REL7_3_STABLE
jdbc/org/postgresql/Driver.java.in
jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java
|
|
Prevent rare possibility of server startup failure (Tom)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
where the Object is a String and the type is numeric (i.e. INTEGER,LONG,etc).
The fix applies the standard escaping for these values.
Modified Files:
Tag: REL7_3_STABLE
jdbc/org/postgresql/Driver.java.in
jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java
|
|
does not dump core.
|
|
|
|
database, emit a WARNING and do nothing, rather than raising ERROR.
Per recent discussion in which we concluded this is the best way to deal
with database dumps that are reloaded into a database of a new name.
|
|
fixed incorrect initial setting of StartUpID. The logic in XLogWrite()
expects that Write->curridx is advanced to the next page as soon as
LogwrtResult points to the end of the current page, but StartupXLOG()
failed to make that happen when the old WAL ended exactly on a page
boundary. Per trouble report from Hannu Krosing.
|
|
|
|
This is no longer necessary or appropriate since we don't use zero typeid
as a wildcard anymore, and it fixes a nasty performance problem with
functions with many parameters. Per recent example from Reuven Lerner.
|
|
If they're not, the below causes problems, as the foreign key is added
after the CHECK. Cluster depends on the index name, so I thought it
wise to ensure all names are available, rather than leaving off the
CONSTRAINT "$n" portion for internally named constraints.
CREATE TABLE jkey (col integer primary key);
CREATE TABLE j (col integer REFERENCES jkey);
ALTER TABLE j ADD CHECK(col > 5);
This is a problem in 7.3 series as well as -Tip.
--
Rod Taylor <[email protected]>
|
