Andreas Pflug

Michael Fuhr

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.

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.

releasing locks, so COMMIT PREPARED should too.

< * -Add two-phase commit [2phase]
> * -Add two-phase commit

< * Add two-phase commit [2phase]
> * -Add two-phase commit [2phase]

hacking by Alvaro Herrera and Tom Lane.

> * 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

* Auto-fill the free space map by scanning the buffer cache or by
  checking pages written by the background writer

Kris Jurka

>
> * 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.

where we need fsync().

shows that adding a circular shift between words greatly improves the
distribution of hash outputs.

 Cosimo Streppone

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.

prevents a large number of *.backup files from existing in pg_xlog/

Christopher Kings-Lynne

> 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

"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

John Hansen

>> 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

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

Pavel Stehule

< * -Add BETWEEN ASYMMETRIC/SYMMETRIC
> * -Add BETWEEN SYMMETRIC/ASYMMETRIC

> * -Add BETWEEN ASYMMETRIC/SYMMETRIC

EXPLAIN output.

Jean-Paul Argudo

it is sufficient to track whether a backend holds a lock or not, and
store information about transaction vs. session locks only in the
inside-the-backend LocalLockTable.  Since there can now be but one
PROCLOCK per lock per backend, LockCountMyLocks() is no longer needed,
thus eliminating some O(N^2) behavior when a backend holds many locks.
Also simplify the LockAcquire/LockRelease API by passing just a
'sessionLock' boolean instead of a transaction ID.  The previous API
was designed with the idea that per-transaction lock holding would be
important for subtransactions, but now that we have subtransactions we
know that this is unwanted.  While at it, add an 'isTempObject' parameter
to LockAcquire to indicate whether the lock is being taken on a temp
table.  This is not used just yet, but will be needed shortly for
two-phase commit.

Euler Taveira de Oliveira
Matthias Schmidt

> 	o -Have SHOW ALL show descriptions for server-side variables

Matthias Schmidt

< 	o Have SHOW ALL and pg_settings show descriptions for server-side variables
> 	o Have SHOW ALL show descriptions for server-side variables