Hopefully fixing memory handling issues in ecpglib that Coverity found.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/0cc0507940c1cf4153fc25c8f6f4f75adada86d0
Modified Files
--
src/interfaces/ecpg/ecpglib/execute.c | 37 ++--
Free memory in ecpg bytea regression test.
While not really a problem it's easier to run tools like valgrind against it
when fixed.
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/42ccbe4351e4c0b1ad1684323c2fea79c86ae573
Modified Files
--
src/interfaces
Change lock acquisition order in expand_inherited_rtentry.
Previously, this function acquired locks in the order using
find_all_inheritors(), which locks the children of each table that it
processes in ascending OID order, and which processes the inheritance
hierarchy as a whole in a breadth-first
Add ExecStorePinnedBufferHeapTuple.
This allows to avoid an unnecessary pin/unpin cycle when storing a
tuple in an already pinned buffer into a slot, when the pin isn't
further needed at the call site.
Only a single caller for now (to ensure coverage), but upcoming
patches will increase use of th
Allow to use HeapTupleData embedded in [Buffer]HeapTupleTableSlot.
That avoids having to care about the lifetime of the
HeapTupleHeaderData passed to ExecStore[Buffer]HeapTuple(). That
doesn't make a huge difference for a plain HeapTupleTableSlot, but for
BufferHeapTupleTableSlot it can be a signi
Store table oid and tuple's tid in tuple slots directly.
After the introduction of tuple table slots all table AMs need to
support returning the table oid of the tuple stored in a slot created
by said AM. It does not make sense to re-implement that in every AM,
therefore move handling of table OID
Use slots in trigger infrastructure, except for the actual invocation.
In preparation for abstracting table storage, convert trigger.c to
track tuples in slots. Which also happens to make code calling
triggers simpler.
As the calling interface for triggers themselves is not changed in
this patch,
Fix memory leak when inserting tuple at relation creation for CTAS
The leak has been introduced by 763f2ed which has addressed the problem
for transient tables, and forgot CREATE TABLE AS which shares a similar
logic when receiving a new tuple to store into the newly-created
relation.
Author: Jef
Hi,
On 2019-02-27 04:41:28 +, Andres Freund wrote:
> Use slots in trigger infrastructure, except for the actual invocation.
Andrew, I see that this broke crake's redis_fdw check. I see it actually
fails with an error, rather than fail to build. Could you perhaps enable
generating backtraces?
