- 20 Jun, 2005 3 commits
-
-
Tom Lane authored
investigate buildfarm failures.
-
Neil Conway authored
-
Tom Lane authored
-
- 19 Jun, 2005 8 commits
-
-
Neil Conway authored
-
Tom Lane authored
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 authored
-
Tom Lane authored
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 authored
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.
-
Bruce Momjian authored
-
Bruce Momjian authored
Andreas Pflug
-
Bruce Momjian authored
Michael Fuhr
-
- 18 Jun, 2005 6 commits
-
-
Tom Lane authored
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 authored
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.
-
Tom Lane authored
releasing locks, so COMMIT PREPARED should too.
-
Bruce Momjian authored
-
Bruce Momjian authored
< * -Add two-phase commit [2phase] > * -Add two-phase commit
-
Bruce Momjian authored
< * Add two-phase commit [2phase] > * -Add two-phase commit [2phase]
-
- 17 Jun, 2005 6 commits
-
-
Tom Lane authored
hacking by Alvaro Herrera and Tom Lane.
-
Bruce Momjian authored
> * 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
-
Bruce Momjian authored
* Auto-fill the free space map by scanning the buffer cache or by checking pages written by the background writer
-
Bruce Momjian authored
Kris Jurka
-
Bruce Momjian authored
-
Bruce Momjian authored
> > * 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.
-
- 16 Jun, 2005 3 commits
-
-
Bruce Momjian authored
-
Bruce Momjian authored
where we need fsync().
-
Bruce Momjian authored
-
- 15 Jun, 2005 13 commits
-
-
Bruce Momjian authored
-
Bruce Momjian authored
-
Tom Lane authored
shows that adding a circular shift between words greatly improves the distribution of hash outputs.
-
Bruce Momjian authored
Cosimo Streppone
-
Bruce Momjian authored
-
Neil Conway authored
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 authored
-
Bruce Momjian authored
prevents a large number of *.backup files from existing in pg_xlog/
-
Bruce Momjian authored
Christopher Kings-Lynne
-
Bruce Momjian authored
> 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 authored
"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 authored
John Hansen
-
Bruce Momjian authored
>> assuming this sideeffect is removed, though? > >I have no problem with the hashtable, only with preloading it with >everything. What I'd like to see is that the table inherited at fork() >contains just the data for the default timezone. (At least in the >normal case where that setting hasn't been changed since postmaster >start.) Here's a patch doing this. Changes score_timezone not to use pg_tzset(), and thus not loading all the zones in the cache. The actual timezone being picked will be set using set_global_timezone() which in turn calls pg_tzset() and loads it in the cache. Magnus Hagander
-
- 14 Jun, 2005 1 commit
-
-
Bruce Momjian authored
test=# \d e Table "public.e" Column | Type | Modifiers --------+---------+----------- i | integer | not null j | integer | not null k | integer | Indexes: "e_pkey" PRIMARY KEY, btree (i, j), tablespace "haha" "ei" btree (i) "ej" btree (j), tablespace "haha" "ek" btree (k) Tablespace: "haha" Qingqing Zhou
-