-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Alvaro
Sent: 17 April 2006 21:58
To: pgsql-bugs@postgresql.org
Subject: [BUGS] BUG #2399: Postgis DLL corrupted
The following bug has been logged online:
Bug reference: 2399
Logged by:
Hi all,
In the last couple of days, we've been bitten (a couple of
times, on different servers) by an apparent glitch or bad
interaction in the Windows implementation of rename().
The relevant log message is:
[2006-04-17 16:49:22.583 ] 2252 LOG: could not rename file
I have now realized another complexity. It is only _syntax_ errors that
are not logged via log_statement, not queries that generate other errors
during execution. I have updated the documentation to mention syntax
error, but it does make log_min_error_statement sub-optimal because if
Unfortunately, it's not that simple. It would be straightforward to
track down if it were.
In response to other questions:
It's Postgres 8.1.3 running on Windows 2003 Server. No anti-virus
software is installed. The servers are essentially bare except for the
OS and Postgres.
We have handle
Peter, G:\pgsql\data\pg_xlog\0001010A00BDpropably a very stupid question: G - is that really a LOKAL drive at that server, or rather some NAS or similiar? I had the same error in one logfile one time, but there where a large amount of possible culprits (viral scanner, login script
Peter Brant [EMAIL PROTECTED] writes:
LOG: could not rename file pg_xlog/0001010A00BD to
pg_xlog/0001010A00D7, continuing to try
...
Only one process (postgres.exe) is holding a handle to
pg_xlog/0001010A00BD:
...
The second is similar, except that two
Magnus Hagander [EMAIL PROTECTED] writes:
Looking at our code, we have the comment:
/* These flags allow concurrent rename/unlink */
(FILE_SHARE_READ |
FILE_SHARE_WRITE | FILE_SHARE_DELETE),
But I'm not sure that those flags actually guarantee
Ed L. [EMAIL PROTECTED] writes:
FATAL: pre-existing shared memory block (key 9812001, ID 655374)
is still in use
However, ipcs shows there is no shared memory block in use:
What platform is that?
Perhaps you need some non-default switches to ipcs to see all memory
segments? Otherwise, it
They are local.
Pete
Harald Armin Massa [EMAIL PROTECTED] 04/18/06 4:35 pm
G - is that really a LOKAL drive at that server, or rather some NAS
or similiar?
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your
It's definitely possible. Both failures occurred around the end of the
business day as update traffic would have been coasting to a stop. The
middle tier never closes a connection unless it's forced to (e.g. as a
result of a query error, connection going away, etc.)
Pete
Tom Lane [EMAIL
Peter Brant [EMAIL PROTECTED] writes:
The error messages refer to the old relfilenode (in 3 out of 3
occurrences today).
So it'd seem the problem is with fsync on recently-deleted files.
Is it possible that we are getting EACCES (ERROR_SHARING_VIOLATION
maybe) in the situation where we try to
Peter Brant [EMAIL PROTECTED] writes:
[2006-04-17 16:49:22.583 ] 2252 LOG: could not rename file
pg_xlog/0001010A00BD to
pg_xlog/0001010A00D7, continuing to try
It apparently just keeps on looping indefinitely. The completed
rename message from port/dirmod.c never
The error messages refer to the old relfilenode (in 3 out of 3
occurrences today).
So it'd seem the problem is with fsync on recently-deleted files.
Is it possible that we are getting EACCES (ERROR_SHARING_VIOLATION
maybe) in the situation where we try to fsync a file that's
been
Magnus Hagander [EMAIL PROTECTED] writes:
Is it possible that we are getting EACCES (ERROR_SHARING_VIOLATION
maybe) in the situation where we try to fsync a file that's
been unlinked but isn't fully gone yet due to open handles?
I think that sounds reasonable. Not as in a reasonable thing to
I wrote:
Peter Brant [EMAIL PROTECTED] writes:
Shortly thereafter, Postgres becomes unresponsive. Attempts to make a
new connection just block. Autovacuums block. A pg_ctl ... stop -m
fast doesn't work. Only pg_ctl ... stop -m immediate does.
BTW, whatever we decide to do about the
Does that also explain why an attempt to make a new connection just
hangs?
One other thing regarding that is that connection attempt seems to
kinda, sorta succeed. It never makes it as far as a command prompt, but
on the stop -m immediate, psql does print the HINT: In a moment you
should be
Peter Brant [EMAIL PROTECTED] writes:
Does that also explain why an attempt to make a new connection just
hangs?
Actually, I was just wondering about that --- seems like a bare
connection attempt should not generate any WAL entries. Do you have any
nondefault actions in ~/.psqlrc or something
Is it possible that we are getting EACCES (ERROR_SHARING_VIOLATION
maybe) in the situation where we try to fsync a file that's been
unlinked but isn't fully gone yet due to open handles?
I think that sounds reasonable. Not as in a reasonable
thing to do,
but as a reasonable thing
It happens often enough and the episodes last long enough that grabbing
a handle dump while this is going on should be easily done.
Regarding the Win32 error code, backend/storage/file/fd.c calls
_commit().
http://msdn2.microsoft.com/en-us/library/17618685(VS.80).aspx It looks
like it is
Magnus Hagander [EMAIL PROTECTED] writes:
Because we are talking about checking the output from _commit(), right?
(being fsync() redefined)
The failure could be coming from that, or from a preceding open() if the
bgwriter didn't already have the file open --- basically, the message
Peter is
It happens often enough and the episodes last long enough
that grabbing a handle dump while this is going on should be
easily done.
Regarding the Win32 error code, backend/storage/file/fd.c
calls _commit().
http://msdn2.microsoft.com/en-us/library/17618685(VS.80).aspx
It looks
I wrote:
Peter Brant [EMAIL PROTECTED] writes:
Does that also explain why an attempt to make a new connection just
hangs?
Actually, I was just wondering about that --- seems like a bare
connection attempt should not generate any WAL entries. Do you have any
nondefault actions in ~/.psqlrc
Tom Lane wrote:
julien [EMAIL PROTECTED] writes:
The INSTALL file mention the command kill `cat
/usr/local/pgsql/data/postmaster.pid` but the pid file contain the pid
but not only, it also contain data directory and some numbers (memory
usage ?, database characteristic ?)
Hm, I
Is anyone working on this?
---
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
On Sat, Apr 08, 2006 at 12:27:19PM -0400, Tom Lane wrote:
Hmm, it seems to depend on the hardware you're using. I just tried
24 matches
Mail list logo
