From: | Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com> |
---|---|
To: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> |
Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_hba_file_settings view patch |
Date: | 2017-01-04 03:54:16 |
Message-ID: | CAJrrPGekqSGiycMuSOzgcRwtKbtEjJgCo7r419AXQEipn9dMKw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Nov 29, 2016 at 9:15 PM, Ashutosh Bapat <
ashutosh(dot)bapat(at)enterprisedb(dot)com> wrote:
> Here's backtrace and some debugging information
> Program terminated with signal 11, Segmentation fault.
> #0 0x00000000007f96cd in shm_mq_sendv (mqh=0x121e998,
> iov=0x7ffc9b7b79f0, iovcnt=2, nowait=1 '\001') at shm_mq.c:357
> 357 Assert(mq->mq_sender == MyProc);
> (gdb) where
> #0 0x00000000007f96cd in shm_mq_sendv (mqh=0x121e998,
> iov=0x7ffc9b7b79f0, iovcnt=2, nowait=1 '\001') at shm_mq.c:357
> #1 0x00000000006d8387 in mq_putmessage (msgtype=88 'X', s=0x0, len=0)
> at pqmq.c:165
> #2 0x0000000000515147 in ParallelWorkerMain (main_arg=141900502) at
> parallel.c:1120
> #3 0x0000000000783063 in StartBackgroundWorker () at bgworker.c:726
> #4 0x0000000000795b77 in do_start_bgworker (rw=0x1216f00) at
> postmaster.c:5535
> #5 0x0000000000795e4f in maybe_start_bgworker () at postmaster.c:5710
> #6 0x0000000000794eb3 in sigusr1_handler (postgres_signal_arg=10) at
> postmaster.c:4959
> #7 <signal handler called>
> #8 0x00002b005933a693 in select () from /lib/x86_64-linux-gnu/libc.so.6
> #9 0x0000000000790720 in ServerLoop () at postmaster.c:1665
> #10 0x000000000078fe76 in PostmasterMain (argc=8, argv=0x11eef40) at
> postmaster.c:1309
> #11 0x00000000006d8f1d in main (argc=8, argv=0x11eef40) at main.c:228
> (gdb) p mq->mq_sender
> Cannot access memory at address 0x6b636568635f707d
> (gdb) p mq
> $1 = (shm_mq *) 0x6b636568635f706d
>
> Looking at this, I am wondering, how could that happen with your
> patches. But every time I have tried to apply your patches and run
> regression, I get this crash. Just now I tried the patches on a all
> new repository and reproduced the crash.
I am also able to reproduce the crash once, but I didn't find the
reason why I leads to crash if I change the loading of hba and ident
files under currentmemory context instead of postmaster context.
>> Reused the error string once, as in this patch it chances in many places
>> compared
>> to pg_file_settings, so I tend to reuse it.
>
>Thanks. Although the new change might affect the way we translate the
>messages in other languages. I am not sure. So, I will leave it for
>someone with more knowledge to review.
There is no problem to the translation, because i kept those messages
under _(), so translations will pick those messages.
>What we may want to do, is separate the logic of reading the hba rules
>in a list and the logic to update existing rules in two different
>functions e.g read_hba() and load_hba(). hba_rules() can use
>read_hba() with ignore errors flag to get the list of hba lines. It
>can then use this list to create tuples to be returned in hba_rules().
>load_hba() will read_hba() with memory reset on error flag (same
>boolean) to read the list of hba lines and update the saved rules if
>there's no error. err_msg can be either a field in HbaLine, which will
>be used only by hba_rules() OR read_hba() could return list of
>err_msgs as a pass by ref argument.
Because of the above context problem, I just needs some part of the
code to read the pg_hba.conf under current memory context, so changed
the logic into a separate function to read the hba rules under currentmemory
context.
Latest patch is attached.
Regards,
Hari Babu
Fujitsu Australia
Attachment | Content-Type | Size |
---|---|---|
pg_hba_rules_6.patch | application/octet-stream | 49.0 KB |
pg_hba_rules_tap_tests_2.patch | application/octet-stream | 10.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Haribabu Kommi | 2017-01-04 04:00:32 | Re: gettimeofday is at the end of its usefulness? |
Previous Message | Amit Kapila | 2017-01-04 03:20:14 | Re: Odd behavior with PG_TRY |