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 e
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 (pgsql-ha
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
Andres Freund 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 anyway,
>> if th
On 2014-06-14 15:48:52 -0400, Tom Lane wrote:
> Andres Freund 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 co
Andres Freund 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 possible to write a
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 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.
>
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 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 allocations in mainline cases,
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 chec
On 2014-06-14 16:57:33 -0400, Tom Lane wrote:
> Alvaro Herrera 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 cat
Andres Freund 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 every last corne
Andres Freund wrote:
> On 2014-06-14 16:57:33 -0400, Tom Lane wrote:
> > Alvaro Herrera 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-sec
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 d
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 view
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": "pu
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:
https://wiki.postgresql.org/wiki/Atomic
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":
On Thu, Jun 12, 2014 at 9:31 AM, Gurjeet Singh wrote:
>
> I don't have intimate knowledge of recovery but I think the above
> assessment of recovery's operations holds true. If you still think
> this is a concern, can you please provide a bit firm example using
> which I can visualize the problem
22 matches
Mail list logo
