[PATCHES] bitmapscan changes patch review

Hi, Here is a patch by Heikki Linnakangas with changes for amgetmulti index access method to amgetbitmap, which returns all matching tuples at once. The patch also introduces support for candidate matches. The original post is here:

Re: [PATCHES] [HACKERS] 'Waiting on lock'

Tom Lane [EMAIL PROTECTED] writes: Applied with some further revisions to improve the usefulness of the log messages. There's now one issued when the deadlock timeout elapses, and another when the lock is finally obtained: LOG: process 14945 still waiting for AccessExclusiveLock on

[PATCHES] [EMAIL PROTECTED]: Re: [HACKERS] EXPLAIN omits schema?]

German sent this some time ago and it never reached the list. He sent it again from Gmail but again it was lost in the void. I am forwarding it to improve the chances of it being delivered ... The patch in the fwd is not a nice MIME part but it should work without problem anyway. -

Re: [PATCHES] more autovacuum fixes

Alvaro Herrera wrote: Turns out that this problem is not serious at all, because if that palloc() fails, the whole postmaster will exit with a FATAL out of memory message. The problems in the worker code after fork are still an issue though. It _is_ still an issue -- and a very serious

[PATCHES] Load Distributed Checkpoints, take 3

Here's an updated WIP patch for load distributed checkpoints. I added a spinlock to protect the signaling fields between bgwriter and backends. The current non-locking approach gets really difficult as the patch adds two new flags, and both are more important than the existing ckpt_time_warn

Re: [PATCHES] [EMAIL PROTECTED]: Re: [HACKERS] EXPLAIN omits schema?]

Alvaro Herrera [EMAIL PROTECTED] writes: I am forwarding it to improve the chances of it being delivered ... The patch in the fwd is not a nice MIME part but it should work without problem anyway. I'm not sure why anyone would want *both* xml and regular output produced at once. The patch's

Re: [PATCHES] Preliminary GSSAPI Patches

On Tue, Jun 19, 2007 at 06:19:37PM -0700, Henry B. Hotz wrote: Such timing! I just spent most of yesterday stepping though the gssapi sample app's in Java 1.4 with someone here at work. Was thinking I needed to get back to the JDBC client and do what I promised. Also finished

Re: [PATCHES] [HACKERS] 'Waiting on lock'

Gregory Stark [EMAIL PROTECTED] writes: Is it possible for unlocking the semaphore to wake another process other than our own? In which case checking log_lock_waits before signalling the semaphore arguably locks us into having log_lock_waits be PGC_POSTMASTER. How you figure that? Currently

Re: [PATCHES] [HACKERS] 'Waiting on lock'

Tom Lane [EMAIL PROTECTED] writes: Gregory Stark [EMAIL PROTECTED] writes: Is it possible for unlocking the semaphore to wake another process other than our own? In which case checking log_lock_waits before signalling the semaphore arguably locks us into having log_lock_waits be

Re: [PATCHES] [HACKERS] 'Waiting on lock'

Gregory Stark [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] writes: How you figure that? Well I'm not clear exactly what's going on with the semaphores here. If it's possible for to be printing the messages only as a result of another backend unlocking the semaphore then making the

[PATCHES] postgresql-icu patch status

Hello, there was postgresql-icu patch for proper collation of UTF8 character set, published here: http://people.freebsd.org/~girgen/postgresql-icu/. I have been using it with 8.1 and it worked fine for me. Now I am migrating to 8.2, but, sadly, there is no patch available this version. Does

Re: [PATCHES] [HACKERS] 'Waiting on lock'

Gregory Stark [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] writes: I don't see how you arrive at that conclusion. The message is printed by the backend that is waiting for (or just obtained) a lock, dependent on its own local setting of log_lock_waits, and not dependent on who woke

Re: [PATCHES] more autovacuum fixes

Alvaro Herrera wrote: Alvaro Herrera wrote: Turns out that this problem is not serious at all, because if that palloc() fails, the whole postmaster will exit with a FATAL out of memory message. The problems in the worker code after fork are still an issue though. It _is_ still an

Re: [PATCHES] [HACKERS] 'Waiting on lock'

Tom Lane [EMAIL PROTECTED] writes: Which is always the same process: PGSemaphoreUnlock(MyProc-sem); Aaah! I just grokked what's going on with the semaphores here. It all makes a lot more sense now. Nevermind. -- Gregory Stark EnterpriseDB

[PATCHES] psql: flush output in cursor-fetch mode

psql's FETCH_COUNT feature is useful for incrementally displaying the results of a long-running query. However, psql fails to flush its output stream as new rows from the partial result set are produced, which means that partial query results may not be visible to the client until the stdio buffer

Re: [PATCHES] Load Distributed Checkpoints, take 3

Heikki Linnakangas [EMAIL PROTECTED] writes: I added a spinlock to protect the signaling fields between bgwriter and backends. The current non-locking approach gets really difficult as the patch adds two new flags, and both are more important than the existing ckpt_time_warn flag. That may

Re: [PATCHES] Load Distributed Checkpoints, take 3

Heikki Linnakangas [EMAIL PROTECTED] wrote: Here's an updated WIP patch for load distributed checkpoints. Since last patch, I did some clean up and refactoring, and added a bunch of comments, and user documentation. The only thing I don't understand is the naming of 'checkpoint_smoothing'.