Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock)
От | Heikki Linnakangas |
---|---|
Тема | Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock) |
Дата | |
Msg-id | 4F3C0F3F.3060206@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock) (Fujii Masao <masao.fujii@gmail.com>) |
Ответы |
Re: Scaling XLog insertion (was Re: Moving more work
outside WALInsertLock)
|
Список | pgsql-hackers |
On 15.02.2012 18:52, Fujii Masao wrote: > On Thu, Feb 16, 2012 at 1:01 AM, Heikki Linnakangas > <heikki.linnakangas@enterprisedb.com> wrote: >> Are you still seeing this failure with the latest patch I posted >> (http://archives.postgresql.org/message-id/4F38F5E5.8050203@enterprisedb.com)? > > Yes. Just to be safe, I again applied the latest patch to HEAD, > compiled that and tried > the same test. Then unfortunately I got the same failure again. Ok. > I ran the configure with '--enable-debug' '--enable-cassert' > 'CPPFLAGS=-DWAL_DEBUG', > and make with -j 2 option. > > When I ran the test with wal_debug = on, I got the following assertion failure. > > LOG: INSERT @ 0/17B3F90: prev 0/17B3F10; xid 998; len 31: Heap - > insert: rel 1663/12277/16384; tid 0/197 > STATEMENT: create table t (i int); insert into t > values(generate_series(1,10000)); delete from t > LOG: INSERT @ 0/17B3FD0: prev 0/17B3F50; xid 998; len 31: Heap - > insert: rel 1663/12277/16384; tid 0/198 > STATEMENT: create table t (i int); insert into t > values(generate_series(1,10000)); delete from t > TRAP: FailedAssertion("!(((bool) (((void*)(&(target->tid)) != ((void > *)0))&& ((&(target->tid))->ip_posid != 0))))", File: "heapam.c", > Line: 5578) > LOG: xlog bg flush request 0/17B4000; write 0/17A6000; flush 0/179D5C0 > LOG: xlog bg flush request 0/17B4000; write 0/17B0000; flush 0/17B0000 > LOG: server process (PID 16806) was terminated by signal 6: Abort trap > > This might be related to the original problem which Jeff and I saw. That's strange. I made a fresh checkout, too, and applied the patch, but still can't reproduce. I used the attached script to test it. It's surprising that the crash happens when the records are inserted, not at recovery. I don't see anything obviously wrong there, so could you please take a look around in gdb and see if you can get a clue what's going on? What's the stack trace? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
Вложения
В списке pgsql-hackers по дате отправления: