doesn't work, and the real reason why not is it's unclear where the path
is relative to (initdb's CWD, or the data directory?). We could make an
arbitrary decision, but it seems best to make the user be unambiguous.
Per gripe from Devrim.
the PARAM_FLAG_CONST flag on the parameters that are passed into the portal,
while the former's behavior is unchanged. This should only affect the case
where the portal is executing an EXPLAIN; it will cause the generated plan to
look more like what would be generated if the portal were actually executing
the command being explained. Per gripe from Pavel.
"make all", and then reference them there during the actual tests. This
makes the handling of these files more parallel to that of regress.so,
and in particular simplifies use of the regression tests outside the
original build tree. The PGDG and Red Hat RPMs have been doing this via
patches for a very long time. Inclusion of the change in core was requested
by Jørgen Austvik of Sun, and I can't see any reason not to.
I attempted to fix the MSVC scripts for this too, but they may need
further tweaking ...
we are on a 64-bit machine (ie, size_t is wider than int) and someone passes
in a query string that approaches or exceeds INT_MAX bytes. Also, just for
paranoia's sake, guard against similar overflows in sizing the input buffer.
The backend will not in the foreseeable future be prepared to send or receive
strings exceeding 1GB, so I didn't take the more invasive step of switching
all the buffer index variables from int to size_t; though someday we might
want to do that.
I have a suspicion that this is not the only such bug in libpq, but this
fix is enough to take care of the crash reported by Francisco Reyes.
calling convention. cube_inter and cube_distance could attempt to pfree
their input arguments, and cube_dim returned a value from a struct it
might have just pfree'd (which would only really cause a problem in a
debug build, but it's still wrong). Per bug #4208 and additional code
reading.
In HEAD and 8.3, I also made a batch of cosmetic changes to bring these
functions into line with the preferred coding style for V1 functions,
ie declare and fetch all the arguments at the top so readers can easily
see what they are.
* Add deferred trigger queue file
< This item involves dumping large queues into files.
> This item involves dumping large queues into files, or doing some
> kind of join to process all the triggers, or some bulk operation.
require SELECT privilege as well, since you normally need to read existing
column values within such commands. This behavior is according to spec,
but we'd never documented it before. Per gripe from Volkan Yazici.
This is required on Windows due to the special locale
handling for UTF8 that doesn't change the full environment.
Fixes crash with translated error messages per bugs 4180
and 4196.
Tom Lane
the associated datatype as their equality member. This means that these
opclasses can now support plain equality comparisons along with LIKE tests,
thus avoiding the need for an extra index in some applications. This
optimization was not possible when the pattern opclasses were first introduced,
because we didn't insist that text equality meant bitwise equality; but we
do now, so there is no semantic difference between regular and pattern
equality operators.
I removed the name_pattern_ops opclass altogether, since it's really useless:
name's regular comparisons are just strcmp() and are unlikely to become
something different. Instead teach indxpath.c that btree name_ops can be
used for LIKE whether or not the locale is C. This might lead to a useful
speedup in LIKE queries on the system catalogs in non-C locales.
The ~=~ and ~<>~ operators are gone altogether. (It would have been nice to
keep them for backward compatibility's sake, but since the pg_amop structure
doesn't allow multiple equality operators per opclass, there's no way.)
A not-immediately-obvious incompatibility is that the sort order within
bpchar_pattern_ops indexes changes --- it had been identical to plain
strcmp, but is now trailing-blank-insensitive. This will impact
in-place upgrades, if those ever happen.
Per discussions a couple months ago.
called before, not after, calling the assign_hook if any. This is because
push_old_value might fail (due to palloc out-of-memory), and in that case
there would be no stack entry to tell transaction abort to undo the GUC
assignment. Of course the actual assignment to the GUC variable hasn't
happened yet --- but the assign_hook might have altered subsidiary state.
Without a stack entry we won't call it again to make it undo such actions.
So this is necessary to make the world safe for assign_hooks with side
effects. Per a discussion a couple weeks ago with Magnus.
Back-patch to 8.0. 7.x did not have the problem because it did not have
allocatable stacks of GUC values.
cases. Recent buildfarm experience shows that it is sometimes possible
to execute several SQL commands in less time than the granularity of
Windows' not-very-high-resolution gettimeofday(), leading to a failure
because the tests expect the value of now() to change and it doesn't.
Also, it was recognized some time ago that the same area of the tests
could fail if local midnight passes between the insertion and the checking
of the values for 'yesterday', 'tomorrow', etc. Clean all this up per
ideas from myself and Greg Stark.
There remains a window for failure if the transaction block is entered
exactly at local midnight (so that 'now' and 'today' have the same value),
but that seems low-probability enough to live with.
Since the point of this change is mostly to eliminate buildfarm noise,
back-patch to all versions we are still actively testing.
Windows, for better performance.
Per suggestion from Andrew Chernow, but not his patch since the underlying
code was changed to deal with return values.
to go beoynd 10MB, as demonstrated by Gavin Sharry's example of dropping a
schema with ~25000 objects. The really bogus thing about the limit was that
it was enforced when a state file file was read in, not when it was written,
so you would end up with a prepared transaction that you can't commit or
abort, and the only recourse was to shut down the server and remove the file
by hand.
Raise the limit to MaxAllocSize, and enforce it also when a state file is
written. We could've removed the limit altogether, but reading in a file
larger than MaxAllocSize would fail anyway because we read it into a
palloc'd buffer.
Backpatch down to 8.1, where 2PC and this issue was introduced.
shared libraries. We've tried this before and had problems with libreadline
not linking properly on some platforms, but that seems to be a libreadline
bug that may have been fixed by now. In any case, it's early enough in the
8.4 devel cycle that we can afford to have some transient breakage while
we work out any portability problems.
On Darwin, we try -Wl,-dead_strip_dylibs, which seems to be the equivalent
incantation there.
found to have been made necessary by our skipping tty detection on Windows. Now
that we are doing tty detection on Windows the kluge is unnecessary and wrong.
IDENTITY to be more explicit about the possible hazards. Per gripe from Neil
and subsequent discussion. Eventually we may be able to get rid of this
warning, but for now it had better be there.
Formerly, the default value of wal_sync_method was determined inside xlog.c,
but now it is determined inside guc.c. guc.c was reading xlogdefs.h
without having read <fcntl.h>, leading to wrong determination of
DEFAULT_SYNC_METHOD. Obviously xlogdefs.h needs to include <fcntl.h>
for itself to ensure stable results.
Alvaro Herrera