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
-
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
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 s
"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 con
"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 mo
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),
>
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 ?
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 compiler
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.wi
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 unreason
"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 ha
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 CurrentM
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 http://www
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 undue
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 be
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
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
--
Pa
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
18 matches
Mail list logo
