- 03 10月, 2007 10 次提交
-
-
由 Magnus Hagander 提交于
-
由 Magnus Hagander 提交于
-
由 Magnus Hagander 提交于
-
由 Magnus Hagander 提交于
on MSVC. Fix strange nonstandard version of __stdcall specifyer in thread tests on win32.
-
由 Magnus Hagander 提交于
-
由 Michael Meskes 提交于
Created export list for ecpglib.
-
由 Michael Meskes 提交于
-
由 Tom Lane 提交于
the 'overview' and 'incompatibilities' summary lists remain to be written. But I think all the raw info is there (indeed maybe too verbose).
-
由 Neil Conway 提交于
-
由 Magnus Hagander 提交于
make sure that a CPU option is actually chosen. Hiroshi Saito
-
- 02 10月, 2007 9 次提交
-
-
由 Michael Meskes 提交于
-
由 Michael Meskes 提交于
-
由 Michael Meskes 提交于
descriptor handling
-
由 Tom Lane 提交于
OpenSSL libraries --- just don't call them if they're not there. This might possibly lead to misleading error messages, but we'll just have to live with that.
-
由 Tom Lane 提交于
-
由 Magnus Hagander 提交于
This fixes potential crashes on old versions of OpenSSL and the requirement on "Applink" in new versions when building with MSVC and using different runtimes. Dave Page with fixes from me.
-
由 D'Arcy J.M. Cain 提交于
-
由 Tom Lane 提交于
-
由 Tom Lane 提交于
compiler --- at least on ARM, it does. I suspect that the varvarlena patch has been creating larger-than-intended toast pointers all along on ARM, but it wasn't exposed until the latest tweak added some Asserts that calculated the expected size in a different way. We could probably have fixed this by adding __attribute__((packed)) as is done for ItemPointerData, but struct varattrib_pointer isn't really all that useful anyway, so it seems cleanest to just get rid of it and have only struct varattrib_1b_e. Per results from buildfarm member quagga.
-
- 01 10月, 2007 10 次提交
-
-
由 Magnus Hagander 提交于
Hiroshi Saito
-
由 Bruce Momjian 提交于
-
由 Magnus Hagander 提交于
Hannes Eder
-
由 D'Arcy J.M. Cain 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Tom Lane 提交于
explicitly. This means a TOAST pointer takes 18 bytes instead of 17 --- still smaller than in 8.2 --- which seems a good tradeoff to ensure we won't have painted ourselves into a corner if we want to support multiple types of TOAST pointer later on. Per discussion with Greg Stark.
-
由 Tom Lane 提交于
ITAGAKI Takahiro's patch.
-
由 Tom Lane 提交于
while the restore_command does its thing, then 'recovering XXX' while processing the segment file. These operations are heavyweight enough that an extra PS display set shouldn't bother anyone.
-
由 Tom Lane 提交于
testing). Combine the formerly independent opclasses for the various ISN types into opfamilies. The latter causes some extra bleating from opr_sanity, since the module doesn't provide complete sets of cross-type operators, but it's still a good idea because it will give the planner more information to work with. The missing cross-type operators no longer pose a risk of unexpected planner errors in 8.3, so there's no need to insist on filling them in (and I gather it wouldn't be very sound semantically to add them all).
-
- 30 9月, 2007 11 次提交
-
-
由 Tom Lane 提交于
Found by running opr_sanity on contrib modules.
-
由 Michael Meskes 提交于
to get memory allocation thread-safe. He also did some cleaning up.
-
由 Tom Lane 提交于
Found by running opr_sanity on contrib modules.
-
由 Tom Lane 提交于
Found by running opr_sanity on contrib modules.
-
由 Tom Lane 提交于
Found by running opr_sanity on contrib modules.
-
由 Tom Lane 提交于
Found by running opr_sanity on contrib modules.
-
由 Tom Lane 提交于
any commutator operator for =(chkpass,text), so this was creating a shell operator that would fail on use. Found by opr_sanity testing.
-
由 Tom Lane 提交于
Found by running opr_sanity on contrib modules.
-
由 Tom Lane 提交于
process' PS display. After a suggestion by Simon (not exactly his patch though).
-
由 Tom Lane 提交于
CREATE INDEX CONCURRENTLY). Such an index might not have entries for every heap row and thus clustering with it would result in silent data loss. The scenario requires a pretty foolish DBA, but still ...
-
由 Tom Lane 提交于
ALTER TABLE on a composite type or ALTER TYPE on a table's rowtype. We already rejected these cases, but the error messages were a bit random and didn't always provide a HINT to use the other command type.
-