Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > Tom Lane wrote: >> I'm very concerned about that too, and think that DEBUG5 is just fine. > Well, the analysis was already done which says this shouldn't be a problem. That analysis is full of holes --- FileRead and FileWrite for starters. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly

Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > Tom Lane wrote: >> That analysis is full of holes --- FileRead and FileWrite for starters. > I already did. The case where they retry do not call _dosmaperr. What's retry got to do with it? What's displeasing me is the idea of LOG messages showing up during perfectly normal operation. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend

Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > I think a reasonable compromise is to turn the ereport() in _dosmaperr > to DEBUG1 instead. That way it won't clutter any log by default, and in > the cases where we're actually interested in tracking the problematic > situation, we don't need to get huge amounts of log traffic coming from > other parts of the system. I'm still not convinced what you think the problematic situation is. It's already the case (and reasonable, I think) that _dosmaperr issues a LOG message if it sees a GetLastError code it doesn't recognize; that addresses the problem that this thread started with. Why do we need to make the success case chattier? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster

Magnus Hagander <magnus@hagander.net> writes: > Tom Lane wrote: >> I'm still not convinced what you think the problematic situation is. > I believe Alvaros point is that several different GetLastError codes map > to the same errno code, making it impossible to see the difference > between those errors. (1) If we need to know the difference, then we shouldn't be mapping them to the same thing. (2) Do we have any live cases where we must know this? Much less enough cases to justify a global increase in the log chattiness? It's not like we cannot get the information if we really need it. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org

Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > Tom Lane wrote: >> (2) Do we have any live cases where we must know this? > Yes. This thread shows the problem: > http://archives.postgresql.org/pgsql-es-ayuda/2007-11/msg00354.php > Basically he is getting this error: > 2007-11-16 14:54:16 ERROR: could not open relation 1663/16403/16487: Invalid argument Well, since EINVAL is the default result from _dosmaperr, and none of the cases it represents are "expected", why don't we just remove all of the explicit mappings to EINVAL from doserrors[]? Then we will get the LOG message you need, and we won't have to increase the chattiness level for anything else. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster

Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > Tom Lane wrote: >> Well, since EINVAL is the default result from _dosmaperr, and none of >> the cases it represents are "expected", why don't we just remove all of >> the explicit mappings to EINVAL from doserrors[]? > Well, the problematic routine is not already using _dosmaperr currently. > It is doing it's own mapping and neglecting to report anything. Oh, well then why are we arguing? There is no reason at all to assume that _dosmaperr wouldn't give us a sufficiently good fix on the error if it were only being used. At the very least, I think we should put in Magnus' patch and find out whether it gives sufficient information. If it doesn't, then we can think about changing to a higher log level. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

Gregory Stark <stark@enterprisedb.com> writes: > "Andrew Dunstan" <andrew@dunslane.net> writes: >> Interesting. Maybe forever is going a bit too far, but retrying for <n> >> seconds or so. > I think looping forever is the right thing. Having a fixed timeout just means > Postgres will break sometimes instead of all the time. And it introduces > non-deterministic behaviour too. Looping forever would be considered broken by a very large fraction of the community. IIRC we have a 30-second timeout in rename() for Windows, and that seems to be working well enough, so I'd be inclined to copy the behavior for this case. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org