Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Dave Page wrote:
Actually thinking about it, I think we should plan the next cycle
based on whatever ends up happening this time - eg. April freeze,
Aug-Sept beta, Oct release.
I actually would be more inclined to have an even
Are we leaking memory in vac_update_relstats ?
/* Fetch a copy of the tuple to scribble on */
ctup = SearchSysCacheCopy(RELOID,
ObjectIdGetDatum(relid),
0, 0, 0);
This copy is not subsequently freed in the function.
Thanks,
Pavan
--
Pavan Deolasee wrote:
Are we leaking memory in vac_update_relstats ?
/* Fetch a copy of the tuple to scribble on */
ctup = SearchSysCacheCopy(RELOID,
ObjectIdGetDatum(relid),
0, 0, 0);
This copy is not subsequently freed in the
Hi,
It's palloc'd in the current memory context, so it's not serious. It'll
be freed at the end of the transaction, if not before that. That's the
beauty of memory contexts; no need to worry about small allocations like
that.
That's the beauty of memory contexts for small allocations. But
Hi,
That's the beauty of memory contexts for small allocations. But because of
the 'convenience' of memory contexts we sometimes tend to not pay attention
to doing explicit pfrees. As a general rule I think allocations in
TopMemoryContext should be critically examined. I was bitten by this
The MAXIMUM_ALIGNOF value is set to 8 bytes in a Windows- 32-bit
environment. I have very little knowledge about Windows, but at
the face of it, this looks strange. Any idea why is this required ?
May be I am missing something obvious.
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB
NikhilS [EMAIL PROTECTED] writes:
One specific case I want to mention here is hash_create(). For local hash
tables if HASH_CONTEXT is not specified, they get created in a context which
becomes a direct child of TopMemoryContext. Wouldn't it be a better idea to
create the table in
Pavan Deolasee [EMAIL PROTECTED] writes:
The MAXIMUM_ALIGNOF value is set to 8 bytes in a Windows- 32-bit
environment. I have very little knowledge about Windows, but at
the face of it, this looks strange. Any idea why is this required ?
It's not entirely unreasonable. The same thing happens
Tom Lane wrote:
Pavan Deolasee [EMAIL PROTECTED] writes:
The MAXIMUM_ALIGNOF value is set to 8 bytes in a Windows- 32-bit
environment. I have very little knowledge about Windows, but at
the face of it, this looks strange. Any idea why is this required ?
It's not entirely
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Anyway, we detect this directly based on the C compiler's behavior,
and you can't argue with the compiler about it. Whatever it's
doing is right by definition.
Perhaps Pavan is referring to what is hardcoded in pg_config.h.win32
Tom Lane wrote:
I see though that the comment in pg_config.h.win32 claims it was derived
from mechanically-generated configure output, so unless that's lying
it should be OK already. AFAIK struct alignment is part of the ABI for
a platform and is not subject to the whims of individual
On 7/20/07, Tom Lane [EMAIL PROTECTED] wrote:
Pavan Deolasee [EMAIL PROTECTED] writes:
The MAXIMUM_ALIGNOF value is set to 8 bytes in a Windows- 32-bit
environment. I have very little knowledge about Windows, but at
the face of it, this looks strange. Any idea why is this required ?
It's
On 7/20/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Pavan Deolasee wrote:
Are we leaking memory in vac_update_relstats ?
/* Fetch a copy of the tuple to scribble on */
ctup = SearchSysCacheCopy(RELOID,
ObjectIdGetDatum(relid),
Pavan Deolasee [EMAIL PROTECTED] writes:
On 7/20/07, Heikki Linnakangas [EMAIL PROTECTED] wrote:
It's palloc'd in the current memory context, so it's not serious.
Right. But may be for code completeness, we should add that
missing heap_freetuple.
Personally I've been thinking of mounting an
Tom Lane [EMAIL PROTECTED] writes:
Personally I've been thinking of mounting an effort to get rid of
unnecessary pfree's wherever possible. Particularly in user-defined
functions, cleaning up at the end is a waste of code space and
cycles too, because they're typically called in contexts
Bill Moran [EMAIL PROTECTED] writes:
Oddly, the query succeeds if it's fed into psql.
I'm now full of mystery and wonder. It would appear as if the
underlying problem has something to do with PHP, but why should this
cause a backend process to crash?
Ah, I see it. Your PHP script is
Gregory Stark [EMAIL PROTECTED] writes:
It seems like the impact of this is self-limiting though. The worst-case is
going to be something which executes an extra pfree for every tuple. Or
perhaps one for every expression in a complex query involving lots of
expressions. Saving a few extra
Tom Lane wrote:
I've actually thought about making short-term memory
contexts use a variant MemoryContext type in which pfree was a no-op and
palloc was simplified by not worrying at all about recycling space.
That sounds like a good idea to me.
cheers
andrew
18 matches
Mail list logo
