- 20 6月, 2005 10 次提交
-
-
由 Neil Conway 提交于
'register' qualifier, make some function declarations more consistent, and so on.
-
由 Tom Lane 提交于
buildfarm machines.
-
由 Tom Lane 提交于
investigate buildfarm failures.
-
由 Neil Conway 提交于
-
由 Tom Lane 提交于
-
由 Neil Conway 提交于
-
由 Tom Lane 提交于
scankeys arrays that it needs can never have more than INDEX_MAX_KEYS entries, so it's reasonable to just allocate them as fixed-size local arrays, and save the cost of palloc/pfree. Not a huge savings, but a cycle saved is a cycle earned ...
-
由 Tom Lane 提交于
-
由 Tom Lane 提交于
includes error checking and an appropriate ereport(ERROR) message. This gets rid of rather tedious and error-prone manipulation of errno, as well as a Windows-specific bug workaround, at more than a dozen call sites. After an idea in a recent patch by Heikki Linnakangas.
-
由 Tom Lane 提交于
given reasonably short lifespans for prepared transactions, this should mean that only a small minority of state files ever need to be fsynced at all. Per discussion with Heikki Linnakangas.
-
- 19 6月, 2005 5 次提交
-
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
Andreas Pflug
-
由 Bruce Momjian 提交于
Michael Fuhr
-
由 Tom Lane 提交于
not memcpy() to copy the offered key into the hash table during HASH_ENTER. This avoids possible core dump if the passed key is located very near the end of memory. Per report from Stefan Kaltenbrunner.
-
由 Tom Lane 提交于
old suggestion by Oliver Jowett. Also, add a transaction column to the pg_locks view to show the xid of each transaction holding or awaiting locks; this allows prepared transactions to be properly associated with the locks they own. There was already a column named 'transaction', and I chose to rename it to 'transactionid' --- since this column is new in the current devel cycle there should be no backwards compatibility issue to worry about.
-
- 18 6月, 2005 6 次提交
-
-
由 Tom Lane 提交于
releasing locks, so COMMIT PREPARED should too.
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
< * -Add two-phase commit [2phase] > * -Add two-phase commit
-
由 Bruce Momjian 提交于
< * Add two-phase commit [2phase] > * -Add two-phase commit [2phase]
-
由 Tom Lane 提交于
hacking by Alvaro Herrera and Tom Lane.
-
由 Bruce Momjian 提交于
> * Auto-fill the free space map by scanning the buffer cache or by > checking pages written by the background writer < * Auto-fill the free space map by scanning the buffer cache or by < checking pages written by the background writer
-
- 17 6月, 2005 6 次提交
-
-
由 Bruce Momjian 提交于
* Auto-fill the free space map by scanning the buffer cache or by checking pages written by the background writer
-
由 Bruce Momjian 提交于
Kris Jurka
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
> > * Create a bitmap of pages that need vacuuming > > Instead of sequentially scanning the entire table, have the background > writer or some other process record pages that have expired rows, then > VACUUM can look at just those pages rather than the entire table. In > the event of a system crash, the bitmap would probably be invalidated.
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
where we need fsync().
-
- 16 6月, 2005 4 次提交
-
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Tom Lane 提交于
shows that adding a circular shift between words greatly improves the distribution of hash outputs.
-
- 15 6月, 2005 9 次提交
-
-
由 Bruce Momjian 提交于
Cosimo Streppone
-
由 Bruce Momjian 提交于
-
由 Neil Conway 提交于
work if either of the join relations are empty. The logic is: (1) if the inner relation's startup cost is less than the outer relation's startup cost and this is not an outer join, read a single tuple from the inner relation via ExecHash() - if NULL, we're done (2) read a single tuple from the outer relation - if NULL, we're done (3) build the hash table on the inner relation - if hash table is empty and this is not an outer join, we're done (4) otherwise, do hash join as usual The implementation uses the new MultiExecProcNode API, per a suggestion from Tom: invoking ExecHash() now produces the first tuple from the Hash node's child node, whereas MultiExecHash() builds the hash table. I had to put in a bit of a kludge to get the row count returned for EXPLAIN ANALYZE to be correct: since ExecHash() is invoked to return a tuple, and then MultiExecHash() is invoked, we would return one too many tuples to EXPLAIN ANALYZE. I hacked around this by just manually detecting this situation and subtracting 1 from the EXPLAIN ANALYZE row count.
-
由 Neil Conway 提交于
-
由 Bruce Momjian 提交于
prevents a large number of *.backup files from existing in pg_xlog/
-
由 Bruce Momjian 提交于
Christopher Kings-Lynne
-
由 Bruce Momjian 提交于
> against rc1. It simply checks with GetDatabaseEncoding() if the current > database is in UTF-8, and if so, sets the UTF-8 flag on the arguments > that are passed to perl. This means that it isn't necessary to > utf8::upgrade() every string, as perl has no way of knowing offhand > that a string is UTF-8 -- but postgres does, because the database > encoding is specified, so it makes sense to turn the flag on. You > should also be able to properly manipulate UTF-8 strings now from > plperl as opposed to plperlu, because otherwise you'd have to use > encoding 'utf8' which was not allowed. It could also eliminate some > unexpected bugs if you assume that perl knows the string is unicode. It > is enabled only for perl 5.6 and higher, so earlier versions will not > be affected. > > I have been assured by crab that the patch is quite harmless and will > not break anything. It would be great to see it in 8 final! :-) David Kamholz
-
由 Bruce Momjian 提交于
"AT TIME ZONE", and not just the shorlist previously available. For example: SELECT CURRENT_TIMESTAMP AT TIME ZONE 'Europe/London'; works fine now. It will also obey whatever DST rules were in effect at just that date, which the previous implementation did not. It also supports the AT TIME ZONE on the timetz datatype. The whole handling of DST is a bit bogus there, so I chose to make it use whatever DST rules are in effect at the time of executig the query. not sure if anybody is actuallyi *using* timetz though, it seems pretty unpredictable just because of this... Magnus Hagander
-
由 Bruce Momjian 提交于
John Hansen
-