[HACKERS] Built-in support for a memory consumption ulimit?
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 exists in pg_ctl. A reasonably low-overhead way to do that would be to define it as something a backend process sets once at startup, if told to by a GUC. The GUC could possibly be PGC_BACKEND level though I'm not sure if we want unprivileged users messing with it. Thoughts? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] WAL format and API changes (9.5)
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-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] UPDATE SET (a,b,c) = (SELECT ...) versus rules
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 has a rule ON UPDATE DO ALSO INSERT INTO foolog VALUES (new.a, new.b, ...); The existing implementation relies on being able to pull expressions for individual fields' new values out of the UPDATE targetlist; but there is no independent expression for the new value of a here. Worse yet, the NEW references might be in WHERE quals, or some other place outside the targetlist of the rule query, which pretty much breaks the implementation I'd sketched earlier. The best that I think is reasonable to do in such cases is to pull out a separate copy of the sub-select for each actual NEW reference in a rule query. So the example above would give rise to an expanded rule query along the lines of INSERT INTO foolog VALUES ( (SELECT x as a, y as b, ...).a, (SELECT x as a, y as b, ...).b, ... ); which would work, but it would re-evaluate the sub-select more times than the user might be hoping. (Of course, if there are volatile functions in the sub-select, he's screwed, but that's not a new problem with rules.) 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 other odd places. Another possible answer is to just throw a not implemented error; but that doesn't seem terribly helpful, and I think it wouldn't save a lot of code anyway. Thoughts? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] UPDATE SET (a,b,c) = (SELECT ...) versus rules
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 other odd places. Another possible answer is to just throw a not implemented error; but that doesn't seem terribly helpful, and I think it wouldn't save a lot of code anyway. I vote for throwing an error. This would make the rules about how rules can be used safely even more confusing. I don't think anybody would be helped by that. If somebody wrote a halfway sane ON UPDATE rule (i.e. calling a function to do the dirty work) it wouldn't be sane anymore if somebody starts to use the new syntax... Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] UPDATE SET (a,b,c) = (SELECT ...) versus rules
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 anyway, if the NEW references are in WHERE or other odd places. Another possible answer is to just throw a not implemented error; but that doesn't seem terribly helpful, and I think it wouldn't save a lot of code anyway. I vote for throwing an error. This would make the rules about how rules can be used safely even more confusing. I don't think anybody would be helped by that. If somebody wrote a halfway sane ON UPDATE rule (i.e. calling a function to do the dirty work) it wouldn't be sane anymore if somebody starts to use the new syntax... 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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] UPDATE SET (a,b,c) = (SELECT ...) versus rules
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 how we could avoid multiple sub-select evaluations anyway, if the NEW references are in WHERE or other odd places. Another possible answer is to just throw a not implemented error; but that doesn't seem terribly helpful, and I think it wouldn't save a lot of code anyway. I vote for throwing an error. This would make the rules about how rules can be used safely even more confusing. I don't think anybody would be helped by that. If somebody wrote a halfway sane ON UPDATE rule (i.e. calling a function to do the dirty work) it wouldn't be sane anymore if somebody starts to use the new syntax... 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 ON UPDATE ... DO INSTEAD rule that's safe wrt multiple evaluations today by calling a function passing in the old pkey and NEW. At least I believed so at some point in the past :P Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] UPDATE SET (a,b,c) = (SELECT ...) versus rules
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 possible to write a ON UPDATE ... DO INSTEAD rule that's safe wrt multiple evaluations today by calling a function passing in the old pkey and NEW. At least I believed so at some point in the past :P Hm. But you might as well use a trigger, no? Is anyone likely to actually be doing such a thing? It's conceivable that we could optimize the special case of NEW.*, especially if it appears in the rule query's targetlist. But it's trouble I don't really care to undertake ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] crash with assertions and WAL_DEBUG
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)), errorType=errorType@entry=0x7e9bec FailedAssertion, fileName=fileName@entry=0x974150 /pgsql/source/minmax/src/backend/utils/mmgr/mcxt.c, lineNumber=lineNumber@entry=670) at /pgsql/source/minmax/src/backend/utils/error/assert.c:54 #3 0x007d2080 in palloc (size=1024) at /pgsql/source/minmax/src/backend/utils/mmgr/mcxt.c:670 #4 0x005f3abe in initStringInfo (str=str@entry=0x7fff11f68a80) at /pgsql/source/minmax/src/backend/lib/stringinfo.c:50 #5 0x004f42ca in XLogInsert (rmid=48 '0', rmid@entry=0 '\000', info=optimized out, info@entry=0 '\000', rdata=rdata@entry=0x7fff11f68d30) at /pgsql/source/minmax/src/backend/access/transam/xlog.c:1262 #6 0x004f4f17 in CreateCheckPoint (flags=flags@entry=6) at /pgsql/source/minmax/src/backend/access/transam/xlog.c:8197 #7 0x004f8079 in StartupXLOG () at /pgsql/source/minmax/src/backend/access/transam/xlog.c:7097 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. I find it strange that nobody has seen this before. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services diff --git a/src/backend/utils/mmgr/mcxt.c b/src/backend/utils/mmgr/mcxt.c index e83e76d..bf3c540 100644 --- a/src/backend/utils/mmgr/mcxt.c +++ b/src/backend/utils/mmgr/mcxt.c @@ -68,7 +68,7 @@ static void MemoryContextStatsInternal(MemoryContext context, int level); */ #define AssertNotInCriticalSection(context) \ Assert(CritSectionCount == 0 || (context) == ErrorContext || \ - AmCheckpointerProcess()) + AmCheckpointerProcess() || AmStartupProcess()) /* * EXPORTED ROUTINES * -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] UPDATE SET (a,b,c) = (SELECT ...) versus rules
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 failing. I forgot the details, but IIRC it's possible to write a ON UPDATE ... DO INSTEAD rule that's safe wrt multiple evaluations today by calling a function passing in the old pkey and NEW. At least I believed so at some point in the past :P 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 to implement updatable views (including any form of row level security). It's conceivable that we could optimize the special case of NEW.*, especially if it appears in the rule query's targetlist. But it's trouble I don't really care to undertake ... I think it's fine to just throw an error. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] crash with assertions and WAL_DEBUG
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. Spoke too soon. This also causes trouble when any process inserts an xlog record and tries to print it, of course, not just startup. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] crash with assertions and WAL_DEBUG
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 allocations in mainline cases, but getting rid of every last corner-case palloc is looking to be, if not impossible, at least a lot more trouble than it is worth. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] crash with assertions and WAL_DEBUG
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, but I guess a more robust solution should be sought. Spoke too soon. This also causes trouble when any process inserts an xlog record and tries to print it, of course, not just startup. I personally think we should just remove WAL_DEBUG, but I guess I won't convince others of that... I think for now the least bad solution is to add a #ifndef WAL_DEBUG around that assertion. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] crash with assertions and WAL_DEBUG
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 was useful to catch unnecessarily-dangerous allocations in mainline cases, but getting rid of every last corner-case palloc is looking to be, if not impossible, at least a lot more trouble than it is worth. I think we at least need to remove it from 9.4. We shouldn't release with an assertion that still regularly triggers in more or less 'harmless' situations. I think it might be worthwile to keep it in master to help maintain the rule against allocations in critical sections. And perhaps as a reminder that e.g. the checkpointer is doing bad things... Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] crash with assertions and WAL_DEBUG
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 every last corner-case palloc is looking to be, if not impossible, at least a lot more trouble than it is worth. I think we at least need to remove it from 9.4. We shouldn't release with an assertion that still regularly triggers in more or less 'harmless' situations. Yeah, it's certainly not looking like it's a production-ready check, even bearing in mind that we recommend against enabling asserts in production. I think it might be worthwile to keep it in master to help maintain the rule against allocations in critical sections. And perhaps as a reminder that e.g. the checkpointer is doing bad things... I've looked at the checkpointer issue, and I don't actually think it's particularly unsafe there, mainly because the checkpointer's memory usage is pretty well bounded. I don't like the hacky solution of excepting *all* pallocs in the checkpointer process, though. I wonder whether we could set up some sort of marking of specific pallocs as being considered OK for the purposes of this assert. Another thought: the checkpointer has a guaranteed maximum on the size of the palloc in AbsorbFsyncRequests, viz CheckpointerShmem-max_requests ... maybe we should just make it prealloc that much space and be done. However, I wouldn't bother unless we are committed to keeping the Assert. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] crash with assertions and WAL_DEBUG
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 no-pallocs-in-critical-sections Assert. It was useful to catch unnecessarily-dangerous allocations in mainline cases, but getting rid of every last corner-case palloc is looking to be, if not impossible, at least a lot more trouble than it is worth. I think we at least need to remove it from 9.4. We shouldn't release with an assertion that still regularly triggers in more or less 'harmless' situations. Yeah, removing it in 9.4 is likely a good idea -- we have an open item about it in connection with LWLOCK_DEBUG, and now this. Who knows what other debugging features will cause trouble. I think it might be worthwile to keep it in master to help maintain the rule against allocations in critical sections. And perhaps as a reminder that e.g. the checkpointer is doing bad things... I also agree with keeping it in 9.5. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] delta relations in AFTER triggers
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 doesn't touch any PLs
-- it just takes things as far as providing the relations as
tuplestores in the TriggerData structure when appropriate, for the
PLs to pick up from there. It seemed best to get agreement on the
overall approach before digging into all the PLs. This is
implemented only for INSERT, UPDATE, and DELETE since it wasn't
totally clear what the use cases and proper behavior was for other
triggers. Opinions on whether we should try to provide deltas for
other cases, and if so what the semantics are, are welcome.
Once triggers can access this delta data, it will also be used for
incremental maintenance of materialized views, although I don't
want get too sidetracked on any details of that until we have
proven delta data available in triggers. (One step at a time or
we'll never get there.)
I looked at the standard, and initially tried to implement the
standard syntax for this; however, it appeared that the reasons
given for not using standard syntax for the row variables also
apply to the transition relations (the term used by the standard).
There isn't an obvious way to tie that in to all the PLs we
support. It could be done, but it seems like it would intolerably
ugly, and more fragile than what we have done so far.
Some things which I *did* follow from the standard: these new
relations are only allowed within AFTER triggers, but are available
in both AFTER STATEMENT and AFTER ROW triggers. That is, an AFTER
UPDATE ... FOR EACH ROW trigger could use both the OLD and NEW row
variables as well as the delta relations (under whatever names we
pick). That probably won't be used very often, but I can imagine
some cases where it might be useful. I expect that these will
normally be used in FOR EACH STATEMENT triggers.
There are a couple things I would really like to get settled in
this round of review, so things don't need to be refactored in
major ways later:
(1) My first impulse was to capture this delta data in the form of
tuplestores of just TIDs, and fetching the tuples themselves from
the heap on reference. In earlier discussions others have argued
for using tuplestores of the actual rows themselves. I have taken
that advice here, but still don't feel 100% convinced. What I am
convinced of is that I don't want to write a lot of code based on
that decision and only then have people weigh in on the side of how
I had planned to do it in the first place. I hate it when that
happens.
(2) Do we want to just pick names for these in the PLs rather than
using the standard syntax? Implementing the standard syntax seemed
to require three new (unreserved) keywords, changes to the catalogs
to store the chosen relations names, and some way to tie the
specified relation names in to the various PLs. The way I have
gone here just adds two new fields to the TriggerData structure and
leaves it to each PL how to deal with that. Failure to do anything
in a PL just leaves it at the status quo with no real harm done --
it just won't have the new delta relations available.
Of course, any other comments on the approach taken or how it can
be improved are welcome.
At this point the only testing is that make check-world completes
without problems. If we can agree on this part of it I will look
at the PLs, and create regression tests. I would probably submit
each PL implementation as a separate patch.
I was surprised that the patch to this point was so small:
5 files changed, 170 insertions(+), 19 deletions(-)
Hopefully that's not due to having missed something.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company*** a/doc/src/sgml/ref/create_table.sgml
--- b/doc/src/sgml/ref/create_table.sgml
***
*** 1062,1067 CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } | UNLOGGED ] TABLE [ IF NOT EXI
--- 1062,1079
/listitem
/varlistentry
+varlistentry
+ termliteralgenerate_deltas/literal (typeboolean/type)/term
+ listitem
+ para
+ Declare that a table generates delta relations when modified. This
+ allows literalAFTER/ triggers to reference the set of rows modified
+ by a statement. See
+ xref linkend=sql-createtrigger for details.
+ /para
+ /listitem
+/varlistentry
+
/variablelist
/refsect2
*** a/src/backend/access/common/reloptions.c
--- b/src/backend/access/common/reloptions.c
***
*** 85,90 static relopt_bool boolRelOpts[] =
--- 85,98
},
false
},
+ {
+ {
+ generate_deltas,
+ Relation generates delta relations for use by AFTER triggers,
+ RELOPT_KIND_HEAP
+ },
+ false
+ },
/* list terminator */
{{NULL}}
};
Re: [HACKERS] UPDATE SET (a,b,c) = (SELECT ...) versus rules
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 to implement updatable views (including any form of row level security). It's conceivable that we could optimize the special case of NEW.*, especially if it appears in the rule query's targetlist. But it's trouble I don't really care to undertake ... I think it's fine to just throw an error. If there was a showstopper to moving forward with rule support I think it'd be OK to throw our hands in the air, but that's not the case here. I'm in favor of doing the substitution, just like we do today with RULES, warts and all. We already warn people against using rules and that they're very difficult to get correct, so I don't think double eval of an expression should surprise anyone. -- Jim C. Nasby, Data Architect j...@nasby.net 512.569.9461 (cell) http://jim.nasby.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] UPDATE SET (a,b,c) = (SELECT ...) versus rules
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 new. For a long time rules were the the only way to implement updatable views (including any form of row level security). It's conceivable that we could optimize the special case of NEW.*, especially if it appears in the rule query's targetlist. But it's trouble I don't really care to undertake ... I think it's fine to just throw an error. If there was a showstopper to moving forward with rule support I think it'd be OK to throw our hands in the air, but that's not the case here. I'm in favor of doing the substitution, just like we do today with RULES, warts and all. We already warn people against using rules and that they're very difficult to get correct, so I don't think double eval of an expression should surprise anyone. It makes a formerly correct/safe rule unsafe. That's a showstopper from my POV. There's *STILL* no proper warning against rules in the manual, btw. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Add CREATE support to event triggers
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
}
}
],
fmt: ALTER SEQUENCE %{identity}D %{definition: }s,
identity: {
objname: t1_a_seq,
schemaname: public
}
}
NOTICE: expanded: ALTER SEQUENCE public.t1_a_seq OWNED BY public.t1.a
Apologies if this has been discussed and I missed it, but shouldn't part of the
JSON be a field that indicates what command is being run? It doesn't seem wise
to conflate detecting what the command is with the overall format string.
--
Jim C. Nasby, Data Architect j...@nasby.net
512.569.9461 (cell) http://jim.nasby.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Atomics hardware support table supported architectures
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/Atomics Does somebody want other columns in there? From that and previous discussions (e.g. http://archives.postgresql.org/message-id/20131013004658.GG4056218%40alap2.anarazel.de ) I think we should definitely remove some platforms: 1) VAX. Production ceased 1997. We've never supported OpenVMS, just netbsd (and probably openbsd) 2) m32r. Our implementation depends on an *unmerged* glibc header. The website was dead for several *years*, even after the restore patches can't be downloaded anymore (404). 3) sparcv8: Last released model 1997. 4) i386: Support dropped from windows 98 (yes, really), linux, openbsd (yes, really), netbsd (yes, really). No code changes needed. 5) pa-risc. 6) armv-v5 Note that this is *not* a requirement for the atomics abstraction - it now has a fallback to spinlocks if atomics aren't available. But I don't think we should add code for practically irrelevant and likely not working setups. That'd get us to the situation that all supported platforms support atomic add cmpxchg. Just as a recap: The reason I want the atomics abstraction is so we can implement improvements like http://www.postgresql.org/message-id/20130926225545.gb26...@awork2.anarazel.de and quite a few others sanely. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Add CREATE support to event triggers
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: public
}
}
],
fmt: ALTER SEQUENCE %{identity}D %{definition: }s,
identity: {
objname: t1_a_seq,
schemaname: public
}
}
NOTICE: expanded: ALTER SEQUENCE public.t1_a_seq OWNED BY public.t1.a
Apologies if this has been discussed and I missed it, but shouldn't part of
the JSON be a field that indicates what command is being run? It doesn't seem
wise to conflate detecting what the command is with the overall format string.
That's reported as a separate field by the
pg_event_trigger_creation_commands function.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
