Re: Potential RC1-stoppers
От | Joel Burton |
---|---|
Тема | Re: Potential RC1-stoppers |
Дата | |
Msg-id | Pine.LNX.4.21.0103222005260.8901-100000@olympus.scw.org обсуждение исходный текст |
Ответ на | Re: Potential RC1-stoppers (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Thu, 22 Mar 2001, Tom Lane wrote: > Joel Burton <jburton@scw.org> writes: > > I rebooted my machine, and it didn't happen again that night. Yesterday, > > my staff reinstalled Pg straight from the CVS but without (!) tarring up > > the old Pg install, so I'm afraid I don't have any logs. I run Pg w/debug > > switches on my development machine; this machine did not have such. > > Drat. > > > I don't have a log, but do have the query that was issued, multiple times, > > overlapping: > > SELECT * FROM zope_facinst LIMIT 1000; > > It's really unlikely (I hope) that the clients running SELECTs had > anything to do with it. You had mentioned that you were busy making > manual schema revisions while this went on; that process seems more > likely to be the guilty party. But if you don't have the logs anymore, > I suppose there's not much chance of reconstructing what you did :-( The dropping and re-making were the zope_facinst view listed in my email. I was tinkering with various parameters, trying to see if distinct on (list) was faster than distinct list, etc. > I spent much of this afternoon groveling through the deletion-related > code, looking for some code path that could lead to a deletion operation > deleting the wrong file. I didn't find anything that looked plausible > enough to be worth pursuing. So I'm stumped for the moment. We'll have > to hope that if it happens again, we can gather more data. It could be my machine; it's not a heavily used machine, so I can't vouch for its stability. Sorry I couldn't help more. As always, thanks. -- Joel Burton <jburton@scw.org> Director of Information Systems, Support Center of Washington
В списке pgsql-hackers по дате отправления: