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
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.
Tha
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 buffe
"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 http://www.enterpr
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 _
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
"Tom Lane" <[EMAIL PROTECTED]> writes:
> 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 an
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 anybo
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 ma
"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
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?
> Curre
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
> f
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 patc
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 f
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
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.
- Forwarde
"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
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:
http://archives.postgresql.org/pgsql-patches/2007-03/msg00163.php
18 matches
Mail list logo
