Marko Kreen says:
This is so obvious that I would like to make it 'official'.
Seems like the theology around bytea<>text casting kept me from
seeing the simple :)
granted the lock when awakened; the signal now only means that the lock
is potentially available. The waiting process must retry its attempt
to get the lock when it gets to run. This allows the lock releasing
process to re-acquire the lock later in its timeslice. Since LWLocks
are usually held for short periods, it is possible for a process to
acquire and release the same lock many times in a timeslice. The old
spinlock-based implementation of these locks allowed for that; but the
original coding of LWLock would force a process swap for each acquisition
if there was any contention. Although this approach reopens the door to
process starvation (a waiter might repeatedly fail to get the lock),
the odds of that being a big problem seem low, and the performance cost
of the previous approach is considerable.
to the client before closing the connection. Before 7.2 this was done
correctly, but new code would simply close the connection with no report
to the client.
> Looking at this I also found an ecpg TODO list in the docs:
>
>
http://candle.pha.pa.us/main/writings/pgsql/sgml/ecpg-develop.html
>
> Seems that TODO section should be removed. Some items are done,
others
> are on the main TODO list.
That's correct. I did not fix the docs for quite some time.
Michael
--
Michael Meskes
a get on a bytea value the code was running the raw value from the server
through character set conversion, which if the character set was SQL_ASCII
would cause all 8bit characters to become ?'s.
> * Consider use of open/fctl(O_DIRECT) to minimize OS caching
> * Make blind writes go through the file descriptor cache
391d392
< * Make blind writes go through the file descriptor cache
409d409
< * Consider use of open/fctl(O_DIRECT) to minimize OS caching
---------------------------------------------------------------------------
When you run 'ecpg --help' you get the following:
-t turn on autocommit of transactions
amongst the other options... Shouldn't this be OFF as per the
documentation?
Best regards, Lee.
--
Lee Kindness, Senior Software Engineer, lkindness@csl.co.uk
Fixes time zone problems introduced by Thomas' implementation of
TIMESTAMP WITHOUT TIME ZONE which caused the behavior of the previously
appropriate routine, timestamp_date(), to change for the worse in this
context.
