Обсуждение: Email search failure
Why is the email below now appearing in a search? http://search.postgresql.org/search?q=As+you+yourself+said%2C+this+patch+mostly+gets+the+machinery+to+count&m=1&l=&d=365&s=d --------------------------------------------------------------------------- ----- Forwarded message from Pavan Deolasee ----- On Tue, Jul 1, 2008 at 4:13 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > > > The first "half" is actually quite large, but that makes it even more > sensible to commit this part now. > > The enclosed patch introduces the machinery by which we might later > optimise hint bit setting. It differentiates between hint bit setting > and block dirtying, when the distinction can safely be made. It acts > safely during VACUUM and correctly during checkpoint. In all other > respects it emulates current behaviour. > As you yourself said, this patch mostly gets the machinery to count hint bits in place and leaves the actual optimization for future. But I think we should try at least one or two possible optimizations and get some numbers before we jump and make substantial changes to the code. Also that would help us in testing the patch for correctness and performance. For example, the following hunk seems buggy to me: Index: src/backend/storage/buffer/bufmgr.c =================================================================== RCS file: /home/sriggs/pg/REPOSITORY/pgsql/src/backend/storage/buffer/bufmgr.c,v retrieving revision 1.232 diff -c -r1.232 bufmgr.c *** src/backend/storage/buffer/bufmgr.c 12 Jun 2008 09:12:31 -0000 1.232 --- src/backend/storage/buffer/bufmgr.c 30 Jun 2008 22:17:20 -0000 *************** *** 1460,1473 **** if (bufHdr->refcount == 0 && bufHdr->usage_count == 0) result |= BUF_REUSABLE; ! else if (skip_recently_used) { /* Caller told us not to write recently-used buffers */ UnlockBufHdr(bufHdr); return result; } ! if (!(bufHdr->flags & BM_VALID) || !(bufHdr->flags & BM_DIRTY)) { /* It's clean, so nothing to do */ UnlockBufHdr(bufHdr); --- 1462,1477 ---- if (bufHdr->refcount == 0 && bufHdr->usage_count == 0) result |= BUF_REUSABLE; ! else if (LRU_scan) { /* Caller told us not to write recently-used buffers */ UnlockBufHdr(bufHdr); return result; } ! if (!(bufHdr->flags & BM_VALID) || ! !(bufHdr->flags & BM_DIRTY || ! (LRU_scan && bufHdr->hint_count > 0))) { /* It's clean, so nothing to do */ UnlockBufHdr(bufHdr); In the "if" condition above, we would throw away a buffer if the hint_count is greater than zero, even if the buffer is dirty. This doesn't seem correct to me, unless I am missing something obvious. > The actual tuning patch can be discussed later, probably at length. > Later patches will be fairly small in comparison and so various people > can fairly easily come up with their own favoured modifications for > testing. > > I would suggest, let's have at least one tuning patch along with some tests and numbers, before we go ahead and commit anything. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches ----- End of forwarded message from Pavan Deolasee ----- -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: > > Why is the email below now appearing in a search? Can we please see the email headers? From, To, Date, Message-Id, Cc. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Bruce Momjian wrote: > > Why is the email below now appearing in a search? > > http://search.postgresql.org/search?q=As+you+yourself+said%2C+this+patch+mostly+gets+the+machinery+to+count&m=1&l=&d=365&s=d FWIW, this patch is in the archives: http://archives.postgresql.org/message-id/2e78013d0807202306t21ff41a9q53673dc9a48bf859@mail.gmail.com and it's referenced on the commitfest page. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera wrote: > Bruce Momjian wrote: > > > > Why is the email below now appearing in a search? > > > > http://search.postgresql.org/search?q=As+you+yourself+said%2C+this+patch+mostly+gets+the+machinery+to+count&m=1&l=&d=365&s=d > > FWIW, this patch is in the archives: > > http://archives.postgresql.org/message-id/2e78013d0807202306t21ff41a9q53673dc9a48bf859@mail.gmail.com > > and it's referenced on the commitfest page. Yep, here it is in the archives: http://archives.postgresql.org/pgsql-patches/2008-07/msg00199.php but it does not show up in a search: http://search.postgresql.org/search?q=Hint+Bits+and+Write+&m=1&l=&d=365&s=d -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes:
> Why is the email below now appearing in a search?
Probably because nothing has gotten indexed for a month or more.
Whoever is supposed to maintain the archive indexer has been
on vacation since it broke ...
regards, tom lane
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: >> Why is the email below now appearing in a search? > > Probably because nothing has gotten indexed for a month or more. > Whoever is supposed to maintain the archive indexer has been > on vacation since it broke ... That would be Magnus and you are correct. He just got back. The problem (last I checked) is an issue with Russian emails. Sincerely, Joshua D. Drake > > regards, tom lane >
Joshua D. Drake wrote: > Tom Lane wrote: >> Bruce Momjian <bruce@momjian.us> writes: >>> Why is the email below now appearing in a search? >> >> Probably because nothing has gotten indexed for a month or more. >> Whoever is supposed to maintain the archive indexer has been >> on vacation since it broke ... > > That would be Magnus and you are correct. He just got back. The problem > (last I checked) is an issue with Russian emails. Looking at it now. That clearly wasn't the only problem, because there was a "sleep 1800" process that had been running since July 3. Logfiles weren't touched etc. Just restarting it fixed that part, which clearly somebody else could've done as well ;) I found the bug with the Russian emails, btw. It seems mhonarc encoded the invalid UTF8 sequences inside valid HTML escape entities And the code applied the "fix broken UTF8" logic *before* it unescaped the HTML entities. Now it does it both before and after.. Oh, and this should never have affected messages on -hackers for example, because it was always processed before ru-general. It would hit the PUG lists, -www, -patches and a few others. //Magnus
Any idea why there were no alerts? Ae we monitoring pgsql-aardvarks instead of pgsql-zebras? On 8/1/08, Magnus Hagander <magnus@hagander.net> wrote: > Joshua D. Drake wrote: >> Tom Lane wrote: >>> Bruce Momjian <bruce@momjian.us> writes: >>>> Why is the email below now appearing in a search? >>> >>> Probably because nothing has gotten indexed for a month or more. >>> Whoever is supposed to maintain the archive indexer has been >>> on vacation since it broke ... >> >> That would be Magnus and you are correct. He just got back. The problem >> (last I checked) is an issue with Russian emails. > > Looking at it now. That clearly wasn't the only problem, because there > was a "sleep 1800" process that had been running since July 3. Logfiles > weren't touched etc. Just restarting it fixed that part, which clearly > somebody else could've done as well ;) > > I found the bug with the Russian emails, btw. It seems mhonarc encoded > the invalid UTF8 sequences inside valid HTML escape entities And the > code applied the "fix broken UTF8" logic *before* it unescaped the HTML > entities. Now it does it both before and after.. > > Oh, and this should never have affected messages on -hackers for > example, because it was always processed before ru-general. It would hit > the PUG lists, -www, -patches and a few others. > > //Magnus > > -- > Sent via pgsql-www mailing list (pgsql-www@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-www > -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Stefan acknowledged the alert on 2008-07-04 07:36:15 (per nagios history), which makes it stop complaining (with the comment that I should be looking at it - doesn't have any effect if I don't actually have time to do that before I go on vacation). It still showed up under services that were down if you went to the nagios website. //Magnus dpage@pgadmin.org wrote: > Any idea why there were no alerts? Ae we monitoring pgsql-aardvarks > instead of pgsql-zebras? > > On 8/1/08, Magnus Hagander <magnus@hagander.net> wrote: >> Joshua D. Drake wrote: >>> Tom Lane wrote: >>>> Bruce Momjian <bruce@momjian.us> writes: >>>>> Why is the email below now appearing in a search? >>>> Probably because nothing has gotten indexed for a month or more. >>>> Whoever is supposed to maintain the archive indexer has been >>>> on vacation since it broke ... >>> That would be Magnus and you are correct. He just got back. The problem >>> (last I checked) is an issue with Russian emails. >> Looking at it now. That clearly wasn't the only problem, because there >> was a "sleep 1800" process that had been running since July 3. Logfiles >> weren't touched etc. Just restarting it fixed that part, which clearly >> somebody else could've done as well ;) >> >> I found the bug with the Russian emails, btw. It seems mhonarc encoded >> the invalid UTF8 sequences inside valid HTML escape entities And the >> code applied the "fix broken UTF8" logic *before* it unescaped the HTML >> entities. Now it does it both before and after.. >> >> Oh, and this should never have affected messages on -hackers for >> example, because it was always processed before ru-general. It would hit >> the PUG lists, -www, -patches and a few others. >> >> //Magnus >> >> -- >> Sent via pgsql-www mailing list (pgsql-www@postgresql.org) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-www >> > >