After giving somebody advice, for the Nth time, to install a
memory-consumption ulimit instead of leaving his database to the tender
mercies of the Linux OOM killer, it occurred to me to wonder why we don't
provide a built-in feature for that, comparable to the ulimit -c max
option that already
Heikki Linnakangas wrote:
Here's a new version, rebased against master. No other changes.
This is missing xlogrecord.h ...
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list
As I mentioned awhile ago, I'm thinking about implementing the
SQL-standard construct
UPDATE foo SET ..., (a,b,...) = (SELECT x,y,...), ...
I've run into a rather nasty problem, which is how does this interact
with expansion of NEW references in ON UPDATE rules? For example,
suppose foo
Hi,
On 2014-06-14 15:35:33 -0400, Tom Lane wrote:
Given that ON UPDATE rules are close to being a deprecated feature,
it doesn't seem appropriate to work harder than this; and frankly
I don't see how we could avoid multiple sub-select evaluations anyway,
if the NEW references are in WHERE or
Andres Freund and...@2ndquadrant.com writes:
Hi,
On 2014-06-14 15:35:33 -0400, Tom Lane wrote:
Given that ON UPDATE rules are close to being a deprecated feature,
it doesn't seem appropriate to work harder than this; and frankly
I don't see how we could avoid multiple sub-select evaluations
On 2014-06-14 15:48:52 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
Hi,
On 2014-06-14 15:35:33 -0400, Tom Lane wrote:
Given that ON UPDATE rules are close to being a deprecated feature,
it doesn't seem appropriate to work harder than this; and frankly
I don't see
Andres Freund and...@2ndquadrant.com writes:
On 2014-06-14 15:48:52 -0400, Tom Lane wrote:
Well, it wouldn't be unsafe (barring volatile functions in the UPDATE,
which are unsafe already). It might be slow, but that's probably better
than failing.
I forgot the details, but IIRC it's
I noticed that HEAD crashes at startup with assertions disabled and
WAL_DEBUG turned on:
#2 0x007af987 in ExceptionalCondition (
conditionName=conditionName@entry=0x974448 !(CritSectionCount == 0 ||
(CurrentMemoryContext) == ErrorContext || (MyAuxProcType ==
CheckpointerProcess)),
On 2014-06-14 16:44:10 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-06-14 15:48:52 -0400, Tom Lane wrote:
Well, it wouldn't be unsafe (barring volatile functions in the UPDATE,
which are unsafe already). It might be slow, but that's probably better
than
Alvaro Herrera wrote:
I noticed that HEAD crashes at startup with assertions disabled and
WAL_DEBUG turned on:
I'm using an interim fix by excepting the startup process (see attached
patch), like the current code does for checkpointer, but I guess a more
robust solution should be sought.
Alvaro Herrera alvhe...@2ndquadrant.com writes:
I noticed that HEAD crashes at startup with assertions disabled and
WAL_DEBUG turned on:
I'm beginning to think we're going to have to give up on that
no-pallocs-in-critical-sections Assert. It was useful to catch
unnecessarily-dangerous
On 2014-06-14 16:53:12 -0400, Alvaro Herrera wrote:
Alvaro Herrera wrote:
I noticed that HEAD crashes at startup with assertions disabled and
WAL_DEBUG turned on:
I'm using an interim fix by excepting the startup process (see attached
patch), like the current code does for checkpointer,
On 2014-06-14 16:57:33 -0400, Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
I noticed that HEAD crashes at startup with assertions disabled and
WAL_DEBUG turned on:
I'm beginning to think we're going to have to give up on that
no-pallocs-in-critical-sections Assert. It
Andres Freund and...@2ndquadrant.com writes:
On 2014-06-14 16:57:33 -0400, Tom Lane wrote:
I'm beginning to think we're going to have to give up on that
no-pallocs-in-critical-sections Assert. It was useful to catch
unnecessarily-dangerous allocations in mainline cases, but getting rid
of
Andres Freund wrote:
On 2014-06-14 16:57:33 -0400, Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
I noticed that HEAD crashes at startup with assertions disabled and
WAL_DEBUG turned on:
I'm beginning to think we're going to have to give up on that
Attached is a WIP patch for implementing the capture of delta
relations for a DML statement, in the form of two tuplestores --
one for the old versions and one for the new versions. In the
short term it is intended to make these relations available in
trigger functions, although the patch so far
On 6/14/14, 3:51 PM, Andres Freund wrote:
Hm. But you might as well use a trigger, no? Is anyone likely to
actually be doing such a thing?
I don't think anybody is likely to do such a thing on an actual table,
but INSTEAD OF for views is pretty new. For a long time rules were the
the only way
On 2014-06-14 19:27:03 -0500, Jim Nasby wrote:
On 6/14/14, 3:51 PM, Andres Freund wrote:
Hm. But you might as well use a trigger, no? Is anyone likely to
actually be doing such a thing?
I don't think anybody is likely to do such a thing on an actual table,
but INSTEAD OF for views is pretty
On 2/6/14, 11:20 AM, Alvaro Herrera wrote:
NOTICE: JSON blob: {
definition: [
{
clause: owned,
fmt: OWNED BY %{owner}D,
owner: {
attrname: a,
objname: t1,
schemaname: public
}
Hi,
At this year developer's meeting we'd discussed the atomics abstraction
which is necessary for some future improvements. We'd concluded that a
overview over the hardware capabilities of the supported platforms would
be helpful. I've started with that at:
Jim Nasby wrote:
On 2/6/14, 11:20 AM, Alvaro Herrera wrote:
NOTICE: JSON blob: {
definition: [
{
clause: owned,
fmt: OWNED BY %{owner}D,
owner: {
attrname: a,
objname: t1,
schemaname:
21 matches
Mail list logo
