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
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 striki
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
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()
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 broadcas
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 th
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
> gav
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
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: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.
>
>
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 particula
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
12 matches
Mail list logo
