Michael Paquier writes:
> On Tue, May 12, 2020 at 04:15:26PM -0400, Robert Haas wrote:
>> On Mon, May 11, 2020 at 10:48 PM Tom Lane wrote:
>>> I have a standing note to check the permissions on /cores after any macOS
>>> upgrade, because every so often Apple decides that that directory ought to
On Tue, May 12, 2020 at 04:15:26PM -0400, Robert Haas wrote:
> On Mon, May 11, 2020 at 10:48 PM Tom Lane wrote:
>> I have a standing note to check the permissions on /cores after any macOS
>> upgrade, because every so often Apple decides that that directory ought to
>> be read-only.
>
> Thanks,
On Mon, May 11, 2020 at 10:48 PM Tom Lane wrote:
> I have a standing note to check the permissions on /cores after any macOS
> upgrade, because every so often Apple decides that that directory ought to
> be read-only.
Thanks, that was my problem.
--
Robert Haas
EnterpriseDB:
On Tue, May 12, 2020 at 3:36 AM Robert Haas wrote:
> On Sun, May 10, 2020 at 11:21 PM Andy Fan
> wrote:
> > Looks this doesn't mean a crash. If the test case(subscription/t/
> 013_partition.pl)
> > failed, test framework kill some process, which leads the above
> message. So you can
> >
Robert Haas writes:
> On Mon, May 11, 2020 at 4:24 PM Antonin Houska wrote:
>> Could "sysctl kernel.core_pattern" be the problem? I discovered this setting
>> sometime when I also couldn't find the core dump on linux.
> Well, I'm running on macOS and the core files normally show up in
> /cores,
On Mon, May 11, 2020 at 4:24 PM Antonin Houska wrote:
> Could "sysctl kernel.core_pattern" be the problem? I discovered this setting
> sometime when I also couldn't find the core dump on linux.
Well, I'm running on macOS and the core files normally show up in
/cores, but in this case they
Robert Haas wrote:
> On Sun, May 10, 2020 at 11:21 PM Andy Fan wrote:
> > Looks this doesn't mean a crash. If the test
> > case(subscription/t/013_partition.pl)
> > failed, test framework kill some process, which leads the above message.
> > So you can
> > ignore this issue now. Thanks
>
On Sun, May 10, 2020 at 11:21 PM Andy Fan wrote:
> Looks this doesn't mean a crash. If the test
> case(subscription/t/013_partition.pl)
> failed, test framework kill some process, which leads the above message. So
> you can
> ignore this issue now. Thanks
I think there might be a real
On Mon, May 11, 2020 at 9:48 AM Andy Fan wrote:
> Hi:
>
>
> 2020-05-11 09:37:40.778 CST [69541] sub_viaroot WARNING: terminating
> connection because of crash of another server process
>
> Looks this doesn't mean a crash. If the test case(subscription/t/
013_partition.pl)
failed, test
Hi:
When I run make -C subscription check, then I see the following logs
in ./tmp_check/log/013_partition_publisher.log
2020-05-11 09:37:40.778 CST [69541] sub_viaroot WARNING: terminating
connection because of crash of another server process
2020-05-11 09:37:40.778 CST [69541] sub_viaroot
10 matches
Mail list logo
