upstream/postgresql
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2026-06-11 01:30:11 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions
postgresql/src/include/common/fe_memutils.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

102 lines
3.9 KiB
C
Raw Normal View History

Create libpgcommon, and move pg_malloc et al to it libpgcommon is a new static library to allow sharing code among the various frontend programs and backend; this lets us eliminate duplicate implementations of common routines. We avoid libpgport, because that's intended as a place for porting issues; per discussion, it seems better to keep them separate. The first use case, and the only implemented by this patch, is pg_malloc and friends, which many frontend programs were already using. At the same time, we can use this to provide palloc emulation functions for the frontend; this way, some palloc-using files in the backend can also be used by the frontend cleanly. To do this, we change palloc() in the backend to be a function instead of a macro on top of MemoryContextAlloc(). This was previously believed to cause loss of performance, but this implementation has been tweaked by Tom and Andres so that on modern compilers it provides a slight improvement over the previous one. This lets us clean up some places that were already with localized hacks. Most of the pg_malloc/palloc changes in this patch were authored by Andres Freund. Zoltán Böszörményi also independently provided a form of that. libpgcommon infrastructure was authored by Álvaro.
2013-02-12 08:33:40 -05:00
/*
* fe_memutils.h
* memory management support for frontend code
*
Update copyright for 2024 Reported-by: Michael Paquier Discussion: https://postgr.es/m/ZZKTDPxBBMt3C0J9@paquier.xyz Backpatch-through: 12
2024-01-03 20:49:05 -05:00
* Copyright (c) 2003-2024, PostgreSQL Global Development Group
Create libpgcommon, and move pg_malloc et al to it libpgcommon is a new static library to allow sharing code among the various frontend programs and backend; this lets us eliminate duplicate implementations of common routines. We avoid libpgport, because that's intended as a place for porting issues; per discussion, it seems better to keep them separate. The first use case, and the only implemented by this patch, is pg_malloc and friends, which many frontend programs were already using. At the same time, we can use this to provide palloc emulation functions for the frontend; this way, some palloc-using files in the backend can also be used by the frontend cleanly. To do this, we change palloc() in the backend to be a function instead of a macro on top of MemoryContextAlloc(). This was previously believed to cause loss of performance, but this implementation has been tweaked by Tom and Andres so that on modern compilers it provides a slight improvement over the previous one. This lets us clean up some places that were already with localized hacks. Most of the pg_malloc/palloc changes in this patch were authored by Andres Freund. Zoltán Böszörményi also independently provided a form of that. libpgcommon infrastructure was authored by Álvaro.
2013-02-12 08:33:40 -05:00
*
* src/include/common/fe_memutils.h
*/
#ifndef FE_MEMUTILS_H
#define FE_MEMUTILS_H
Unify src/common/'s definitions of MaxAllocSize. Define MaxAllocSize in src/include/common/fe_memutils.h rather than having several copies of it in different src/common/*.c files. This also provides an opportunity to document it better. Back-patch of commit 11b7de4a7, needed now because assorted security fixes are adding additional references to MaxAllocSize in frontend code. Backpatch-through: 14-17 Security: CVE-2026-6473
2026-05-11 08:13:48 -04:00
/*
* Assumed maximum size for allocation requests.
*
* We don't enforce this, so the actual maximum is the platform's SIZE_MAX.
* But it's useful to have it defined in frontend builds, so that common
* code can check for oversized requests without having frontend-vs-backend
* differences. Also, some code relies on MaxAllocSize being no more than
* INT_MAX/2, so rather than setting this to SIZE_MAX, make it the same as
* the backend's value.
*/
#define MaxAllocSize ((Size) 0x3fffffff) /* 1 gigabyte - 1 */
Add palloc_extended for frontend and backend. This commit also adds pg_malloc_extended for frontend. These interfaces can be used to control at a lower level memory allocation using an interface similar to MemoryContextAllocExtended. For example, the callers can specify MCXT_ALLOC_NO_OOM if they want to suppress the "out of memory" error while allocating the memory and handle a NULL return value. Michael Paquier, reviewed by me.
2015-04-03 04:36:12 -04:00
/*
* Flags for pg_malloc_extended and palloc_extended, deliberately named
* the same as the backend flags.
*/
#define MCXT_ALLOC_HUGE 0x01 /* allow huge allocation (> 1 GB) not
* actually used for frontends */
#define MCXT_ALLOC_NO_OOM 0x02 /* no failure if out-of-memory */
#define MCXT_ALLOC_ZERO 0x04 /* zero allocated memory */
/*
* "Safe" memory allocation functions --- these exit(1) on failure
* (except pg_malloc_extended with MCXT_ALLOC_NO_OOM)
*/
Rename "string" pstrdup argument to "in" The former name collides with a symbol also used in the isolation test's parser, causing assorted failures in certain platforms.
2013-02-12 10:43:09 -05:00
extern char *pg_strdup(const char *in);
Create libpgcommon, and move pg_malloc et al to it libpgcommon is a new static library to allow sharing code among the various frontend programs and backend; this lets us eliminate duplicate implementations of common routines. We avoid libpgport, because that's intended as a place for porting issues; per discussion, it seems better to keep them separate. The first use case, and the only implemented by this patch, is pg_malloc and friends, which many frontend programs were already using. At the same time, we can use this to provide palloc emulation functions for the frontend; this way, some palloc-using files in the backend can also be used by the frontend cleanly. To do this, we change palloc() in the backend to be a function instead of a macro on top of MemoryContextAlloc(). This was previously believed to cause loss of performance, but this implementation has been tweaked by Tom and Andres so that on modern compilers it provides a slight improvement over the previous one. This lets us clean up some places that were already with localized hacks. Most of the pg_malloc/palloc changes in this patch were authored by Andres Freund. Zoltán Böszörményi also independently provided a form of that. libpgcommon infrastructure was authored by Álvaro.
2013-02-12 08:33:40 -05:00
extern void *pg_malloc(size_t size);
extern void *pg_malloc0(size_t size);
Add palloc_extended for frontend and backend. This commit also adds pg_malloc_extended for frontend. These interfaces can be used to control at a lower level memory allocation using an interface similar to MemoryContextAllocExtended. For example, the callers can specify MCXT_ALLOC_NO_OOM if they want to suppress the "out of memory" error while allocating the memory and handle a NULL return value. Michael Paquier, reviewed by me.
2015-04-03 04:36:12 -04:00
extern void *pg_malloc_extended(size_t size, int flags);
Harmonize more parameter names in bulk. Make sure that function declarations use names that exactly match the corresponding names from function definitions in optimizer, parser, utility, libpq, and "commands" code, as well as in remaining library code. Do the same for all code related to frontend programs (with the exception of pg_dump/pg_dumpall related code). Like other recent commits that cleaned up function parameter names, this commit was written with help from clang-tidy. Later commits will handle ecpg and pg_dump/pg_dumpall. Author: Peter Geoghegan <pg@bowt.ie> Reviewed-By: David Rowley <dgrowleyml@gmail.com> Discussion: https://postgr.es/m/CAH2-WznJt9CMM9KJTMjJh_zbL5hD9oX44qdJ4aqZtjFi-zA3Tg@mail.gmail.com
2022-09-20 16:09:30 -04:00
extern void *pg_realloc(void *ptr, size_t size);
extern void pg_free(void *ptr);
Create libpgcommon, and move pg_malloc et al to it libpgcommon is a new static library to allow sharing code among the various frontend programs and backend; this lets us eliminate duplicate implementations of common routines. We avoid libpgport, because that's intended as a place for porting issues; per discussion, it seems better to keep them separate. The first use case, and the only implemented by this patch, is pg_malloc and friends, which many frontend programs were already using. At the same time, we can use this to provide palloc emulation functions for the frontend; this way, some palloc-using files in the backend can also be used by the frontend cleanly. To do this, we change palloc() in the backend to be a function instead of a macro on top of MemoryContextAlloc(). This was previously believed to cause loss of performance, but this implementation has been tweaked by Tom and Andres so that on modern compilers it provides a slight improvement over the previous one. This lets us clean up some places that were already with localized hacks. Most of the pg_malloc/palloc changes in this patch were authored by Andres Freund. Zoltán Böszörményi also independently provided a form of that. libpgcommon infrastructure was authored by Álvaro.
2013-02-12 08:33:40 -05:00
Make palloc_array() and friends safe against integer overflow. Sufficiently large "count" arguments could result in undetected overflow, causing the allocated memory chunk to be much smaller than what the caller will subsequently write into it. This is unlikely to be a hazard with 64-bit size_t but can sometimes happen on 32-bit builds, primarily where a function allocates workspace that's significantly larger than its input data. Rather than trying to patch the at-risk callers piecemeal, let's just redefine these macros so that they always check. To do that, move the longstanding add_size() and mul_size() functions into palloc.h and mcxt.c, and adjust them to not be specific to shared-memory allocation. Then invent palloc_mul(), palloc0_mul(), palloc_mul_extended() to use these functions. Actually, the latter use inlined copies to save one function call. repalloc_array() gets similar treatment. I didn't bother trying to inline the calls for repalloc0_array() though. In v14 and v15, this also adds repalloc_extended(), which previously was only available in v16 and up. We need copies of all this in fe_memutils.[hc] as well, since that module also provides palloc_array() etc. Reported-by: Xint Code Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com> Backpatch-through: 14 Security: CVE-2026-6473
2026-05-11 08:13:48 -04:00
/*
* Support for safe calculation of memory request sizes
*/
extern Size add_size(Size s1, Size s2);
extern Size mul_size(Size s1, Size s2);
extern void *pg_malloc_mul(Size s1, Size s2);
extern void *pg_malloc0_mul(Size s1, Size s2);
extern void *pg_malloc_mul_extended(Size s1, Size s2, int flags);
extern void *pg_realloc_mul(void *p, Size s1, Size s2);
Expand palloc/pg_malloc API for more type safety This adds additional variants of palloc, pg_malloc, etc. that encapsulate common usage patterns and provide more type safety. Specifically, this adds palloc_object(), palloc_array(), and repalloc_array(), which take the type name of the object to be allocated as its first argument and cast the return as a pointer to that type. There are also palloc0_object() and palloc0_array() variants for initializing with zero, and pg_malloc_*() variants of all of the above. Inspired by the talloc library. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/bb755632-2a43-d523-36f8-a1e7a389a907@enterprisedb.com
2022-09-12 02:31:56 -04:00
/*
* Variants with easier notation and more type safety
*/
/*
* Allocate space for one object of type "type"
*/
#define pg_malloc_object(type) ((type *) pg_malloc(sizeof(type)))
#define pg_malloc0_object(type) ((type *) pg_malloc0(sizeof(type)))
/*
* Allocate space for "count" objects of type "type"
*/
Make palloc_array() and friends safe against integer overflow. Sufficiently large "count" arguments could result in undetected overflow, causing the allocated memory chunk to be much smaller than what the caller will subsequently write into it. This is unlikely to be a hazard with 64-bit size_t but can sometimes happen on 32-bit builds, primarily where a function allocates workspace that's significantly larger than its input data. Rather than trying to patch the at-risk callers piecemeal, let's just redefine these macros so that they always check. To do that, move the longstanding add_size() and mul_size() functions into palloc.h and mcxt.c, and adjust them to not be specific to shared-memory allocation. Then invent palloc_mul(), palloc0_mul(), palloc_mul_extended() to use these functions. Actually, the latter use inlined copies to save one function call. repalloc_array() gets similar treatment. I didn't bother trying to inline the calls for repalloc0_array() though. In v14 and v15, this also adds repalloc_extended(), which previously was only available in v16 and up. We need copies of all this in fe_memutils.[hc] as well, since that module also provides palloc_array() etc. Reported-by: Xint Code Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com> Backpatch-through: 14 Security: CVE-2026-6473
2026-05-11 08:13:48 -04:00
#define pg_malloc_array(type, count) ((type *) pg_malloc_mul(sizeof(type), count))
#define pg_malloc0_array(type, count) ((type *) pg_malloc0_mul(sizeof(type), count))
#define pg_malloc_array_extended(type, count, flags) ((type *) pg_malloc_mul_extended(sizeof(type), count, flags))
Expand palloc/pg_malloc API for more type safety This adds additional variants of palloc, pg_malloc, etc. that encapsulate common usage patterns and provide more type safety. Specifically, this adds palloc_object(), palloc_array(), and repalloc_array(), which take the type name of the object to be allocated as its first argument and cast the return as a pointer to that type. There are also palloc0_object() and palloc0_array() variants for initializing with zero, and pg_malloc_*() variants of all of the above. Inspired by the talloc library. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/bb755632-2a43-d523-36f8-a1e7a389a907@enterprisedb.com
2022-09-12 02:31:56 -04:00
/*
* Change size of allocation pointed to by "pointer" to have space for "count"
* objects of type "type"
*/
Make palloc_array() and friends safe against integer overflow. Sufficiently large "count" arguments could result in undetected overflow, causing the allocated memory chunk to be much smaller than what the caller will subsequently write into it. This is unlikely to be a hazard with 64-bit size_t but can sometimes happen on 32-bit builds, primarily where a function allocates workspace that's significantly larger than its input data. Rather than trying to patch the at-risk callers piecemeal, let's just redefine these macros so that they always check. To do that, move the longstanding add_size() and mul_size() functions into palloc.h and mcxt.c, and adjust them to not be specific to shared-memory allocation. Then invent palloc_mul(), palloc0_mul(), palloc_mul_extended() to use these functions. Actually, the latter use inlined copies to save one function call. repalloc_array() gets similar treatment. I didn't bother trying to inline the calls for repalloc0_array() though. In v14 and v15, this also adds repalloc_extended(), which previously was only available in v16 and up. We need copies of all this in fe_memutils.[hc] as well, since that module also provides palloc_array() etc. Reported-by: Xint Code Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com> Backpatch-through: 14 Security: CVE-2026-6473
2026-05-11 08:13:48 -04:00
#define pg_realloc_array(pointer, type, count) ((type *) pg_realloc_mul(pointer, sizeof(type), count))
Expand palloc/pg_malloc API for more type safety This adds additional variants of palloc, pg_malloc, etc. that encapsulate common usage patterns and provide more type safety. Specifically, this adds palloc_object(), palloc_array(), and repalloc_array(), which take the type name of the object to be allocated as its first argument and cast the return as a pointer to that type. There are also palloc0_object() and palloc0_array() variants for initializing with zero, and pg_malloc_*() variants of all of the above. Inspired by the talloc library. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/bb755632-2a43-d523-36f8-a1e7a389a907@enterprisedb.com
2022-09-12 02:31:56 -04:00
Don't #include utils/palloc.h in common/fe_memutils.h. This breaks the principle that common/ ought not depend on anything in the server, not only code-wise but in the headers. The only arguable advantage is avoidance of duplication of half a dozen extern declarations, and even that is rather dubious, considering that the previous coding was wrong about which declarations to duplicate: it exposed pnstrdup() to frontend code even though no such function is provided in fe_memutils.c. On the same principle, don't #include utils/memutils.h in the frontend build of psprintf.c. This requires duplicating the definition of MaxAllocSize, but that seems fine to me: there's no a-priori reason why frontend code should use the same size limit as the backend anyway. In passing, clean up some rather odd layout and ordering choices that were imposed on palloc.h to reduce the number of #ifdefs required by the previous approach. Per gripe from Christoph Berg. There's still more work to do to make include/common/ clean, but this part seems reasonably noncontroversial.
2014-04-26 14:14:28 -04:00
/* Equivalent functions, deliberately named the same as backend functions */
extern char *pstrdup(const char *in);
Offer pnstrdup to frontend code We already had it on the backend. Frontend can also use it now. Discussion: https://postgr.es/m/20191204144021.GA17976@alvherre.pgsql
2019-12-04 17:36:06 -05:00
extern char *pnstrdup(const char *in, Size size);
Don't #include utils/palloc.h in common/fe_memutils.h. This breaks the principle that common/ ought not depend on anything in the server, not only code-wise but in the headers. The only arguable advantage is avoidance of duplication of half a dozen extern declarations, and even that is rather dubious, considering that the previous coding was wrong about which declarations to duplicate: it exposed pnstrdup() to frontend code even though no such function is provided in fe_memutils.c. On the same principle, don't #include utils/memutils.h in the frontend build of psprintf.c. This requires duplicating the definition of MaxAllocSize, but that seems fine to me: there's no a-priori reason why frontend code should use the same size limit as the backend anyway. In passing, clean up some rather odd layout and ordering choices that were imposed on palloc.h to reduce the number of #ifdefs required by the previous approach. Per gripe from Christoph Berg. There's still more work to do to make include/common/ clean, but this part seems reasonably noncontroversial.
2014-04-26 14:14:28 -04:00
extern void *palloc(Size size);
extern void *palloc0(Size size);
Add palloc_extended for frontend and backend. This commit also adds pg_malloc_extended for frontend. These interfaces can be used to control at a lower level memory allocation using an interface similar to MemoryContextAllocExtended. For example, the callers can specify MCXT_ALLOC_NO_OOM if they want to suppress the "out of memory" error while allocating the memory and handle a NULL return value. Michael Paquier, reviewed by me.
2015-04-03 04:36:12 -04:00
extern void *palloc_extended(Size size, int flags);
Don't #include utils/palloc.h in common/fe_memutils.h. This breaks the principle that common/ ought not depend on anything in the server, not only code-wise but in the headers. The only arguable advantage is avoidance of duplication of half a dozen extern declarations, and even that is rather dubious, considering that the previous coding was wrong about which declarations to duplicate: it exposed pnstrdup() to frontend code even though no such function is provided in fe_memutils.c. On the same principle, don't #include utils/memutils.h in the frontend build of psprintf.c. This requires duplicating the definition of MaxAllocSize, but that seems fine to me: there's no a-priori reason why frontend code should use the same size limit as the backend anyway. In passing, clean up some rather odd layout and ordering choices that were imposed on palloc.h to reduce the number of #ifdefs required by the previous approach. Per gripe from Christoph Berg. There's still more work to do to make include/common/ clean, but this part seems reasonably noncontroversial.
2014-04-26 14:14:28 -04:00
extern void *repalloc(void *pointer, Size size);
extern void pfree(void *pointer);
Make palloc_array() and friends safe against integer overflow. Sufficiently large "count" arguments could result in undetected overflow, causing the allocated memory chunk to be much smaller than what the caller will subsequently write into it. This is unlikely to be a hazard with 64-bit size_t but can sometimes happen on 32-bit builds, primarily where a function allocates workspace that's significantly larger than its input data. Rather than trying to patch the at-risk callers piecemeal, let's just redefine these macros so that they always check. To do that, move the longstanding add_size() and mul_size() functions into palloc.h and mcxt.c, and adjust them to not be specific to shared-memory allocation. Then invent palloc_mul(), palloc0_mul(), palloc_mul_extended() to use these functions. Actually, the latter use inlined copies to save one function call. repalloc_array() gets similar treatment. I didn't bother trying to inline the calls for repalloc0_array() though. In v14 and v15, this also adds repalloc_extended(), which previously was only available in v16 and up. We need copies of all this in fe_memutils.[hc] as well, since that module also provides palloc_array() etc. Reported-by: Xint Code Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com> Backpatch-through: 14 Security: CVE-2026-6473
2026-05-11 08:13:48 -04:00
extern void *palloc_mul(Size s1, Size s2);
extern void *palloc0_mul(Size s1, Size s2);
extern void *palloc_mul_extended(Size s1, Size s2, int flags);
extern void *repalloc_mul(void *p, Size s1, Size s2);
Don't #include utils/palloc.h in common/fe_memutils.h. This breaks the principle that common/ ought not depend on anything in the server, not only code-wise but in the headers. The only arguable advantage is avoidance of duplication of half a dozen extern declarations, and even that is rather dubious, considering that the previous coding was wrong about which declarations to duplicate: it exposed pnstrdup() to frontend code even though no such function is provided in fe_memutils.c. On the same principle, don't #include utils/memutils.h in the frontend build of psprintf.c. This requires duplicating the definition of MaxAllocSize, but that seems fine to me: there's no a-priori reason why frontend code should use the same size limit as the backend anyway. In passing, clean up some rather odd layout and ordering choices that were imposed on palloc.h to reduce the number of #ifdefs required by the previous approach. Per gripe from Christoph Berg. There's still more work to do to make include/common/ clean, but this part seems reasonably noncontroversial.
2014-04-26 14:14:28 -04:00
Expand palloc/pg_malloc API for more type safety This adds additional variants of palloc, pg_malloc, etc. that encapsulate common usage patterns and provide more type safety. Specifically, this adds palloc_object(), palloc_array(), and repalloc_array(), which take the type name of the object to be allocated as its first argument and cast the return as a pointer to that type. There are also palloc0_object() and palloc0_array() variants for initializing with zero, and pg_malloc_*() variants of all of the above. Inspired by the talloc library. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/bb755632-2a43-d523-36f8-a1e7a389a907@enterprisedb.com
2022-09-12 02:31:56 -04:00
#define palloc_object(type) ((type *) palloc(sizeof(type)))
#define palloc0_object(type) ((type *) palloc0(sizeof(type)))
Make palloc_array() and friends safe against integer overflow. Sufficiently large "count" arguments could result in undetected overflow, causing the allocated memory chunk to be much smaller than what the caller will subsequently write into it. This is unlikely to be a hazard with 64-bit size_t but can sometimes happen on 32-bit builds, primarily where a function allocates workspace that's significantly larger than its input data. Rather than trying to patch the at-risk callers piecemeal, let's just redefine these macros so that they always check. To do that, move the longstanding add_size() and mul_size() functions into palloc.h and mcxt.c, and adjust them to not be specific to shared-memory allocation. Then invent palloc_mul(), palloc0_mul(), palloc_mul_extended() to use these functions. Actually, the latter use inlined copies to save one function call. repalloc_array() gets similar treatment. I didn't bother trying to inline the calls for repalloc0_array() though. In v14 and v15, this also adds repalloc_extended(), which previously was only available in v16 and up. We need copies of all this in fe_memutils.[hc] as well, since that module also provides palloc_array() etc. Reported-by: Xint Code Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com> Backpatch-through: 14 Security: CVE-2026-6473
2026-05-11 08:13:48 -04:00
#define palloc_array(type, count) ((type *) palloc_mul(sizeof(type), count))
#define palloc0_array(type, count) ((type *) palloc0_mul(sizeof(type), count))
#define palloc_array_extended(type, count, flags) ((type *) palloc_mul_extended(sizeof(type), count, flags))
#define repalloc_array(pointer, type, count) ((type *) repalloc_mul(pointer, sizeof(type), count))
Expand palloc/pg_malloc API for more type safety This adds additional variants of palloc, pg_malloc, etc. that encapsulate common usage patterns and provide more type safety. Specifically, this adds palloc_object(), palloc_array(), and repalloc_array(), which take the type name of the object to be allocated as its first argument and cast the return as a pointer to that type. There are also palloc0_object() and palloc0_array() variants for initializing with zero, and pg_malloc_*() variants of all of the above. Inspired by the talloc library. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://www.postgresql.org/message-id/flat/bb755632-2a43-d523-36f8-a1e7a389a907@enterprisedb.com
2022-09-12 02:31:56 -04:00
Don't #include utils/palloc.h in common/fe_memutils.h. This breaks the principle that common/ ought not depend on anything in the server, not only code-wise but in the headers. The only arguable advantage is avoidance of duplication of half a dozen extern declarations, and even that is rather dubious, considering that the previous coding was wrong about which declarations to duplicate: it exposed pnstrdup() to frontend code even though no such function is provided in fe_memutils.c. On the same principle, don't #include utils/memutils.h in the frontend build of psprintf.c. This requires duplicating the definition of MaxAllocSize, but that seems fine to me: there's no a-priori reason why frontend code should use the same size limit as the backend anyway. In passing, clean up some rather odd layout and ordering choices that were imposed on palloc.h to reduce the number of #ifdefs required by the previous approach. Per gripe from Christoph Berg. There's still more work to do to make include/common/ clean, but this part seems reasonably noncontroversial.
2014-04-26 14:14:28 -04:00
/* sprintf into a palloc'd buffer --- these are in psprintf.c */
extern char *psprintf(const char *fmt,...) pg_attribute_printf(1, 2);
extern size_t pvsnprintf(char *buf, size_t len, const char *fmt, va_list args) pg_attribute_printf(3, 0);
Create libpgcommon, and move pg_malloc et al to it libpgcommon is a new static library to allow sharing code among the various frontend programs and backend; this lets us eliminate duplicate implementations of common routines. We avoid libpgport, because that's intended as a place for porting issues; per discussion, it seems better to keep them separate. The first use case, and the only implemented by this patch, is pg_malloc and friends, which many frontend programs were already using. At the same time, we can use this to provide palloc emulation functions for the frontend; this way, some palloc-using files in the backend can also be used by the frontend cleanly. To do this, we change palloc() in the backend to be a function instead of a macro on top of MemoryContextAlloc(). This was previously believed to cause loss of performance, but this implementation has been tweaked by Tom and Andres so that on modern compilers it provides a slight improvement over the previous one. This lets us clean up some places that were already with localized hacks. Most of the pg_malloc/palloc changes in this patch were authored by Andres Freund. Zoltán Böszörményi also independently provided a form of that. libpgcommon infrastructure was authored by Álvaro.
2013-02-12 08:33:40 -05:00
#endif /* FE_MEMUTILS_H */
Reference in a new issue Copy permalink