node starts from the same place as the first scan did. This avoids surprising
behavior of scrollable and WITH HOLD cursors, as seen in Mark Kirkwood's bug
report of yesterday.
It's not entirely clear whether a rescan should be forced to drop out of the
syncscan mode, but for the moment I left the code behaving the same on that
point. Any change there would only be a performance and not a correctness
issue, anyway.
Back-patch to 8.3, since the unstable behavior was created by the syncscan
patch.
eg Japan. Report and fix by Itagaki Takahiro. Also fix CASHDEBUG printout
format for branches with 64-bit money type, and some minor comment cleanup.
Back-patch to 7.4, because it's broken all the way back.
In particular, always show 0 for the date type instead of null, and show
6 (the default) for time, timestamp, and interval without a declared
precision. This is now in fuller conformance with the SQL standard.
Also clarify the documentation about this.
discovered and analyzed by Konstantin Izmailov and Tom Lane
more consistent with other cases, by having an unlabeled integer field
be treated as a number of minutes or seconds respectively. These cases
are outside the spec (which insists on full "dd hh:mm" or "dd hh:mm:ss"
input respectively), so it's not much help to us in deciding what to do.
But with this change, it's uniformly the case that an unlabeled integer
will be considered as being a number of the interval's rightmost field.
The change also takes us back to the 8.3 behavior of throwing error
for certain ambiguous inputs such as INTERVAL '1 2' DAY TO MINUTE.
Per recent discussion.
Sergey Burladyan, there are at least some dank corners of libxml2 that
assume this behavior, even though their published documentation suggests
they shouldn't.
This is only really a live problem in 8.3, but the code is still there
for possible debugging use in HEAD, so patch both branches.
will throw an error, rather than possibly allowing someone to synthesize
a manual call to an internal-accepting function. As of CVS HEAD and existing
releases, all such functions are either STRICT or careful about null inputs,
so there is no current security issue here. But it seems like a good idea
to lock this down to protect against future mistakes.
In passing, similarly lock down trigger_in, language_handler_in, opaque_in,
and shell_in. These are not believed to present any security risk, but
there's still no good reason to allow nulls of these types to be created.
I left the polymorphic pseudotypes (anyelement etc) alone, since a null
of one of those types doesn't seem to be a problem --- the worst you can
say about it is that it doesn't have an underlying non-polymorphic type.
If we were to make this change during normal development, we'd just
automatically bump catversion for a pg_proc.h change. But since this doesn't
create a compatibility risk and isn't believed to be fixing a live bug, it
seems better not to force a catversion bump in late beta.
"array_agg_finalfn(null)". We should modify pg_proc entries to prevent this
query from being accepted, but let's just make the function itself secure too.
Per my note of today.
create an ABI break between 8.3 and 8.4. It is still just a wrapper around
the built-in current_query() function, but at a different implementation
level. Per my proposal.
Note: this change doesn't break 8.4beta installations, since their
SQL-language definition of the function still works fine.
The original implementation of the 3-argument form of get_raw_page() risked
core dumps if the 8.3 SQL function definition was mistakenly used with the
8.4 module, which is entirely likely after a dump-and-reload upgrade. To
protect 8.4 beta testers against upgrade problems, add a check on PG_NARGS.
In passing, fix missed additions to the uninstall script, and polish the
docs a trifle.
the <@ and @> operators. These are not in fact equivalent to the built-in
anyarray operators of the same names, because they have different behavior for
empty arrays, namely they don't think empty arrays are contained in anything.
That is mathematically wrong, no doubt, but until we can persuade GIN indexes
to implement the mathematical definition we should probably not change this.
Another reason for not changing it now is that we can't yet ensure the
opclasses will be updated correctly in a dump-and-reload upgrade. Per
recent discussions.
behavior in cases where we don't know the heap tuple count accurately; in
particular partial vacuum, but this also makes the API a bit more useful
for ANALYZE. This patch adds "estimated_count" flags to both structs so
that an approximate count can be flagged as such, and adjusts the logic
so that approximate counts are not used for updating pg_class.reltuples.
This fixes my previous complaint that VACUUM was putting ridiculous values
into pg_class.reltuples for indexes. The actual impact of that bug is
limited, because the planner only pays attention to reltuples for an index
if the index is partial; which probably explains why beta testers hadn't
noticed a degradation in plan quality from it. But it needs to be fixed.
The whole thing is a bit messy and should be redesigned in future, because
reltuples now has the potential to drift quite far away from reality when
a long period elapses with no non-partial vacuums. But this is as good as
it's going to get for 8.4.
is supposed to remove duplicate heap TIDs, we have to be sure to reduce the
tuple size and posting-item count accordingly in addItemPointersToTuple().
Failing to do so resulted in the effective injection of garbage TIDs into the
index contents, ie, whatever happened to be in the memory palloc'd for the
new tuple. I'm not sure that this fully explains the index corruption
reported by Tatsuo Ishii, but the test case I'm using no longer fails.
should use GinItemPointerGetBlockNumber/GinItemPointerGetOffsetNumber,
not ItemPointerGetBlockNumber/ItemPointerGetOffsetNumber, because the latter
will Assert() on ip_posid == 0, ie a "Min" pointer. (Thus, ItemPointerIsMin
has never worked at all, but it seems unused at present.) I'm not certain
that the case can occur in normal functioning, but it's blowing up on me
while investigating Tatsuo-san's data corruption problem. In any case it
seems like a problem waiting to bite someone.
Back-patch just in case this really is a problem for somebody in the field.
by extending the ereport() API to cater for pluralization directly. This
is better than the original method of calling ngettext outside the elog.c
code because (1) it avoids double translation, which wastes cycles and in
the worst case could give a wrong result; and (2) it avoids having to use
a different coding method in PL code than in the core backend. The
client-side uses of ngettext are not touched since neither of these concerns
is very pressing in the client environment. Per my proposal of yesterday.
__attribute__() marker so that gcc can validate the format string against
the actual arguments, get rid of overcomplicated and unsafe usage in
base_yyerror().
cosmetic --- I'm wondering if geteuid could have side effects on errno,
thus possibly resulting in a misleading error message after failure of
getpwuid.
instead just pointing out that a larger value may trigger use of GEQO.
Per Robert Haas.
In passing, do a bit of wordsmithing on the Genetic Query Optimizer section.
symbolic links with the -l option, and as Fujii Masao pointed out we ended up
overwriting files in the archive directory before this patch. Patch by
Aidan Van Dyk, Fujii Masao and me.
Backpatch to 8.3, where pg_standby was introduced.
while we're at it per request by Tom Lane. Specifically, don't try to
perform dblink_send_query() via dblink_record_internal() -- it was
inappropriate and ugly.
grounds that they don't fit into the specified interval qualifier (typmod).
This behavior, while of long standing, is clearly wrong per spec --- for
example the value INTERVAL '999' SECOND means 999 seconds and should not be
reduced to less than 60 seconds.
In some cases there could be grounds to raise an error if higher-order field
values are not given as zero; for example '1 year 1 month'::INTERVAL MONTH
should arguably be taken as an error rather than equivalent to 13 months.
However our internal representation doesn't allow us to do that in a fashion
that would consistently reject all and only the cases that a strict reading
of the spec would suggest. Also, seeing that for example INTERVAL '13' MONTH
will print out as '1 year 1 mon', we have to be careful not to create a
situation where valid data will fail to dump and reload. The present patch
therefore takes the attitude of not throwing an error in any such case.
We might want to revisit that in future but it would take more redesign
than seems prudent in late beta.
Per a complaint from Sebastien Flaesch and subsequent discussion. While
at other times we might have just postponed such an issue to the next
development cycle, 8.4 already has changed the parsing of interval literals
quite a bit in an effort to accept all spec-compliant cases correctly.
This seems like a change that should be part of that rather than coming
along later.
YEAR, DECADE, CENTURY, or MILLENIUM fields, just as it always has done for
other types of fields. The previous behavior seems to have been a hack to
avoid defining bit-positions for all these field types in DTK_M() masks,
rather than something that was really considered to be desired behavior.
But there is room in the masks for these, and we really need to tighten up
at least the behavior of DAY and YEAR fields to avoid unexpected behavior
associated with the 8.4 changes to interpret ambiguous fields based on the
interval qualifier (typmod) value. Per my example and proposed patch.
queries frequently took no lock at all on individual indexes. That's not
true any more, but we still need lock on the parent table to make it safe
to use cached lists of index OIDs.
