On 2015-02-17, Ted Unangst wrote:
>> -memcpy(&addrcopy, &addr, sizeof(addrcopy));
>> -memcpy(&maskcopy, &mask, sizeof(maskcopy));
>> +memcpy(&addrcopy, addr, addr->sa_len);
>> +memcpy(&maskcopy, mask, mask->sa_len);
>
> How did this ever work?
It di
On 2015-02-16 Mon 18:19 PM |, Hugo Osvaldo Barrera wrote:
> #3 0x11080cf8d1b1 in check_ip (raddr=0x110abc279918,
> addr=0x110a899f9058, mask=0x110a899f9158) at hba.c:704
Is this an IPv6 thing?
Until recently, Squid crashes likewise:
Squid bug: 4024
Status: RESOLVED FIXED
"l
On 2015-02-16 23:21, Jérémie Courrèges-Anglas wrote:
> j...@wxcvbn.org (Jérémie Courrèges-Anglas) writes:
>
> > Please try the diff below. It fixes the "backwards memcpy" problem
> > easily noticeable with psql -h ::1.
>
> Updated diff. Thanks to Stuart for reminding me that netmasks sa_len
> valu
Jérémie Courrèges-Anglas wrote:
> Please try the diff below. It fixes the "backwards memcpy" problem
> easily noticeable with psql -h ::1.
>
> $OpenBSD$
> --- src/backend/libpq/hba.c.orig Mon Feb 16 21:53:21 2015
> +++ src/backend/libpq/hba.c Mon Feb 16 21:54:44 2015
> @@ -700,8 +700,8 @@
worked out with jca and lteo, this fixes this issue (which only occurs
when there's an ipv6 connection) for me.
Index: Makefile
===
RCS file: /cvs/ports/databases/postgresql/Makefile,v
retrieving revision 1.198
diff -u -p -r1.198 Make
j...@wxcvbn.org (Jérémie Courrèges-Anglas) writes:
> Please try the diff below. It fixes the "backwards memcpy" problem
> easily noticeable with psql -h ::1.
Updated diff. Thanks to Stuart for reminding me that netmasks sa_len
values can be much surprising.
$OpenBSD$
--- src/backend/libpq/hba.c
Please try the diff below. It fixes the "backwards memcpy" problem
easily noticeable with psql -h ::1.
$OpenBSD$
--- src/backend/libpq/hba.c.origMon Feb 16 21:53:21 2015
+++ src/backend/libpq/hba.c Mon Feb 16 21:54:44 2015
@@ -700,8 +700,8 @@ check_ip(SockAddr *raddr, struct sockaddr
On Mon, Feb 16, 2015 at 2:19 PM, Hugo Osvaldo Barrera
wrote:
> On 2015-02-16 16:24, Stuart Henderson wrote:
> > On 2015-02-15, Hugo Osvaldo Barrera wrote:
> > >
> > > Am I mistaken in understanding that this is an issue with postgresql
> itself,
> > > and not a local configuration error?
> >
> >
On 2015/02/16 21:02, Stuart Henderson wrote:
> On 2015/02/16 17:19, Hugo Osvaldo Barrera wrote:
> > (gdb) bt
>
> Was this backtrace from a new coredump, or was it from one created by
> the old binary? (if the latter, please could you remove the old coredump
> and get it to crash again and send a
On 2015-02-16 20:44, Stuart Henderson wrote:
> > Thanks a lot, it did. I was unaware of make DEBUG, and had been editing
the
> > Makefile with no success.
>
> The missing piece is that, normally, binaries get stripped of their
> debug symbols in the "fake install" stage. Passing the flags in via DE
On 2015-02-16 21:02, Stuart Henderson wrote:
> On 2015/02/16 17:19, Hugo Osvaldo Barrera wrote:
> > (gdb) bt
>
> Was this backtrace from a new coredump, or was it from one created by
> the old binary? (if the latter, please could you remove the old coredump
> and get it to crash again and send a
On 2015/02/16 17:19, Hugo Osvaldo Barrera wrote:
> (gdb) bt
Was this backtrace from a new coredump, or was it from one created by
the old binary? (if the latter, please could you remove the old coredump
and get it to crash again and send a fresh backtrace?)
On 2015-02-16 16:24, Stuart Henderson wrote:
> On 2015-02-15, Hugo Osvaldo Barrera wrote:
> >
> > Am I mistaken in understanding that this is an issue with postgresql
itself,
> > and not a local configuration error?
>
> Correct.
>
> > I tried building postgres with debug symbols (I added the flags
On 2015-02-15, Hugo Osvaldo Barrera wrote:
>
> Am I mistaken in understanding that this is an issue with postgresql itself,
> and not a local configuration error?
Correct.
> I tried building postgres with debug symbols (I added the flags described
> here[1] to the ports Makefile), but the backtr
On 2015-02-14 13:29, Stuart Henderson wrote:
> On 2015-02-14, Joel Sing wrote:
> > The interesting/useful part is:
> >
> > LOG: statement: SELECT ... ORDER BY c.oid
> > LOG: server process (PID 11531) was terminated by signal 6: Abort trap
> >
> > So the server process is being sent a SIGABRT, w
On 2015-02-14, Joel Sing wrote:
> The interesting/useful part is:
>
> LOG: statement: SELECT ... ORDER BY c.oid
> LOG: server process (PID 11531) was terminated by signal 6: Abort trap
>
> So the server process is being sent a SIGABRT, which is causing it to
> terminate. There is a good chance
On Saturday 14 February 2015, Hugo Osvaldo Barrera wrote:
> On 2015-02-14 02:28, Abel Abraham Camarillo Ojeda wrote:
> > On Sat, Feb 14, 2015 at 2:12 AM, Hugo Osvaldo Barrera
>
> wrote:
> > > On 2015-02-13 13:20, Stuart Henderson wrote:
> > >> On 2015-02-12, Hugo Osvaldo Barrera wrote:
> > >> > O
On 2015-02-14 02:28, Abel Abraham Camarillo Ojeda wrote:
> On Sat, Feb 14, 2015 at 2:12 AM, Hugo Osvaldo Barrera
wrote:
> > On 2015-02-13 13:20, Stuart Henderson wrote:
> >> On 2015-02-12, Hugo Osvaldo Barrera wrote:
> >> > On 2015-02-12 10:18, Stuart Henderson wrote:
> >> >> On 2015-02-11, Hugo
On Sat, Feb 14, 2015 at 2:12 AM, Hugo Osvaldo Barrera wrote:
> On 2015-02-13 13:20, Stuart Henderson wrote:
>> On 2015-02-12, Hugo Osvaldo Barrera wrote:
>> > On 2015-02-12 10:18, Stuart Henderson wrote:
>> >> On 2015-02-11, Hugo Osvaldo Barrera wrote:
>> >> > Can
>> >> > someone else confirm po
On 2015-02-13 13:20, Stuart Henderson wrote:
> On 2015-02-12, Hugo Osvaldo Barrera wrote:
> > On 2015-02-12 10:18, Stuart Henderson wrote:
> >> On 2015-02-11, Hugo Osvaldo Barrera wrote:
> >> > Can
> >> > someone else confirm postgres9.4 work fine on the latest -snapshot?
(the
> >> > confirmation
On 2015-02-12, Hugo Osvaldo Barrera wrote:
> On 2015-02-12 10:18, Stuart Henderson wrote:
>> On 2015-02-11, Hugo Osvaldo Barrera wrote:
>> > Can
>> > someone else confirm postgres9.4 work fine on the latest -snapshot? (the
>> > confirmation would be helpful to reafirm that it's not an issue with
On 2015-02-12 10:18, Stuart Henderson wrote:
> On 2015-02-11, Hugo Osvaldo Barrera wrote:
> > Can
> > someone else confirm postgres9.4 work fine on the latest -snapshot? (the
> > confirmation would be helpful to reafirm that it's not an issue with some
> > dependency or library).
>
> Works fine on
On 2015-02-11, Hugo Osvaldo Barrera wrote:
> Can
> someone else confirm postgres9.4 work fine on the latest -snapshot? (the
> confirmation would be helpful to reafirm that it's not an issue with some
> dependency or library).
Works fine on my bacula box, running 9.4.1 (and previously 9.4.0) on am
On 2015-02-11 19:54, Jan Stary wrote:
> On Feb 11 14:49:17, h...@barrera.io wrote:
> > Hi,
> >
> > I upgraded to -snapshot today, and did all the proper postgresql upgrade:
> > pg_dump, moved the old db out the the way, re-init'd, started, and
import.
> >
> > The thing is, upon receiving connection
Hi,
I upgraded to -snapshot today, and did all the proper postgresql upgrade:
pg_dump, moved the old db out the the way, re-init'd, started, and import.
The thing is, upon receiving connections, postgres dies horribly. The log is
just this following iterating over and over:
WARNING: terminati
25 matches
Mail list logo
