> -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
>
> 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
> "pg_
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
log_min_e
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 ch
Ok. So we're obviously blocking ourselves out.
Which process was the stalled one? Was it the same one that held the
file open, or a different one?
Looking at our code, we have the comment:
/* These flags allow concurrent rename/unlink */
(FILE_SHAR
"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, exc
"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 guaran
Not sure this is a bug, but I'm seeing the following message:
pg_ctl: another postmaster may be running; trying to start
postmaster anyway
FATAL: pre-existing shared memory block (key 9812001, ID 655374)
is still in use
HINT: If you're sure there are no old server processes still
running, rem
"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? Otherwis
> > 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 that.
> They do allow
> > concurr
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 igno
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
"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/dir
> > 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
> be
"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 reasona
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
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 a
"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 somet
> >> 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 re
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 alread
"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 i
> 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 loo
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
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 ?)
>
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
27 matches
Mail list logo
