Re: [HACKERS] seahorse again failing
"Magnus Hagander" <[EMAIL PROTECTED]> writes: >> Could someone with access to Windows code and test this? > Do you mean something as simple as this? > compiles, passes regression tests, logs this on startup of a fresh > cluster: > LOG: win32 open error on 'global/pgstat.stat': 2 Looks good --- I tweaked it to log all the info AllocateFile has access to, just in case it helps. Now we wait to capture a failure. Stefan, do you want to set that box to doing continuous regression tests? Or anyone else with a Windows machine that's not doing much? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] seahorse again failing
> > Tom Lane wrote: > >> It would be interesting to know the actual underlying Windows > error > >> code > >> --- I see that win32error.c maps several different codes to > EACCES. > > > It may be a good idea to put a elog(LOG) with the error code in > the > > failure path of AllocateFile. > > That seems like a plan to me. I had been thinking of making > win32error.c itself log the conversions, but that would not provide > any context information. AllocateFile could log the file name > along with the code, which should be enough info to associate a > particular log entry with the actual failure. > > Note you should probably save and restore errno around the elog > call, just to be safe. > > Could someone with access to Windows code and test this? Do you mean something as simple as this? compiles, passes regression tests, logs this on startup of a fresh cluster: LOG: win32 open error on 'global/pgstat.stat': 2 (very simple - it's a file-not-found, which is expected..) //Magnus allocatefile.patch Description: allocatefile.patch ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] seahorse again failing
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Magnus Hagander > Sent: 23 August 2006 09:25 > To: Andrew Dunstan; Tom Lane > Cc: Alvaro Herrera; Stefan Kaltenbrunner; PostgreSQL-development > Subject: Re: [HACKERS] seahorse again failing > > Definitly. If nothing else, it should at least be listed in > the platform > identificagtion. AFAIK, Snake is also a VM, and Daves other box as > well... But on VMWare (or was it Virtual Server?) and not Xen, but > still. No, Snake is real. Bandicoot is a VMWare Server VM running on Snake though. /D ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] seahorse again failing
> >> It may be a good idea to put a elog(LOG) with the error code in > the > >> failure path of AllocateFile. > >> > > > > That seems like a plan to me. I had been thinking of making > > win32error.c itself log the conversions, but that would not > provide > > any context information. AllocateFile could log the file name > along > > with the code, which should be enough info to associate a > particular > > log entry with the actual failure. > > > > Note you should probably save and restore errno around the elog > call, > > just to be safe. > > > > Could someone with access to Windows code and test this? > > > > > > All this seems good and sensible. > > I am just a little suspicious of seahorse, though, as it is running > on a Xen VM. > > I wonder if we should add a VM column to the buildfarm machine > specs. Definitly. If nothing else, it should at least be listed in the platform identificagtion. AFAIK, Snake is also a VM, and Daves other box as well... But on VMWare (or was it Virtual Server?) and not Xen, but still. //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] seahorse again failing
Martijn van Oosterhout writes: > Would it be possible to get errcode_for_file_access() to report the > results of GetLastError() for windows, or would that roduce spurious > results. At DEBUG lavel maybe? It would have to be at LOG level, because otherwise it wouldn't get logged at all with the default settings that the buildfarm is using. Also, I think that errcode_for_file_access() may run too late, ie, we couldn't be sure that we were looking at the same value of GetLastError. This could be dealt with by saving GetLastError into the error data structure at the same place we save errno, but that's starting to get a bit invasive for a temporary-investigation kluge. BTW, whoever writes this needs to check that it doesn't change the default regression test results ... regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] seahorse again failing
On Tue, Aug 22, 2006 at 10:19:38AM -0400, Tom Lane wrote: > > It may be a good idea to put a elog(LOG) with the error code in the > > failure path of AllocateFile. > > That seems like a plan to me. I had been thinking of making > win32error.c itself log the conversions, but that would not provide any > context information. AllocateFile could log the file name along with > the code, which should be enough info to associate a particular log > entry with the actual failure. Would it be possible to get errcode_for_file_access() to report the results of GetLastError() for windows, or would that roduce spurious results. At DEBUG lavel maybe? Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate. signature.asc Description: Digital signature
Re: [HACKERS] seahorse again failing
Andrew Dunstan wrote: > Tom Lane wrote: >> Alvaro Herrera <[EMAIL PROTECTED]> writes: >> >>> Tom Lane wrote: >>> It would be interesting to know the actual underlying Windows error code --- I see that win32error.c maps several different codes to EACCES. >> >> >>> It may be a good idea to put a elog(LOG) with the error code in the >>> failure path of AllocateFile. >>> >> >> That seems like a plan to me. I had been thinking of making >> win32error.c itself log the conversions, but that would not provide any >> context information. AllocateFile could log the file name along with >> the code, which should be enough info to associate a particular log >> entry with the actual failure. >> >> Note you should probably save and restore errno around the elog call, >> just to be safe. >> >> Could someone with access to Windows code and test this? >> >> > > All this seems good and sensible. > > I am just a little suspicious of seahorse, though, as it is running on a > Xen VM. indeed seahorse is running under Xen - though i have no reason to believe that xen is at fault - the eventlog shows absolutly no sign of any troubles nor does the hypervisor. The only thing I would think about is that the VM might cause some subtile timing differences wrt disk-access or scheduling (xen is not exceptionally bright about cpu scheduling - so it might starve some guests sometimes). Other than that I do seem to recall that we got a number of weird looking "permission denied" errors on win32 - improving the error reporting might help to find out if there is a pattern involved somewhere. > > I wonder if we should add a VM column to the buildfarm machine specs. that would be fine with me - maybe we could add a "LDAP" symbol too since we just had some body failing after the ldap-on-windows fix ? Stefan ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] seahorse again failing
Tom Lane wrote: Alvaro Herrera <[EMAIL PROTECTED]> writes: Tom Lane wrote: It would be interesting to know the actual underlying Windows error code --- I see that win32error.c maps several different codes to EACCES. It may be a good idea to put a elog(LOG) with the error code in the failure path of AllocateFile. That seems like a plan to me. I had been thinking of making win32error.c itself log the conversions, but that would not provide any context information. AllocateFile could log the file name along with the code, which should be enough info to associate a particular log entry with the actual failure. Note you should probably save and restore errno around the elog call, just to be safe. Could someone with access to Windows code and test this? All this seems good and sensible. I am just a little suspicious of seahorse, though, as it is running on a Xen VM. I wonder if we should add a VM column to the buildfarm machine specs. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] seahorse again failing
Alvaro Herrera <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> It would be interesting to know the actual underlying Windows error code >> --- I see that win32error.c maps several different codes to EACCES. > It may be a good idea to put a elog(LOG) with the error code in the > failure path of AllocateFile. That seems like a plan to me. I had been thinking of making win32error.c itself log the conversions, but that would not provide any context information. AllocateFile could log the file name along with the code, which should be enough info to associate a particular log entry with the actual failure. Note you should probably save and restore errno around the elog call, just to be safe. Could someone with access to Windows code and test this? regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] seahorse again failing
Tom Lane wrote: > Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: >> seahorse just failed again with one of the dreaded "permission denied" >> errors we seem to sporadically getting reported on the lists: >> seahorse is just a stock windows XP box (with all patches and >> servicepacks applied) and msys/mingw. >> There is no other software installed or ever was - maybe there is really >> an underlying issue that is causing those sporadic "permission denied" >> errors ? > > How repeatable is it? this seems two be the second time seahorse managed to trigger that (first was a manual build a while ago) - so unfortunably not very repeatable :-( > > It would be interesting to know the actual underlying Windows error code > --- I see that win32error.c maps several different codes to EACCES. yeah - is there a way to log the actual windows error code too ? Stefan ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] seahorse again failing
Tom Lane wrote: > Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: > > seahorse just failed again with one of the dreaded "permission denied" > > errors we seem to sporadically getting reported on the lists: > > seahorse is just a stock windows XP box (with all patches and > > servicepacks applied) and msys/mingw. > > There is no other software installed or ever was - maybe there is really > > an underlying issue that is causing those sporadic "permission denied" > > errors ? > > How repeatable is it? > > It would be interesting to know the actual underlying Windows error code > --- I see that win32error.c maps several different codes to EACCES. It may be a good idea to put a elog(LOG) with the error code in the failure path of AllocateFile. This particular problem must be coming from FindMyDatabase (or maybe RebuildFlatFiles when called from PostgresMain?) -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] seahorse again failing
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: > seahorse just failed again with one of the dreaded "permission denied" > errors we seem to sporadically getting reported on the lists: > seahorse is just a stock windows XP box (with all patches and > servicepacks applied) and msys/mingw. > There is no other software installed or ever was - maybe there is really > an underlying issue that is causing those sporadic "permission denied" > errors ? How repeatable is it? It would be interesting to know the actual underlying Windows error code --- I see that win32error.c maps several different codes to EACCES. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] seahorse again failing
seahorse just failed again with one of the dreaded "permission denied" errors we seem to sporadically getting reported on the lists: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=seahorse&dt=2006-08-22%2002:30:01 we seem to attribute those to AV and other security related software - except that seahorse does not have (and never had) anything like that installed. seahorse is just a stock windows XP box (with all patches and servicepacks applied) and msys/mingw. There is no other software installed or ever was - maybe there is really an underlying issue that is causing those sporadic "permission denied" errors ? Stefan ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
