Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] fork/exec problem: DynaHashCxt

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com>
Cc: "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org>,"'PostgreSQL Win32 port list'" <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: [HACKERS] fork/exec problem: DynaHashCxt
Date: 2003-12-03 05:01:53
Message-ID: 27094.1070427713@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-hackers-win32
Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com> writes:
> So this means we'll have to pull relHash out of the shared FreeSpaceMap
> structure and make it a variable in it's own right?

Hm.  The freespace.c code is relatively new and might not be jumping
through all of the hoops it should be jumping through.  My recollection
of the older code is that the logic was like "create or attach to shared
memory structure named 'foo', if not create then initialize the shared
structure".  I'll take the blame if freespace.c doesn't do this right...

> [Same goes for lockHash and proclockHash in the LockMethod structure
> reference by "LockTable (lock method table)"]

The lock code *should* be doing this right, unless I've totally
forgotten the modification history ...

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Randolf RichardsonDate: 2003-12-03 05:20:35
Subject: Re: *sigh*
Previous:From: Claudio NatoliDate: 2003-12-03 04:48:42
Subject: Re: [HACKERS] fork/exec problem: DynaHashCxt

pgsql-hackers-win32 by date

Next:From: Claudio NatoliDate: 2003-12-03 05:30:40
Subject: Re: [HACKERS] fork/exec problem: DynaHashCxt
Previous:From: Claudio NatoliDate: 2003-12-03 04:48:42
Subject: Re: [HACKERS] fork/exec problem: DynaHashCxt

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group