Am I correct in the thought that the various files listed below are not
used by the database and can be safely removed? There were no other
active db connections when I issued this command.
I think truncate (Slony) left them behind.
ssdb=# select file
from pg_ls_dir('base/'|| (select oid
Rod Taylor [EMAIL PROTECTED] writes:
Am I correct in the thought that the various files listed below are not
used by the database and can be safely removed? There were no other
active db connections when I issued this command.
I think truncate (Slony) left them behind.
I don't particularly
On Fri, 2006-05-05 at 14:09 -0400, Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
Am I correct in the thought that the various files listed below are not
used by the database and can be safely removed? There were no other
active db connections when I issued this command.
I think
Rod Taylor [EMAIL PROTECTED] writes:
At some point it must have failed in copying the data across, aborted,
and restarted.
Unless you had an actual backend crash, that's not an adequate
explanation. Transaction abort does clean up created files.
regards, tom lane
On Fri, 2006-05-05 at 14:31 -0400, Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
At some point it must have failed in copying the data across, aborted,
and restarted.
Unless you had an actual backend crash, that's not an adequate
explanation. Transaction abort does clean up
Rod Taylor [EMAIL PROTECTED] writes:
On Fri, 2006-05-05 at 14:31 -0400, Tom Lane wrote:
Unless you had an actual backend crash, that's not an adequate
explanation. Transaction abort does clean up created files.
The only thing I can come up with is that perhaps someone forcefully
gave it a
On Fri, 2006-05-05 at 15:10 -0400, Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
On Fri, 2006-05-05 at 14:31 -0400, Tom Lane wrote:
Unless you had an actual backend crash, that's not an adequate
explanation. Transaction abort does clean up created files.
The only thing I can
Rod Taylor [EMAIL PROTECTED] writes:
% 1960 2006-05-02 17:03:19 EDTLOG: 0: server process (PID 10171) exited
with exit code 1
Hm. I wonder if there are any uses of exit(1) in the Slony triggers.
regards, tom lane
---(end of
On Friday 05 May 2006 13:11, Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
% 1960 2006-05-02 17:03:19 EDTLOG: 0: server process (PID 10171)
exited with exit code 1
Hm. I wonder if there are any uses of exit(1) in the Slony triggers.
No, there are no calls to exit() in the
On Fri, 2006-05-05 at 16:11 -0400, Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
% 1960 2006-05-02 17:03:19 EDTLOG: 0: server process (PID 10171)
exited with exit code 1
Hm. I wonder if there are any uses of exit(1) in the Slony triggers.
It doesn't appear so. It does have
Rod Taylor [EMAIL PROTECTED] writes:
On Fri, 2006-05-05 at 16:11 -0400, Tom Lane wrote:
Hm. I wonder if there are any uses of exit(1) in the Slony triggers.
It doesn't appear so. It does have this though:
Well, a SIGTERM would have resulted in a bleat in the postmaster log.
The striking
On Fri, 2006-05-05 at 18:53 -0400, Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
On Fri, 2006-05-05 at 16:11 -0400, Tom Lane wrote:
Hm. I wonder if there are any uses of exit(1) in the Slony triggers.
It doesn't appear so. It does have this though:
Well, a SIGTERM would have
Hey guys,
When do you reckon 8.1.3 will be released? That has the massive speedup
on GiST index creation, right?
I'm planning on a major upgrade soon, but the greatest time in reload is
taken up by index creation time, so I'll hang out for 8.1.3.
Any ETA?
Chris
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
When do you reckon 8.1.3 will be released?
We haven't really thought about it yet ... if you're desperate for that
tsearch2 patch, you could pull REL8_1_STABLE branch tip from CVS and use
that ...
regards, tom lane
14 matches
Mail list logo