Re: [HACKERS] stack usage in toast_insert_or_update()

2007-02-01 Thread Pavan Deolasee
On 1/31/07, Tom Lane [EMAIL PROTECTED] wrote: We can't change TOAST_MAX_CHUNK_SIZE without forcing an initdb, but I think that it would be safe to remove the MAXALIGN'ing of the tuple size in the tests in heapam.c, that is That would mean that the tuple size in the heap may exceed

Re: [HACKERS] stack usage in toast_insert_or_update()

2007-02-01 Thread Jan Wieck
On 1/31/2007 12:41 PM, Tom Lane wrote: Pavan Deolasee [EMAIL PROTECTED] writes: On 1/31/07, Tom Lane [EMAIL PROTECTED] wrote: The toast code takes pains to ensure that the tuples it creates won't be subject to re-toasting. Else it'd be an infinite recursion. I think I found it. The

Re: [HACKERS] stack usage in toast_insert_or_update()

2007-02-01 Thread Tom Lane
Jan Wieck [EMAIL PROTECTED] writes: On 1/31/2007 12:41 PM, Tom Lane wrote: We can't change TOAST_MAX_CHUNK_SIZE without forcing an initdb, but I think that it would be safe to remove the MAXALIGN'ing of the tuple size in the tests in heapam.c, that is Can't we maxalign the page header in the

Re: [HACKERS] stack usage in toast_insert_or_update()

2007-01-31 Thread Pavan Deolasee
On 1/31/07, Tom Lane [EMAIL PROTECTED] wrote: Pavan Deolasee [EMAIL PROTECTED] writes: Btw, I noticed that the toast_insert_or_update() is re-entrant. toast_save_datum() calls simple_heap_insert() which somewhere down the line calls toast_insert_or_update() again. The toast code takes pains

Re: [HACKERS] stack usage in toast_insert_or_update()

2007-01-31 Thread Pavan Deolasee
On 1/31/07, Pavan Deolasee [EMAIL PROTECTED] wrote: Attached is a patch which would print the recursion depth for toast_insert_or_update() before PANICing the server to help us examine the core. Here is the attachment. Thanks, Pavan -- EnterpriseDB http://www.enterprisedb.com

Re: [HACKERS] stack usage in toast_insert_or_update()

2007-01-31 Thread Tom Lane
Pavan Deolasee [EMAIL PROTECTED] writes: On 1/31/07, Tom Lane [EMAIL PROTECTED] wrote: The toast code takes pains to ensure that the tuples it creates won't be subject to re-toasting. Else it'd be an infinite recursion. I think I found it. The toast_insert_or_update() function gets into an

[HACKERS] stack usage in toast_insert_or_update()

2007-01-30 Thread Pavan Deolasee
Not sure whether its worth optimizing, but had spotted this while browsing the code a while back. So thought would post it anyways. The stack usage for toast_insert_or_update() may run into several KBs since the MaxHeapAttributeNumber is set to a very large value of 1600. The usage could

Re: [HACKERS] stack usage in toast_insert_or_update()

2007-01-30 Thread Tom Lane
Pavan Deolasee [EMAIL PROTECTED] writes: The stack usage for toast_insert_or_update() may run into several KBs since the MaxHeapAttributeNumber is set to a very large value of 1600. The usage could anywhere between 28K to 48K depending on alignment and whether its a 32-bit or a 64-bit machine.

Re: [HACKERS] stack usage in toast_insert_or_update()

2007-01-30 Thread Pavan Deolasee
On 1/30/07, Tom Lane [EMAIL PROTECTED] wrote: Pavan Deolasee [EMAIL PROTECTED] writes: The stack usage for toast_insert_or_update() may run into several KBs since the MaxHeapAttributeNumber is set to a very large value of 1600. The usage could anywhere between 28K to 48K depending on

Re: [HACKERS] stack usage in toast_insert_or_update()

2007-01-30 Thread Tom Lane
Pavan Deolasee [EMAIL PROTECTED] writes: Btw, I noticed that the toast_insert_or_update() is re-entrant. toast_save_datum() calls simple_heap_insert() which somewhere down the line calls toast_insert_or_update() again. The toast code takes pains to ensure that the tuples it creates won't be