Hello,
i've written a bugreport which got the ID #5904, but i'm not able to
find it in the mailinglist. Is it lost? Maybe there is a problem with
the Umlaut in my name?
Now for the Problem: There is a problem with the translation of the
english word "March" to the german "März". Instead of "
The following bug has been logged online:
Bug reference: 5914
Logged by: YAMAMOTO Takashi
Email address: y...@mwd.biglobe.ne.jp
PostgreSQL version: 9.1devel
Operating system: NetBSD
Description:locking error in heap_fetch
Details:
heap_fetch calls CheckForSerializab
Hello,
i've written a bugreport which got the ID #5904, but i'm not able to
find it in the mailinglist. Is it lost? Maybe there is a problem with
the Umlaut in my name?
Now for the Problem: There is a problem with the translation of the
english word "March" to the german "März". Instead of "
Hi,
On Friday, March 04, 2011 10:16:24 AM Torsten Zühlsdorff wrote:
> Now for the Problem: There is a problem with the translation of the
> english word "March" to the german "März". Instead of "März" i get
> "MäRz" (with uppercase "r").
>
> You can reproduce it as follow:
> # SET lc_time = "de
Josh Berkus writes:
> echo $TZ returns nothing. We've checked several Ubuntu systems, and it
> seems that Ubuntu does not set $TZ.
You can tweak that easily by editing /etc/postgresql/8.4/main/environment.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation
Hello Andres,
Now for the Problem: There is a problem with the translation of the
english word "March" to the german "März". Instead of "März" i get
"MäRz" (with uppercase "r").
You can reproduce it as follow:
# SET lc_time = "de_DE.UTF-8";
# SELECT to_char('2011-03-04 00:00:01'::date, 'TMMon
On Fri, Mar 4, 2011 at 14:34, Torsten Zühlsdorff
wrote:
> Hello Andres,
>
>>> Now for the Problem: There is a problem with the translation of the
>>> english word "March" to the german "März". Instead of "März" i get "MäRz"
>>> (with uppercase "r").
>>>
>>> You can reproduce it as follow:
>>> # SE
Hello,
Now for the Problem: There is a problem with the translation of the
english word "March" to the german "März". Instead of "März" i get "MäRz"
(with uppercase "r").
You can reproduce it as follow:
# SET lc_time = "de_DE.UTF-8";
# SELECT to_char('2011-03-04 00:00:01'::date, 'TMMonth ')
On 04.03.2011 10:34, YAMAMOTO Takashi wrote:
The following bug has been logged online:
Bug reference: 5914
Logged by: YAMAMOTO Takashi
Email address: y...@mwd.biglobe.ne.jp
PostgreSQL version: 9.1devel
Operating system: NetBSD
Description:locking error in heap_fetch
Magnus Hagander writes:
> On Fri, Mar 4, 2011 at 00:58, Tom Lane wrote:
>>> One small problem is that if the sslmode is "verify-ca" or
>>> "verify-full", failure to find the root cert file is an error,
>>> and that error message normally includes the pathname at which
>>> the cert file was sought
"YAMAMOTO Takashi" wrote:
> heap_fetch calls CheckForSerializableConflictOut without buffer
> locked. it ends up an assertion failure in
> SetBufferCommitInfoNeedsSave.
>
>
> diff --git a/src/backend/access/heap/heapam.c
> b/src/backend/access/heap/heapam.c
> index 7dcc601..89697f6 100644
> --
Christian Kastner writes:
> On 03/04/2011 12:58 AM, Tom Lane wrote:
>> Attached is an untested patch which I'd appreciate if you (or somebody
>> else who uses SSL connections more than I do) could test.
> I can confirm that this fixes the issue for me.
> I tested this with psql and PGSSLMODE={di
The following bug has been logged online:
Bug reference: 5915
Logged by: YAMAMOTO Takashi
Email address: y...@mwd.biglobe.ne.jp
PostgreSQL version: 9.1devel
Operating system: NetBSD
Description:OldSerXidAdd inflates pg_serial too much
Details:
a seemingly wrong math
"YAMAMOTO Takashi" wrote:
> a seemingly wrong math in OldSerXidAdd makes it busy writing zeros
> to pg_serial.
>
> [patch]
Your fix looks correct to me -- we want to get from a SLRU segment
number to the first page of that segment, so SLRU_PAGES_PER_SEGMENT
is the right multiplier.
Thanks!
On ons, 2011-03-02 at 21:59 +0200, Peter Eisentraut wrote:
> On ons, 2011-03-02 at 18:00 +0200, Heikki Linnakangas wrote:
> > Hmm, regardless of what's causing this, I wonder if we should check
> > that the locale works at CREATE COLLATION time, rather than fail when
> > you try to use it. Ie. add
On 04.03.2011 21:26, Kevin Grittner wrote:
"YAMAMOTO Takashi" wrote:
a seemingly wrong math in OldSerXidAdd makes it busy writing zeros
to pg_serial.
[patch]
Your fix looks correct to me -- we want to get from a SLRU segment
number to the first page of that segment, so SLRU_PAGES_PER_SEGMEN
Heikki Linnakangas wrote:
> Hmm, if I'm reading that function correctly, it makes sure that
> when headPage < 0 (which implies that the SLRU has not been used
> since startup, right? )
No, look at the bottom of OldSerXidSetActiveSerXmin() -- cleanup of
segments is done incrementally, but when
On 04.03.2011 22:33, Kevin Grittner wrote:
Heikki Linnakangas wrote:
Hmm, if I'm reading that function correctly, it makes sure that
when headPage< 0 (which implies that the SLRU has not been used
since startup, right? )
No, look at the bottom of OldSerXidSetActiveSerXmin() -- cleanup of
se
On Fri, Mar 4, 2011 at 5:04 AM, David Schmitt wrote:
> Ehh, I deserved that. Please see the attached screenshot for a demo of the
> problem. It is really easy to reproduce and I just re-tested the current
> 8.4.7-1-windows installer from enterprisedb.com.
Hmm, interesting. I don't see garbage th
Heikki Linnakangas wrote:
> Sorry, I was not entirely clear. It clears all pages from the
> start of the segment, up to the last currently active page, even
> if the active region from tailXid to headXid only spans a couple
> of pages somewhere in the middle of the segment. It seems
> pointless
Heikki Linnakangas wrote:
> I wonder if we should move the responsibility of truncating the
> SLRU to checkpoint. At the moment, it's done in
> OldSerXidSetActiveSerXmin(), while the callers are holding
> SerializableXactHashLock in exclusive mode. While it'll probably
> go quickly in practice,
I wrote:
> I think what we're protecting against is disk I/O at COMMIT time,
> not transaction startup.
One more thought on this -- on a properly configured server, this
code should rarely be exercised unless there is a long-running READ
WRITE transaction. The delay, if any, would be on the co
22 matches
Mail list logo
