> For the complete documentation index, see [llms.txt](https://docs.postgresql.tw/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.postgresql.tw/15/server-programming/server-programming-interface/spi-memory.md).

# 47.3. Memory Management

## 47.3. Memory Management

[SPI\_palloc](/15/server-programming/server-programming-interface/spi-memory/spi-spi-palloc.md) — allocate memory in the upper executor context

[SPI\_repalloc](/15/server-programming/server-programming-interface/spi-memory/spi-realloc.md) — reallocate memory in the upper executor context

[SPI\_pfree](/15/server-programming/server-programming-interface/spi-memory/spi-spi-pfree.md) — free memory in the upper executor context

[SPI\_copytuple](/15/server-programming/server-programming-interface/spi-memory/spi-spi-copytuple.md) — make a copy of a row in the upper executor context

[SPI\_returntuple](/15/server-programming/server-programming-interface/spi-memory/spi-spi-returntuple.md) — prepare to return a tuple as a Datum

[SPI\_modifytuple](/15/server-programming/server-programming-interface/spi-memory/spi-spi-modifytuple.md) — create a row by replacing selected fields of a given row

[SPI\_freetuple](/15/server-programming/server-programming-interface/spi-memory/spi-spi-freetuple.md) — free a row allocated in the upper executor context

[SPI\_freetuptable](/15/server-programming/server-programming-interface/spi-memory/spi-spi-freetupletable.md) — free a row set created by `SPI_execute` or a similar function

[SPI\_freeplan](/15/server-programming/server-programming-interface/spi-memory/spi-spi-freeplan.md) — free a previously saved prepared statement

PostgreSQL allocates memory within *memory contexts*, which provide a convenient method of managing allocations made in many different places that need to live for differing amounts of time. Destroying a context releases all the memory that was allocated in it. Thus, it is not necessary to keep track of individual objects to avoid memory leaks; instead only a relatively small number of contexts have to be managed. `palloc` and related functions allocate memory from the “current” context.

`SPI_connect` creates a new memory context and makes it current. `SPI_finish` restores the previous current memory context and destroys the context created by `SPI_connect`. These actions ensure that transient memory allocations made inside your C function are reclaimed at C function exit, avoiding memory leakage.

However, if your C function needs to return an object in allocated memory (such as a value of a pass-by-reference data type), you cannot allocate that memory using `palloc`, at least not while you are connected to SPI. If you try, the object will be deallocated by `SPI_finish`, and your C function will not work reliably. To solve this problem, use `SPI_palloc` to allocate memory for your return object. `SPI_palloc` allocates memory in the “upper executor context”, that is, the memory context that was current when `SPI_connect` was called, which is precisely the right context for a value returned from your C function. Several of the other utility functions described in this section also return objects created in the upper executor context.

When `SPI_connect` is called, the private context of the C function, which is created by `SPI_connect`, is made the current context. All allocations made by `palloc`, `repalloc`, or SPI utility functions (except as described in this section) are made in this context. When a C function disconnects from the SPI manager (via `SPI_finish`) the current context is restored to the upper executor context, and all allocations made in the C function memory context are freed and cannot be used any more.

***

原文：[PostgreSQL 15.19 Documentation](/15/server-programming/server-programming-interface/spi-memory.md)（英文原文，待翻譯）


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.postgresql.tw/15/server-programming/server-programming-interface/spi-memory.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.