Re: [BUGS] BUG #4339: The postgreSQL service stops abnormally
Hi, Bhaskar Sirohi wrote: > ... 2008-07-30 15:05:01 EDT LOG: checkpoints are occurring too frequently (28 seconds apart) 2008-07-30 15:05:01 EDT HINT: Consider increasing the configuration parameter "checkpoint_segments". 2008-07-30 15:13:34 EDT LOG: checkpoints are occurring too frequently (29 seconds apart) 2008-07-30 15:13:34 EDT HINT: Consider increasing the configuration parameter "checkpoint_segments". 2008-07-30 15:18:50 EDT LOG: checkpoints are occurring too frequently (28 seconds apart) 2008-07-30 15:18:50 EDT HINT: Consider increasing the configuration parameter "checkpoint_segments". 2008-07-30 15:19:21 EDT LOG: received fast shutdown request These log lines look like your database is touching lots of tuples, requiring it to checkpoint frequently. Then it receives a fast shutdown request - from whoever. What causes the workload? Did you check memory usage? (And uh.. does Windows 2003 Server have an OOM Killer or some such?) Regards Markus Wanner -- 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 #4186: set lc_messages does not work
Bruce Momjian wrote: > Tom Lane wrote: >> Magnus Hagander <[EMAIL PROTECTED]> writes: >>> Thomas H. wrote: so at least that explains the "changed" behaviour. nevertheless, LC_MESSAGES seems to be defunct - with the "locale" folder present, pg always picks the os' language and ignores the lc_message value. >>> This looks like I can reproduce though, at least on cvs head. Did this >>> work for you in previous versions? >> Maybe we were using a different build of gettext in the previous >> releases, one that didn't look at the same info as the current code? >> >> Anyway the patch mentioned at the start of the thread >> http://archives.postgresql.org/pgsql-patches/2008-02/msg00038.php >> purports to fix this. It doesn't seem to have gotten reviewed >> though. > > Agreed. Magnus, someone, can we get feedback on the patch at this URL? > > http://archives.postgresql.org/pgsql-patches/2008-02/msg00038.php IIRC, there was further work to be done on the patch before it was to be applied, and we held off the review until then. Gevik - can you comment on this? Where are we, what needs ot be done still? //Magnus -- 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 #4186: set lc_messages does not work
Hi Magnus. I have tried with Inoue-san, investigation of this problem, and adjustment. http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/pg8.3.3-to_char_gettext_format.png Native-strftime was proposed by Tom-san. It corrects(LC_TIME) from 8.3.3.(LC_MESSAGES) http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/ http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/pg_locale_patch It has not resulted in the still final conclusion. However, Possibly this may be the optimal one. http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/wcsftimeck.c I am creating the proposal of patch with Inoue-san. Regards, Hiroshi Saito - Original Message - From: "Magnus Hagander" <[EMAIL PROTECTED]> Bruce Momjian wrote: Tom Lane wrote: Magnus Hagander <[EMAIL PROTECTED]> writes: Thomas H. wrote: so at least that explains the "changed" behaviour. nevertheless, LC_MESSAGES seems to be defunct - with the "locale" folder present, pg always picks the os' language and ignores the lc_message value. This looks like I can reproduce though, at least on cvs head. Did this work for you in previous versions? Maybe we were using a different build of gettext in the previous releases, one that didn't look at the same info as the current code? Anyway the patch mentioned at the start of the thread http://archives.postgresql.org/pgsql-patches/2008-02/msg00038.php purports to fix this. It doesn't seem to have gotten reviewed though. Agreed. Magnus, someone, can we get feedback on the patch at this URL? http://archives.postgresql.org/pgsql-patches/2008-02/msg00038.php IIRC, there was further work to be done on the patch before it was to be applied, and we held off the review until then. Gevik - can you comment on this? Where are we, what needs ot be done still? //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Hmm, nodeUnique doesn't really support backwards scan too well
In the regression database: regression=# select distinct on (ten) ten, thousand from tenk1 order by ten, thousand; ten | thousand -+-- 0 |0 1 |1 2 |2 3 |3 4 |4 5 |5 6 |6 7 |7 8 |8 9 |9 (10 rows) This is correct, but watch this: regression=# begin; BEGIN regression=# declare c cursor for regression-# select distinct on (ten) ten, thousand from tenk1 order by ten, thousand; DECLARE CURSOR regression=# fetch forward all in c; ten | thousand -+-- 0 |0 1 |1 2 |2 3 |3 4 |4 5 |5 6 |6 7 |7 8 |8 9 |9 (10 rows) regression=# fetch backward all in c; ten | thousand -+-- 9 | 999 8 | 998 7 | 997 6 | 996 5 | 995 4 | 994 3 | 993 2 | 992 1 | 991 0 | 990 (10 rows) This happens in all supported releases (and even further back; it's broken in 7.1 which is the oldest release I have running at the moment). The reason is that nodeUnique claims to support backwards scan, but what it actually delivers during backwards scanning is the last tuple (the first-encountered one) from each group, not the first tuple (the last-encountered one) as would be needed to maintain consistency with the forward scan direction. We could probably fix this by complicating the logic in ExecUnique, but I wonder whether it wouldn't be better to just stop treating Unique nodes as backwards-scannable. The only reason for that node type to exist (as opposed to using Group nodes) is that it's simple and low-overhead. So complicating it to support a corner case that no one has noticed in many years might be counterproductive. Thoughts? 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] Hmm, nodeUnique doesn't really support backwards scan too well
On Tue, 2008-08-05 at 13:07 -0400, Tom Lane wrote: > We could probably fix this by complicating the logic in ExecUnique, > but I wonder whether it wouldn't be better to just stop treating > Unique nodes as backwards-scannable. No problem there. > The only reason for that > node type to exist (as opposed to using Group nodes) is that it's > simple and low-overhead. So complicating it to support a corner case > that no one has noticed in many years might be counterproductive. > Thoughts? I've never seen anyone scan backwards like this at all in practical use. I knew it was possible, but never seen it done. It seems entirely probable nobody else has either. It's a PostgreSQL extension, so people arriving from outside don't even know it exists, plus its always had bugs so those in-the-know don't use it either: http://archives.postgresql.org/pgsql-bugs/1998-06/msg00049.php My perceptions may not match others... -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and 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] Hmm, nodeUnique doesn't really support backwards scan too well
Simon Riggs <[EMAIL PROTECTED]> writes: > I've never seen anyone scan backwards like this at all in practical use. > I knew it was possible, but never seen it done. > It seems entirely probable nobody else has either. It's a PostgreSQL > extension, so people arriving from outside don't even know it exists, Say again? Both the SCROLL option to DECLARE CURSOR and FETCH PRIOR are straight out of the SQL92 spec. 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] Hmm, nodeUnique doesn't really support backwards scan too well
On 8/5/08, Tom Lane <[EMAIL PROTECTED]> wrote: > Simon Riggs <[EMAIL PROTECTED]> writes: > > I've never seen anyone scan backwards like this at all in practical use. > > > I knew it was possible, but never seen it done. > > > It seems entirely probable nobody else has either. It's a PostgreSQL > > extension, so people arriving from outside don't even know it exists, > > Say again? Both the SCROLL option to DECLARE CURSOR and FETCH PRIOR are > straight out of the SQL92 spec. > i think Simon is talking about DISTINCT ON -- regards, Jaime Casanova Soporte y capacitación de PostgreSQL Guayaquil - Ecuador Cel. (593) 87171157 -- 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] Hmm, nodeUnique doesn't really support backwards scan too well
On Tue, 2008-08-05 at 18:00 -0500, Jaime Casanova wrote: > On 8/5/08, Tom Lane <[EMAIL PROTECTED]> wrote: > > Simon Riggs <[EMAIL PROTECTED]> writes: > > > I've never seen anyone scan backwards like this at all in practical use. > > > > > I knew it was possible, but never seen it done. > > > > > It seems entirely probable nobody else has either. It's a PostgreSQL > > > extension, so people arriving from outside don't even know it exists, > > > > Say again? Both the SCROLL option to DECLARE CURSOR and FETCH PRIOR are > > straight out of the SQL92 spec. Yep. I was talking about FETCH BACKWARDS n | ALL though forgot that this is the same thing as FETCH PRIOR. But even use of FETCH PRIOR is fairly rare, so IMHO your proposal is still safe. > i think Simon is talking about DISTINCT ON No, don't confuse things! That is rare also, but I know of various places that is used. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
