On Wed, Jan 4, 2017 at 5:03 PM, Thomas Munro
wrote:
> The way I proposed makes it a lot easier to work with dynamic names so
> you can differentiate variable numbers of areas; the names would have
> exactly the right extent and they'd get unregistered in each backend
> at just the right time.
Onl
On Thu, Jan 5, 2017 at 10:23 AM, Robert Haas wrote:
> On Tue, Dec 27, 2016 at 9:28 PM, Thomas Munro
> wrote:
>> On Wed, Dec 28, 2016 at 11:57 AM, Thomas Munro
>> wrote:
>>> But I'm starting to think that the best way might be to do BOTH of the
>>> things I said in my previous message: make dsa.c
On Tue, Dec 27, 2016 at 9:28 PM, Thomas Munro
wrote:
> On Wed, Dec 28, 2016 at 11:57 AM, Thomas Munro
> wrote:
>> But I'm starting to think that the best way might be to do BOTH of the
>> things I said in my previous message: make dsa.c register on
>> create/attach and also unregister before deta
Thomas Munro writes:
> [2. text/x-diff; fix-dsa-tranche-registration.patch]
Fuzzing with the patch applied hasn't triggered the crash so far. It
did happen 5 times with the same amount of fuzzing before patching.
regards,
Andreas
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
On Wed, Dec 28, 2016 at 11:57 AM, Thomas Munro
wrote:
> But I'm starting to think that the best way might be to do BOTH of the
> things I said in my previous message: make dsa.c register on
> create/attach and also unregister before detaching iff the name was
> supplied at creation time for the be
Andreas Seltenreich writes:
> Thomas Munro writes:
>
>> It is safe, as long as the segment remains mapped. Each backend that
>> attaches calls LWLockRegisterTranche giving it the address of the name
>> in its virtual address space.
>
> Hmok, I was under the impression only backends participating
Thomas Munro writes:
> On Wed, Dec 28, 2016 at 11:38 AM, Andreas Seltenreich
> wrote:
>> Thomas Munro writes:
>>
>>> On Wed, Dec 28, 2016 at 10:40 AM, Thomas Munro
>>> wrote:
On Wed, Dec 28, 2016 at 10:01 AM, Andreas Seltenreich
wrote:
> testing master as of fe591f8bf6 produced
On Wed, Dec 28, 2016 at 11:38 AM, Andreas Seltenreich
wrote:
> Thomas Munro writes:
>
>> On Wed, Dec 28, 2016 at 10:40 AM, Thomas Munro
>> wrote:
>>> On Wed, Dec 28, 2016 at 10:01 AM, Andreas Seltenreich
>>> wrote:
testing master as of fe591f8bf6 produced a crash reading
pg_stat_acti
Thomas Munro writes:
> On Wed, Dec 28, 2016 at 10:40 AM, Thomas Munro
> wrote:
>> On Wed, Dec 28, 2016 at 10:01 AM, Andreas Seltenreich
>> wrote:
>>> testing master as of fe591f8bf6 produced a crash reading
>>> pg_stat_activity (backtrace below). Digging around with with gdb
>>> revealed that
On Wed, Dec 28, 2016 at 10:40 AM, Thomas Munro
wrote:
> On Wed, Dec 28, 2016 at 10:01 AM, Andreas Seltenreich
> wrote:
>> testing master as of fe591f8bf6 produced a crash reading
>> pg_stat_activity (backtrace below). Digging around with with gdb
>> revealed that pgstat_get_wait_event() returned
On Wed, Dec 28, 2016 at 10:01 AM, Andreas Seltenreich
wrote:
> testing master as of fe591f8bf6 produced a crash reading
> pg_stat_activity (backtrace below). Digging around with with gdb
> revealed that pgstat_get_wait_event() returned an invalid pointer for a
> classId PG_WAIT_LWLOCK.
>
> I thin
Hi,
testing master as of fe591f8bf6 produced a crash reading
pg_stat_activity (backtrace below). Digging around with with gdb
revealed that pgstat_get_wait_event() returned an invalid pointer for a
classId PG_WAIT_LWLOCK.
I think the culprit is dsa.c passing a pointer to memory that goes away
on
12 matches
Mail list logo
