>>> On 16.06.2006 at 23:21:21, in message
<[EMAIL PROTECTED]>, Bruce Momjian
wrote:
> Yea. Where you using WAL archiving? We will have a fix in 8.1.5 to
> prevent multiple archivers from starting. Perhaps that was a cause.
>
Not at the time, no. The rename in question was just a regular WAL
s
Peter Brant wrote:
> Really? If there was a patch, I missed it.
>
> My recollection is that there was general agreement about this
> particular problem (see, for example,
> http://archives.postgresql.org/pgsql-bugs/2006-04/msg00189.php ), but
> things kind of trailed off after that without a reso
Really? If there was a patch, I missed it.
My recollection is that there was general agreement about this
particular problem (see, for example,
http://archives.postgresql.org/pgsql-bugs/2006-04/msg00189.php ), but
things kind of trailed off after that without a resolution.
As far as the complete
I am assuming this problem and the other rash of Win32 problems reported
in March are now all fixed in 8.1.4. If not, please let me know.
---
Tom Lane wrote:
> I wrote:
> > "Peter Brant" <[EMAIL PROTECTED]> writes:
> >> Doe
This is probably somewhat superfluous, but we had another one these
incidents last night whose details confirm your explanation here.
[2006-04-21 00:22:19.500 ] 2452 LOG: could not rename file
"pg_xlog/0001011A004C" to
"pg_xlog/0001011A0071", continuing to try
the autovac
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
"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
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
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
"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
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
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
> > 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
"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
"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
ROTECTED]
> Sent: Tuesday, April 18, 2006 4:15 PM
> To: Bruce Momjian; Qingqing Zhou <[EMAIL PROTECTED];
> Magnus Hagander <[EMAIL PROTECTED]
> Cc: pgsql-bugs@postgresql.org
> Subject: Re: [BUGS] [Win32] Problem with rename()
>
> Unfortunately, it's not that simple
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
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
> 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_
""Peter Brant"" <[EMAIL PROTECTED]>
>
> 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 n
Peter Brant wrote:
> 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 re
21 matches
Mail list logo
