Log Message:
---
Fix possible corruption of AfterTriggerEventLists in subtransaction rollback.
afterTriggerInvokeEvents failed to adjust events->tailfree when truncating
the last chunk of an event list. This could result in the data being
"de-truncated" by afterTriggerRestoreEventList dur
Log Message:
---
Fix possible corruption of AfterTriggerEventLists in subtransaction rollback.
afterTriggerInvokeEvents failed to adjust events->tailfree when truncating
the last chunk of an event list. This could result in the data being
"de-truncated" by afterTriggerRestoreEventList dur
Log Message:
---
Fix possible corruption of AfterTriggerEventLists in subtransaction rollback.
afterTriggerInvokeEvents failed to adjust events->tailfree when truncating
the last chunk of an event list. This could result in the data being
"de-truncated" by afterTriggerRestoreEventList dur
Log Message:
---
Allocate local buffers in a context of their own, rather than dumping them
into TopMemoryContext. This makes no functional difference, but makes it
easier to see what the space is being used for in MemoryContextStats dumps.
Per a recent example in which I was surprised by
Log Message:
---
Allocate local buffers in a context of their own, rather than dumping them
into TopMemoryContext. This makes no functional difference, but makes it
easier to see what the space is being used for in MemoryContextStats dumps.
Per a recent example in which I was surprised by
Log Message:
---
Revert patch to coerce 'unknown' type parameters in the backend. As Tom
pointed out, it would need a 2nd pass after the whole query is processed to
correctly check that an unknown Param is coerced to the same target type
everywhere. Adding the 2nd pass would add a lot more
Log Message:
---
Revert patch to coerce 'unknown' type parameters in the backend. As Tom
pointed out, it would need a 2nd pass after the whole query is processed to
correctly check that an unknown Param is coerced to the same target type
everywhere. Adding the 2nd pass would add a lot more
Log Message:
---
Revert patch to coerce 'unknown' type parameters in the backend. As Tom
pointed out, it would need a 2nd pass after the whole query is processed to
correctly check that an unknown Param is coerced to the same target type
everywhere. Adding the 2nd pass would add a lot more
Log Message:
---
Be a bit less cavalier with both the code and the comment for UNKNOWN fix.
Modified Files:
--
pgsql/src/pl/plpgsql/src:
pl_exec.c (r1.264 -> r1.265)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/pl/plpgsql/src/pl_exec.c?r1=1.264&r2=1.
Log Message:
---
Be a bit less cavalier with both the code and the comment for UNKNOWN fix.
Tags:
REL9_0_STABLE
Modified Files:
--
pgsql/src/pl/plpgsql/src:
pl_exec.c (r1.261.2.2 -> r1.261.2.3)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/pl/pl
Log Message:
---
Be a bit less cavalier with both the code and the comment for UNKNOWN fix.
Tags:
REL8_4_STABLE
Modified Files:
--
pgsql/src/pl/plpgsql/src:
pl_exec.c (r1.244.2.8 -> r1.244.2.9)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/pl/pl
Log Message:
---
Keep exec_simple_check_plan() from thinking "SELECT foo INTO bar" is simple.
It's not clear if this situation can occur in plpgsql other than via the
EXECUTE USING case Heikki illustrated, which I will shortly close off.
However, ignoring the intoClause if it's there is su
Log Message:
---
Keep exec_simple_check_plan() from thinking "SELECT foo INTO bar" is simple.
It's not clear if this situation can occur in plpgsql other than via the
EXECUTE USING case Heikki illustrated, which I will shortly close off.
However, ignoring the intoClause if it's there is su
Log Message:
---
Keep exec_simple_check_plan() from thinking "SELECT foo INTO bar" is simple.
It's not clear if this situation can occur in plpgsql other than via the
EXECUTE USING case Heikki illustrated, which I will shortly close off.
However, ignoring the intoClause if it's there is su
Log Message:
---
Keep exec_simple_check_plan() from thinking "SELECT foo INTO bar" is simple.
It's not clear if this situation can occur in plpgsql other than via the
EXECUTE USING case Heikki illustrated, which I will shortly close off.
However, ignoring the intoClause if it's there is su
Log Message:
---
Allow USING and INTO clauses of plpgsql's EXECUTE to appear in either order.
Aside from being more forgiving, this prevents a rather surprising misbehavior
when the "wrong" order was used: the old code didn't throw a syntax error,
but absorbed the INTO clause into the last
Log Message:
---
Allow USING and INTO clauses of plpgsql's EXECUTE to appear in either order.
Aside from being more forgiving, this prevents a rather surprising misbehavior
when the "wrong" order was used: the old code didn't throw a syntax error,
but absorbed the INTO clause into the last
Log Message:
---
Allow USING and INTO clauses of plpgsql's EXECUTE to appear in either order.
Aside from being more forgiving, this prevents a rather surprising misbehavior
when the "wrong" order was used: the old code didn't throw a syntax error,
but absorbed the INTO clause into the last
Log Message:
---
Bring some sanity to the trace_recovery_messages code and docs.
Per gripe from Fujii Masao, though this is not exactly his proposed patch.
Categorize as DEVELOPER_OPTIONS and set context PGC_SIGHUP, as per Fujii,
but set the default to LOG because higher values aren't reall
Log Message:
---
Bring some sanity to the trace_recovery_messages code and docs.
Per gripe from Fujii Masao, though this is not exactly his proposed patch.
Categorize as DEVELOPER_OPTIONS and set context PGC_SIGHUP, as per Fujii,
but set the default to LOG because higher values aren't reall
Log Message:
---
Remove the isLocalBuf argument from ReadBuffer_common.
Since an SMgrRelation now knows whether or not the underlying relation is
temporary, there's no point in also passing that information via an
additional argument.
Modified Files:
--
pgsql/src/backend/s
21 matches
Mail list logo
