>>> 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
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_xlog/0001010A00
22 matches
Mail list logo
