[BUGS] Missing Bug-Report #5904?
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 "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 ');
to_char
---
MäRz 2011
I did not find the translation file for this, so i can't add a patch or
check for other misspellings.
My System:
PostgreSQL 9.0.3
FreeBSD 8.1-RELEASE
Greetings from Germany,
Torsten
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5914: locking error in heap_fetch
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 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
--- a/src/backend/access/heap/heapam.c
+++ b/src/backend/access/heap/heapam.c
@@ -1472,10 +1472,10 @@ heap_fetch(Relation relation,
if (valid)
PredicateLockTuple(relation, tuple);
- LockBuffer(buffer, BUFFER_LOCK_UNLOCK);
-
CheckForSerializableConflictOut(valid, relation, tuple, buffer);
+ LockBuffer(buffer, BUFFER_LOCK_UNLOCK);
+
if (valid)
{
/*
(gdb) bt
#0 0xbbba4cc7 in _lwp_kill () from /usr/lib/libc.so.12
#1 0xbbba4c85 in raise (s=6) at /siro/nbsd/src/lib/libc/gen/raise.c:48
#2 0xbbba445a in abort () at /siro/nbsd/src/lib/libc/stdlib/abort.c:74
#3 0x083dae20 in ExceptionalCondition (
conditionName=0x8546fa4 "!(LWLockHeldByMe(bufHdr->content_lock))",
errorType=0x8546d04 "FailedAssertion", fileName=0x8546cfb "bufmgr.c",
lineNumber=2279) at assert.c:57
#4 0x082cb599 in SetBufferCommitInfoNeedsSave (buffer=633) at
bufmgr.c:2279
#5 0x0840b8e0 in SetHintBits (tuple=0x9b72efd0, buffer=633, infomask=256,
xid=154311) at tqual.c:121
#6 0x0840d614 in HeapTupleSatisfiesVacuum (tuple=0x9b72efd0,
OldestXmin=154312, buffer=633) at tqual.c:1128
#7 0x082ea867 in CheckForSerializableConflictOut (visible=1 '\001',
relation=0x99b5fcf8, tuple=0xbfbfdee4, buffer=633) at predicate.c:3402
#8 0x080a8c67 in heap_fetch (relation=0x99b5fcf8, snapshot=0x85949a0,
tuple=0xbfbfdee4, userbuf=0xbfbfdecc, keep_buf=0 '\0',
stats_relation=0x0)
at heapam.c:1477
#9 0x081d0174 in AfterTriggerExecute (event=0x99a19044, rel=0x99b5fcf8,
trigdesc=0x99a05110, finfo=0x99a05450, instr=0x99a05588,
per_tuple_context=0x99b32a50) at trigger.c:3311
#10 0x081d05f2 in afterTriggerInvokeEvents (events=0x99a01120, firing_id=1,
estate=0x99a0501c, delete_ok=1 '\001') at trigger.c:3531
#11 0x081d09df in AfterTriggerEndQuery (estate=0x99a0501c) at
trigger.c:3721
#12 0x081e8afa in standard_ExecutorFinish (queryDesc=0x99b358bc)
at execMain.c:383
#13 0x081e89db in ExecutorFinish (queryDesc=0x99b358bc) at execMain.c:351
#14 0x082f73c2 in ProcessQuery (plan=0x99ba8c4c,
sourceText=0x99b3581c "DELETE FROM file WHERE fileid = $1",
params=0x99b3587c, dest=0x858ef9c, completionTag=0xbfbfe1f0 "DELETE 1")
at pquery.c:227
#15 0x082f8837 in PortalRunMulti (portal=0x99b3d01c, isTopLevel=1 '\001',
dest=0x858ef9c, altdest=0x858ef9c, completionTag=0xbfbfe1f0 "DELETE 1")
at pquery.c:1276
#16 0x082f7ffe in PortalRun (portal=0x99b3d01c, count=2147483647,
isTopLevel=1 '\001', dest=0x99b05428, altdest=0x99b05428,
completionTag=0xbfbfe1f0 "DELETE 1") at pquery.c:813
#17 0x082f3df1 in exec_execute_message (portal_name=0x99b0501c "",
max_rows=2147483647) at postgres.c:1963
#18 0x082f6709 in PostgresMain (argc=2, argv=0xbb9126a4,
username=0xbb9125f8 "takashi") at postgres.c:3959
#19 0x082a81cb in BackendRun (port=0xbb94c0f0) at postmaster.c:3590
#20 0x082a788f in BackendStartup (port=0xbb94c0f0) at postmaster.c:3275
#21 0x082a4b0f in ServerLoop () at postmaster.c:1449
#22 0x082a42be in PostmasterMain (argc=3, argv=0xbfbfe5a8) at
postmaster.c:1110
#23 0x08225618 in main (argc=3, argv=0xbfbfe5a8) at main.c:199
(gdb)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Missing Bug-Report #5904?
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 "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 ');
to_char
---
MäRz 2011
I did not find the translation file for this, so i can't add a patch or
check for other misspellings.
My System:
PostgreSQL 9.0.3
FreeBSD 8.1-RELEASE
Greetings from Germany,
Torsten
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Missing Bug-Report #5904?
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_DE.UTF-8";
> # SELECT to_char('2011-03-04 00:00:01'::date, 'TMMonth ');
>to_char
> ---
> MäRz 2011
>
> I did not find the translation file for this, so i can't add a patch or
> check for other misspellings.
>
> My System:
> PostgreSQL 9.0.3
> FreeBSD 8.1-RELEASE
Thats very likely a problem of your operating systems locales. What spelling
does the month have if you construct it with `date` or such?
Andres
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Mismapping of Mountain Time
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 et Support -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Missing Bug-Report #5904?
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, 'TMMonth ');
to_char
---
MäRz 2011
I did not find the translation file for this, so i can't add a patch or
check for other misspellings.
My System:
PostgreSQL 9.0.3
FreeBSD 8.1-RELEASE
Thats very likely a problem of your operating systems locales. What spelling
does the month have if you construct it with `date` or such?
Done directly at the bash on the same system:
$ date +%B
March
$ export LC_TIME=de_DE.UTF-8
$ date +%B
März
And in PostgreSQL:
# SET lc_time = "de_DE.UTF-8";
SET
# SELECT to_char(current_date, 'TMMonth ');
to_char
---
MäRz 2011
I also can reproduce this at a FreeBSD 7.0-STABLE.
Greetings,
Torsten
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Missing Bug-Report #5904?
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:
>>> # SET lc_time = "de_DE.UTF-8";
>>> # SELECT to_char('2011-03-04 00:00:01'::date, 'TMMonth ');
>>> to_char
>>> ---
>>> MäRz 2011
>>>
>>> I did not find the translation file for this, so i can't add a patch or
>>> check for other misspellings.
>>>
>>> My System:
>>> PostgreSQL 9.0.3
>>> FreeBSD 8.1-RELEASE
>>
>> Thats very likely a problem of your operating systems locales. What
>> spelling does the month have if you construct it with `date` or such?
>
> Done directly at the bash on the same system:
> $ date +%B
> March
> $ export LC_TIME=de_DE.UTF-8
> $ date +%B
> März
>
> And in PostgreSQL:
> # SET lc_time = "de_DE.UTF-8";
> SET
> # SELECT to_char(current_date, 'TMMonth ');
> to_char
> ---
> MäRz 2011
>
> I also can reproduce this at a FreeBSD 7.0-STABLE.
IIRC, the FreeBSD locales at least used to be pretty much broken for
UTF8. Can you try and see if you get the same problem in a non-UTF8
locale?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Missing Bug-Report #5904?
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 ');
to_char
---
MäRz 2011
I did not find the translation file for this, so i can't add a patch or
check for other misspellings.
My System:
PostgreSQL 9.0.3
FreeBSD 8.1-RELEASE
Thats very likely a problem of your operating systems locales. What
spelling does the month have if you construct it with `date` or such?
Done directly at the bash on the same system:
$ date +%B
March
$ export LC_TIME=de_DE.UTF-8
$ date +%B
März
And in PostgreSQL:
# SET lc_time = "de_DE.UTF-8";
SET
# SELECT to_char(current_date, 'TMMonth ');
to_char
---
MäRz 2011
I also can reproduce this at a FreeBSD 7.0-STABLE.
IIRC, the FreeBSD locales at least used to be pretty much broken for
UTF8. Can you try and see if you get the same problem in a non-UTF8
locale?
Doesn't work proper at my bash, even the dirty way:
$ export LC_ALL=de_DE.ISO8859-1
$ export LC_PAPER=de_DE.ISO8859-1
$ export LC_ADDRESS=de_DE.ISO8859-1
$ export LC_MONETARY=de_DE.ISO8859-1
$ export LC_NUMERIC=de_DE.ISO8859-1
$ export LC_TELEPHONE=de_DE.ISO8859-1
$ export LC_MESSAGES=de_DE.ISO8859-1
$ export LC_IDENTIFICATION=de_DE.ISO8859-1
$ export LC_COLLATE=de_DE.ISO8859-1
$ export LANG=de_DE.ISO8859-1
$ export LC_MEASUREMENT=de_DE.ISO8859-1
$ export XTERM_LOCALE=de_DE.ISO8859-1
$ export LANGUAGE=de_DE.ISO8859-1:de
$ export LC_CTYPE=de_DE.ISO8859-1
$ export LC_TIME=de_DE.ISO8859-1
$ export LC_NAME=de_DE.ISO8859-1
$ export LC_ALL=de_DE.ISO8859-1
$ date +%B
M�z
I can't figure out, why the umlaut is not displayed correctly.
In PostgreSQL it looks interesting:
# SET lc_time = "de_DE.ISO8859-1";
SET
0.3.impos=# SELECT to_char(current_date, 'TMMonth ');
to_char
--
MRz 2011
(1 Zeile)
The missing Umlaut could be an error of the bash, but the upperase "r"
is still there.
Greetings,
Torsten
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5914: locking error in heap_fetch
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 Details: heap_fetch calls CheckForSerializableConflictOut without buffer locked. it ends up an assertion failure in SetBufferCommitInfoNeedsSave. Thanks, applied. I also added a comment to CheckForSerializableConflictOut, noting that the caller must hold a lock on the page. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Possible regression: libpq + SSL aborts when user has no home directory
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. What shall we print if we couldn't >>> identify the home directory? > Is there any case when it would actually be realistic that we don't > find the home directory, but the user can't figure out that's why it > couldn't find the file? If so, the "could not get home directory" adds > some more information... We can't exactly expect the end user to know > that this is the only codepath that can lead to the error message... Yeah, after sleeping on it I think that it'd be better to have a specialized error message for this case. It's not significantly more code, but it would represent another translatable string, and I had first thought that dodging that would be good. But it's a sufficiently odd case that making the error message as explicit as possible is probably the best thing. Will change and commit. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5914: locking error in heap_fetch
"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
> --- a/src/backend/access/heap/heapam.c
> +++ b/src/backend/access/heap/heapam.c
> @@ -1472,10 +1472,10 @@ heap_fetch(Relation relation,
> if (valid)
> PredicateLockTuple(relation, tuple);
>
> - LockBuffer(buffer, BUFFER_LOCK_UNLOCK);
> -
> CheckForSerializableConflictOut(valid, relation, tuple,
buffer);
>
> + LockBuffer(buffer, BUFFER_LOCK_UNLOCK);
> +
> if (valid)
> {
> /*
Thanks so much for all your SSI testing! And thanks for your
excellent diagnosis when you hit a problem! If you can think of any
portable tests we could add, please share.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Possible regression: libpq + SSL aborts when user has no home directory
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={disable,prefer,verify-ca}, with
> various (or no) PGSSLROOTCERTs in the case of verify-ca. In all cases,
> the result was the expected one.
Great, thanks very much for testing! I've applied the patch (with the
adjustment of error message) to HEAD and 9.0.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #5915: OldSerXidAdd inflates pg_serial too much
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 in OldSerXidAdd makes it busy writing zeros
to pg_serial.
diff --git a/src/backend/storage/lmgr/predicate.c
b/src/backend/storage/lmgr/predicate.c
index aa657fa..297508b 100644
--- a/src/backend/storage/lmgr/predicate.c
+++ b/src/backend/storage/lmgr/predicate.c
@@ -755,7 +755,7 @@ OldSerXidAdd(TransactionId xid, SerCommitSeqNo
minConflictCommitSeqNo)
{
page = OldSerXidPage(tailXid);
oldSerXidControl->tailSegment = OldSerXidSegment(page);
- page = oldSerXidControl->tailSegment * OLDSERXID_ENTRIESPERPAGE;
+ page = oldSerXidControl->tailSegment * SLRU_PAGES_PER_SEGMENT;
isNewPage = true;
}
else
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5915: OldSerXidAdd inflates pg_serial too much
"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! While I was looking at it, I noticed some obsolete comment lines which should be removed. Trivial patch attached. -Kevin *** a/src/backend/storage/lmgr/predicate.c --- b/src/backend/storage/lmgr/predicate.c *** *** 722,731 OldSerXidInit(void) * Record a committed read write serializable xid and the minimum * commitSeqNo of any transactions to which this xid had a rw-conflict out. * A zero seqNo means that there were no conflicts out from xid. - * - * The return value is normally false -- true means that we're about to - * wrap around our space for tracking these xids, so the caller might want - * to take action to prevent that. */ static void OldSerXidAdd(TransactionId xid, SerCommitSeqNo minConflictCommitSeqNo) --- 722,727 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Cannot create collation?
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 a call to pg_newlocale_from_collation() at > > the end of DefineCollation(). > > Yeah, I was apparently hoping that check_encoding_locale_matches() would > catch invalid locales, but it doesn't, so we should put in an explicit > check. Fixed. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5915: OldSerXidAdd inflates pg_serial too much
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_SEGMENT is the right multiplier. Thanks! While I was looking at it, I noticed some obsolete comment lines which should be removed. Trivial patch attached. 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? ), it zeroes out the whole SLRU file, not only the currently active region. At least pg_subtrans doesn't seem to bother with that, StartupSubTrans only zeroes the active region. 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, it still seems like there's a risk of stalling all new transactions for a few seconds while that happens. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5915: OldSerXidAdd inflates pg_serial too much
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 it finds it has cleaned up *everything* it sets headPage = -1. I believe that should only happen when the xmin has moved past the end of the segment. > it zeroes out the whole SLRU file, not only the currently active > region. That's not the intent. If it's doing that, it's accidental. It is trying to zero from the start of a segment, if a new one is needed. I'll look at this some more to see if I can spot something I'm missing, but if you see something to indicate it's not working as I describe above, please point me in the right direction. -Kevin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5915: OldSerXidAdd inflates pg_serial too much
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 segments is done incrementally, but when it finds it has cleaned up *everything* it sets headPage = -1. I believe that should only happen when the xmin has moved past the end of the segment. it zeroes out the whole SLRU file, not only the currently active region. That's not the intent. If it's doing that, it's accidental. It is trying to zero from the start of a segment, if a new one is needed. 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 to clear the pages in the beginning of the segment in that case. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5869: postgresql corrupts unquoted non-ascii chars in column aliases
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 there; I see nothing. Actually, that's what I get on MacOS X, too. For example, the following two statements produce identical output: SELECT 1 AS xx SELECT 1 AS xüx In case it comes through garbled, the second one is x-umlaut-x on my system. The umlaut isn't included in the resulting column header. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5915: OldSerXidAdd inflates pg_serial too much
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 to clear the pages in the beginning of the segment in > that case. Oh, I see now. Somehow I thought I needed to clear pages from the start of the segment to the active portion. If that's not needed, it's easy enough to adjust the calculations there to start with the first active page. Do you want me to do that? -Kevin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5915: OldSerXidAdd inflates pg_serial too much
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, it still seems like there's a risk of > stalling all new transactions for a few seconds while that > happens. I don't think it can stall new transactions unless they are DEFERRABLE, but it might stall the COMMIT of the oldest serializable transaction -- if I'm thinking it through correctly. (If not, I have another energy drink I can crack open.) Here's my thinking: The call in RegisterSerializableTransactionInt() to OldSerXidSetActiveSerXmin() only happens if there are no active serializable transactions, so it can't fall into the SLRU truncation code (I think). I'm not worried about predicatelock_twophase_recover() because it will only call the function during startup with no transactions active, so it can't hit the cleanup code. That leaves SetNewSxactGlobalXmin(), which is only called from ReleasePredicateLocks(), and only when the last transaction with the low xmin is being cleaned up. Now, that's only called around completion of a transaction except when starting a SERIALIZABLE READ ONLY DEFERRABLE transaction; and if you have explicitly requested a DEFERRABLE transaction you presumably won't be astonished by a delay in its startup. So, I'm not arguing that we shouldn't move the truncation to checkpoint time, but I think what we're protecting against is disk I/O at COMMIT time, not transaction startup. Presumably disk I/O at that point would be less surprising, although perhaps the fact that it can happen on a read only transaction might surprise someone. Of course, moving any possible delay from this to a background process seems like a good thing in general; I just don't know whether it's worth doing right now, versus adding to a list of possible enhancements. If you're confident it's safe enough, I'm game. -Kevin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #5915: OldSerXidAdd inflates pg_serial too much
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 connection which is committing that long running transaction. -Kevin -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
