| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
with not responding to query cancel during the last stage of btree index
creation.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
var_samp(), stddev_pop(), and stddev_samp(). var_samp() and stddev_samp()
are just renamings of the historical Postgres aggregates variance() and
stddev() -- the latter names have been kept for backward compatibility.
This patch includes updates for the documentation and regression tests.
The catversion has been bumped.
NB: SQL2003 requires that DISTINCT not be specified for any of these
aggregates. Per discussion on -patches, I have NOT implemented this
restriction: if the user asks for stddev(DISTINCT x), presumably they
know what they are doing.
|
| |
|
| |
|
|
|
|
| |
Otherwise you can't cancel queries like select ... from generate_series(1,1000000).
|
|
|
|
| |
boilerplate, with approval of author.
|
| |
|
|
|
|
|
| |
tapes) for each merge step. This will give us some idea of how effective
the merge distribution algorithm is.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
performance issue during regular merge passes not only the 'final merge'
case. The original design contemplated that there would never be more
than about one free block per 'tape', hence no need for an efficient
method of keeping the free blocks sorted. But given the later addition
of merge preread behavior in tuplesort.c, there is likely to be about
work_mem worth of free blocks, which is not so small ... and for that
matter the number of tapes isn't necessarily small anymore either. So
we'd better get rid of the assumption entirely. Instead, I'm assuming
that the usage pattern will involve alternation between merge preread
and writing of a new run. This makes it reasonable to just add blocks
to the list without sorting during successive ltsReleaseBlock calls,
and then do a qsort() when we start getting ltsGetFreeBlock() calls.
Experimentation seems to confirm that there aren't many qsort calls
relative to the number of ltsReleaseBlock/ltsGetFreeBlock calls.
|
|
|
|
|
|
|
|
| |
we are doing the final merge pass on-the-fly, and not writing the data
back onto a 'tape', the number of free blocks in the tape set will become
large, leading to a lot of time wasted in ltsReleaseBlock(). There is
really no need to track the free blocks anymore in this state, so add a
simple shutoff switch. Per report from Stefan Kaltenbrunner.
|
|
|
|
|
| |
process not in the postmaster) and with the right GucSource (needs to
be a nontransactional source since we've not started an xact yet).
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
(respectively) to rename yylex and related symbols. Some were doing
it this way already, while others used not-too-reliable sed hacks in
the Makefiles. It's all nice and consistent now.
|
|
|
|
|
|
| |
not likely ever to be implemented seeing it's been removed from SQL2003.
This allows getting rid of the 'filter' version of yylex() that we had in
parser.c, which should save at least a few microseconds in parsing.
|
| |
|
|
|
|
| |
escape_string_warning = on
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- new function justify_interval(interval)
- modified function justify_hours(interval)
- modified function justify_days(interval)
These functions are defined to meet the requirements as discussed in
this thread. Specifically:
- justify_hours makes certain the sign bit on the hours
matches the sign bit on the days. It only checks the
sign bit on the days, and not the months, when
determining if the hours should be positive or negative.
After the call, -24 < hours < 24.
- justify_days makes certain the sign bit on the days
matches the sign bit on the months. It's behavior does
not depend on the hours, nor does it modify the hours.
After the call, -30 < days < 30.
- justify_interval makes sure the sign bits on all three
fields months, days, and hours are all the same. After
the call, -24 < hours < 24 AND -30 < days < 30.
Mark Dilger
|
|
|
|
| |
Kevin Grittner
|
|
|
|
| |
Markus Bertheau
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
> I've now tested this patch at home w/ 8.2HEAD and it seems to fix the
> bug. I plan on testing it under 8.1.2 at work tommorow with
> mod_auth_krb5, etc, and expect it'll work there. Assuming all goes
> well and unless someone objects I'll forward the patch to -patches.
> It'd be great to have this fixed as it'll allow us to use Kerberos to
> authenticate to phppgadmin and other web-based tools which use
> Postgres.
While playing with this patch under 8.1.2 at home I discovered a
mistake in how I manually applied one of the hunks to fe-auth.c.
Basically, the base code had changed and so the patch needed to be
modified slightly. This is because the code no longer either has a
freeable pointer under 'name' or has 'name' as NULL.
The attached patch correctly frees the string from pg_krb5_authname
(where it had been strdup'd) if and only if pg_krb5_authname returned
a string (as opposed to falling through and having name be set using
name = pw->name;). Also added a comment to this effect.
Backpatch to 8.1.X.
Stephen Frost
|
|
|
|
|
|
|
| |
PAM (such as Win32, but also unixen without PAM). On Unix, uses
OpenLDAP. On win32, uses the builin WinLDAP library.
Magnus Hagander
|
|
|
|
| |
remain as part of the multi-line query.
|
| |
|
|
|
|
|
| |
statements before the multi-line statement, rather than inside the
multi-line statement.
|
|
|
|
|
|
|
|
|
|
| |
columns of the grouping clause to avoid redundant sorts. The optimizer
is not currently capable of doing this, so this patch implements a
simple hack in the analysis phase (transformGroupClause): if any
subset of the GROUP BY clause matches a prefix of the ORDER BY list,
that prefix is moved to the front of the GROUP BY clause. This
shouldn't change the semantics of the query, and allows a redundant
sort to be avoided for queries like "GROUP BY a, b ORDER BY b".
|
|
|
|
| |
and docs from Dmitry Karasik, slightly editorialised.
|
| |
|
| |
|
|
|
|
| |
variable.
|
|
|
|
| |
Add DLLIMPORT for V1 headers, in case Win32 don't export all symbols.
|
|
|
|
| |
Patch by Joachim Wieland, somewhat reworked for clarity and portability.
|
|
|
|
| |
This is consistent with the standard definition of fopen().
|
|
|
|
|
|
| |
In particular, ensure that enlargement of the memtuples[] array doesn't
fall foul of MaxAllocSize when work_mem is very large, and don't bother
enlarging it if that would force an immediate switch into 'tape' mode anyway.
|
|
|
|
| |
per report from Stefan Kaltenbrunner.
|
|
|
|
|
|
|
| |
we'll go over to disk-based sort if we reach that limit.
This fixes Stefan Kaltenbrunner's observation that sorting can suffer an
'invalid memory alloc request size' failure when sort_mem is set large
enough. It's unfortunately not so easy to fix in 8.1 ...
|
|
|
|
|
| |
sequence such as "0x95 0x27". Patches from Akio Ishida.
Also update copyright notice.
|
|
|
|
|
|
|
|
|
|
| |
> type
Wouldn't it be better to use the UINT64CONST macro? I realize this
file is Windows-only, but we do worry about more than one compiler
on that platform.
Kris Jurka
|
| |
|
|
|
|
|
|
|
| |
gettimeofday.c:35: warning: integer constant is too large for "long"
type
Kris Jurka
|
|
|
|
|
|
|
|
|
|
|
| |
/dev/tty, but it isn't a device file and doesn't work as expected.
This fixes a known bug where psql does not prompt for a password on some
Win32 systems.
Backpatch to 8.1.X.
Robert Kinberg
|
|
|
|
|
| |
instead of the old deprecated ones.
Volkan Yazici, with some editorializing by moi.
|
|
|
|
| |
Hiroshi Saito
|
| |
|
|
|
|
|
|
| |
have. This happens when MSVC uses pg_config.h generated by MinGW.
Per report from Charles F. I. Savage
|
|
|
|
|
| |
and tighten up its sanity checking of the tag as a safety measure.
Volkan Yazici.
|