Re: [HACKERS] MemoryContextSwitchTo (Re: [GENERAL] Autovacuum daemon terminated by signal 11)

2009-01-20 Thread Alvaro Herrera
Tom Lane wrote: > Alvaro Herrera writes: > > But freed memory is clobbered, so if we were to have an assert that > > checks the node tag, it should show up. In fact, we do have such an > > assert, but only for compilers other than GCC, because the inline > > version of palloc() cannot have it fo

Re: [HACKERS] MemoryContextSwitchTo (Re: [GENERAL] Autovacuum daemon terminated by signal 11)

2009-01-17 Thread Tom Lane
Alvaro Herrera writes: > Tom Lane wrote: >> No, not really. AFAICS the reason for Alvaro not seeing it must be that >> on his machine the new transaction happens to allocate its >> TopTransactionContext control block right in the same place where the >> old one was. > But freed memory is clobber

Re: [HACKERS] MemoryContextSwitchTo (Re: [GENERAL] Autovacuum daemon terminated by signal 11)

2009-01-17 Thread Tom Lane
Simon Riggs writes: > Can we put a identifier into header of each control block, an ascending > value that is unlikely duplicate between calls? That way we'd be able to > tell immediately it wasn't the same block, Same block than what? Unless you can somehow hide that ID number in a MemoryContex

Re: [HACKERS] MemoryContextSwitchTo (Re: [GENERAL] Autovacuum daemon terminated by signal 11)

2009-01-17 Thread Gregory Stark
Tom Lane writes: > Simon Riggs writes: >> Can we add something to memory contexts to make this fail every time? > > No, not really. AFAICS the reason for Alvaro not seeing it must be that > on his machine the new transaction happens to allocate its > TopTransactionContext control block right in

Re: [HACKERS] MemoryContextSwitchTo (Re: [GENERAL] Autovacuum daemon terminated by signal 11)

2009-01-17 Thread Alvaro Herrera
Tom Lane wrote: > Simon Riggs writes: > > Can we add something to memory contexts to make this fail every time? > > No, not really. AFAICS the reason for Alvaro not seeing it must be that > on his machine the new transaction happens to allocate its > TopTransactionContext control block right in

Re: [HACKERS] MemoryContextSwitchTo (Re: [GENERAL] Autovacuum daemon terminated by signal 11)

2009-01-17 Thread Simon Riggs
On Sat, 2009-01-17 at 11:35 -0500, Tom Lane wrote: > Simon Riggs writes: > > Can we add something to memory contexts to make this fail every time? > > No, not really. AFAICS the reason for Alvaro not seeing it must be that > on his machine the new transaction happens to allocate its > TopTransa

Re: [HACKERS] MemoryContextSwitchTo (Re: [GENERAL] Autovacuum daemon terminated by signal 11)

2009-01-17 Thread Tom Lane
Simon Riggs writes: > Can we add something to memory contexts to make this fail every time? No, not really. AFAICS the reason for Alvaro not seeing it must be that on his machine the new transaction happens to allocate its TopTransactionContext control block right in the same place where the old

[HACKERS] MemoryContextSwitchTo (Re: [GENERAL] Autovacuum daemon terminated by signal 11)

2009-01-17 Thread Simon Riggs
On Fri, 2009-01-16 at 18:43 -0500, Tom Lane wrote: > What is happening is that autovacuum_do_vac_analyze contains > > old_cxt = MemoryContextSwitchTo(AutovacMemCxt); > ... > vacuum(vacstmt, relids); > ... > MemoryContextSwitchTo(old_cxt); > > and at the t