On Tue, Nov 29, 2016 at 9:15 PM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.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
pg_hba_rules_6.patch
Description: Binary data
pg_hba_rules_tap_tests_2.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
