Re: [HACKERS] Assertion failure in REL9_5_STABLE

On 2016-08-10 11:01 PM, Alvaro Herrera wrote: Oh, I see ... so there's an update chain, and you're updating a earlier tuple. But the later tuple has a multixact and one of the members is the current transaction. I wonder how can you lock a tuple that's not the latest, where that update chain wa

Re: [HACKERS] Assertion failure in REL9_5_STABLE

On 2016-08-11 12:09 AM, Alvaro Herrera wrote: BTW this is not a regression, right? It's been broken all along. Or am I mistaken? You're probably right. I just hadn't realized I could run our app against 9.5 with --enable-cassert until last week. .m -- Sent via pgsql-hackers mailing lis

Re: [HACKERS] Assertion failure in REL9_5_STABLE

On 11/08/16 8:48 AM, Michael Paquier wrote: On Thu, Aug 11, 2016 at 8:09 AM, Marko Tiikkaja wrote: On 2016-08-11 12:09 AM, Alvaro Herrera wrote: BTW this is not a regression, right? It's been broken all along. Or am I mistaken? You're probably right. I just hadn't reali

Re: [HACKERS] Writeable CTE patch

m doing is wrong? 4. As previously noted, the changes to avoid using es_result_relation_info are broken and need to be dropped from the patch. Done. I kept the logic for result relations to allow nested ModifyTable nodes, but I don't think it ever did the right thing with EvalPlanQual() and nested nodes

Re: [HACKERS] Writeable CTE patch

ently sure how hard that would be, though; it might not be a practical answer. I'm trying to avoid doing this, at least for now. Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.or

Re: [HACKERS] Writeable CTE patch

code which uses the active snapshot stack. Any ideas? Regards, Marko Tiikkaja -- 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] Aggregate ORDER BY patch

having this seems like a useful feature in some cases. Although the DISTINCT ON syntax would have a bit more resemblance on the existing syntax, I'd still like to see agg(distinct x order by x,y). Just my $0.02. Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailing list (pgsql-h

Re: [HACKERS] alpha3 bundled -- please verify

figure out what was wrong. Is this documented somewhere? Regards, Marko Tiikkaja -- 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] Writeable CTEs

the actual problem in the original post. The problem only affects INSERT, UDPATE and DELETE where you are actually counting affected rows (i.e. PQcmdTuples(), not PQntuples()) so the this example would work as expected. Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailing list (pgs

Re: [HACKERS] Testing with concurrent sessions

d what we're reaching for here. What I think would be most useful would be to interleave statements between transactions, not just randomly fire psql sessions and hope for race conditions. Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or

Re: [HACKERS] Testing with concurrent sessions

in order using asynchronous connections. Regards, Marko Tiikkaja -- 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] Testing with concurrent sessions

On 2010-01-07 18:13 +0200, Marko Tiikkaja wrote: I had a similar syntax in mind, but instead of using threads, just execute the file in order using asynchronous connections. I completely failed to make the point here which was to somehow mark which statements will (or, should) block. So here

Re: [HACKERS] Review of Writeable CTE Patch

of it and has a fix ready. > > So it sounds like we should expect an updated patch shortly? Yes. I'm adding more comments and documentation, expect a patch within a couple of days. Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or

Re: [HACKERS] Review of Writeable CTE Patch

new function RegisterSnapshotCopy instead? Sounds reasonable. Regards, Marko Tiikkaja -- 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] Review: listagg aggregate

t; b) when second parameter is stable, then store it and use it as constant. > > I prefer a) Someone might have a perfectly good use case for using different delimiters. I don't think it's a good idea to be artificially limiting what you can and can't do. Regards, Marko Tiikk

[HACKERS] UPDATE .. RETURNING OLD.*

, and bar was 0, so I couldn't put bar != 0 into the WHERE clause. This time I got around it by using RETURNING bar and checking that it was 1 on the client side, but I can come up with other cases where you can't do that. Comments? Regards, Marko Tiikkaja -- Sent via pgsql-hacke

[HACKERS] Progress on Writeable CTEs

Hi, I've looked at implementing writeable CTEs on top of my DML node patch (repo here: git://git.postgresql.org/git/writeable_cte.git ) and encountered a few conundrums. You can see what I've done in the "actually_write" branch of that repo. - Currently we only store the OIDs of the result rela

Re: [HACKERS] Using results from INSERT ... RETURNING

ues that I'm aware of. There are a few spots that could be prettier, but I have no good ideas for them. I'll try to provide some more feedback on this after I look it over some more. Thanks! Regards, Marko Tiikkaja -- 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] Using results from INSERT ... RETURNING

e and submit an updated patch in a couple of days. Regards, Marko Tiikkaja -- 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] Using results from INSERT ... RETURNING

Robert Haas wrote: Can you at least take a stab at it? We can fix your grammar, but guessing what's going on without documentation is hard. With some help from David Fetter, I took another try at it. I hope someone finds this helpful. I'm happy to answer any questions. Rega

Re: [HACKERS] Using results from INSERT ... RETURNING

x27;t accomplish anything, but supporting writeable CTEs will be a lot easier as seen in the git repo David pointed you to. Regards, Marko Tiikkaja -- 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] Using results from INSERT ... RETURNING

ould be executed separately. I'm not saying that we don't want to provide the means to do this, but writeable CTEs alone aren't meant to handle this. Regards, Marko Tiikkaja -- 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] Using results from INSERT ... RETURNING

t;project". I'm going to go ahead and mark this Ready for Committer. Thanks for your patience. Thanks for reviewing! Regards, Marko Tiikkaja -- 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] Using results from INSERT ... RETURNING

INTO foo WITH t AS ( DELETE FROM bar RETURNING * ) SELECT * FROM t; which is probably the most useful thing you could do with this feature. Am I misinterpreting what you said? Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

Re: [HACKERS] Using results from INSERT ... RETURNING

/UPDATE/DELETE works as expected here. Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Writeable CTEs and side effects

the main execution tree and execute it using the data we now have inside the CTEs. This way we can avoid storing useless rows in memory without unexpected behaviour and caveats. Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

Re: [HACKERS] Writeable CTEs and side effects

Jaime Casanova wrote: On Wed, Oct 7, 2009 at 4:08 PM, Marko Tiikkaja wrote: 1) WITH t AS (UPDATE foo SET bar = bar+1 RETURNING *) SELECT * FROM t LIMIT 1; What's problematic here is that only 1 row is read from the CTE, meaning also that only one row is updated whic

Re: [HACKERS] Writeable CTEs and side effects

Jaime Casanova wrote: On Wed, Oct 7, 2009 at 4:20 PM, Marko Tiikkaja wrote: Right. This is exactly what I'm trying to do, except I think we could easily optimize this case and store only the first processed row inside the CTE. why? we don't should be thinking in optimizations in

Re: [HACKERS] Writeable CTEs and side effects

ain after CommitFest. Agreed. Does this have any impact on the pending DML-node patch? Not really. This could be done without the patch, but we can use far more of the existing CTE code with the patch. Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

Re: [HACKERS] Writeable CTEs and side effects

RNING clause if the CTE isn't referenced, so you could write this as: WITH t1 AS (UPDATE foo SET bar=bar+1), t2 AS (UPDATE baz SET bar=bar+1) VALUES(true); Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to you

Re: [HACKERS] Using results from INSERT ... RETURNING

Tom Lane wrote: Does anyone have a problem with the ModifyTable suggestion, or a better idea? Lacking a better idea, +1 for ModifyTable from me. Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] Using results from INSERT ... RETURNING

I'm a bit tired of that topic right now. I'm sorry, it didn't occur to me that this is part of this patch, but I made these changes in my writeable CTE repo, see http://git.postgresql.org/gitweb?p=writeable_cte.git;a=commitdiff;h=41ad3d24af845c67a3866e0946129cf9809fe7e9 Regards, Ma

Re: [HACKERS] Using results from INSERT ... RETURNING

hinking that this should be part of the writeable CTE patch. Regards, Marko Tiikkaja -- 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] Using results from INSERT ... RETURNING

taking it out now seemed like moving backward. Ok. 2. Move actual execution of (non-deferred) AFTER triggers inside ModifyTuple. This might be a good idea in order to have the most consistent results for a series of WITH queries, but I'm not sure. This definitely seems like the best opti

Re: [HACKERS] Writeable CTEs and side effects

ITH t AS (DELETE FROM foo RETURNING id) UPDATE bar SET foo_id = NULL FROM t WHERE t.id = bar.foo_id; Did I misunderstand something here? Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Writeable CTEs, again

ughly yet, but I don't see any obvious problems. I'd appreciate any input. Regards, Marko Tiikkaja diff --git a/doc/src/sgml/queries.sgml b/doc/src/sgml/queries.sgml index b2741bc..111ed6a 100644 --- a/doc/src/sgml/queries.sgml +++ b/doc/src/sgml/queries.sgml @@ -1499,7 +1499,7 @@ SELEC

Re: [HACKERS] WIP: push AFTER-trigger execution into ModifyTable node

ome cases we could inline the CTE for this to actually be a quite significant performance benefit, so I'm not too fancy about the approach you're suggesting. Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subs

Re: [HACKERS] WIP: push AFTER-trigger execution into ModifyTable node

T or an INSERT. Also, UPDATEs and DELETEs inside CTEs can't have the same result relations. Whether or not we want to break the expected(?) behaviour for statement-level triggers, I have no opinion to way or another. Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailing list (pgsql-hack

Re: [HACKERS] WIP: push AFTER-trigger execution into ModifyTable node

but I don't think it matters because those trigger calls would have a different snapshot, right? Or am I missing something? Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mail

Re: [HACKERS] WIP: push AFTER-trigger execution into ModifyTable node

n't read all the output of a portal", but at least for cursors we'd have to first execute ModifyTable nodes. Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Query::targetList and RETURNING

#x27;ll be glad to do it if people think this is useful. Thoughts? Regards, Marko Tiikkaja *** a/src/backend/executor/functions.c --- b/src/backend/executor/functions.c *** *** 1070,1078 check_sql_fn_retval(Oid func_id, Oid rettype, List *queryTreeList,

Re: [HACKERS] Query::targetList and RETURNING

oint B. Right, but this way you only have to special-case in grouping_planner(), and targetList always means the same thing. Regards, Marko Tiikkaja -- 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] Query::targetList and RETURNING

Tom Lane wrote: Marko Tiikkaja writes: Tom Lane wrote: This doesn't really seem like a good idea from here. You're changing a decision that has something like twenty years' standing in the code, for no real gain. AFAICS this is just going to move the special cases from poi

Re: [HACKERS] Query::targetList and RETURNING

Tom Lane wrote: Marko Tiikkaja writes: I wouldn't care for this at all, but with things the way they are right now, the writeable CTE patch has to do quite a few of these: [ shrug... ] How many is "quite a few"? In a quick search for existing references to targetList in

[HACKERS] Writeable CTE patch

's something to think about. Regards, Marko Tiikkaja diff --git a/doc/src/sgml/queries.sgml b/doc/src/sgml/queries.sgml index b2741bc..3aa7da5 100644 --- a/doc/src/sgml/queries.sgml +++ b/doc/src/sgml/queries.sgml @@ -1499,7 +1499,7 @@ SELECT 3, 'three'; SELECT select_list FROM

Re: [HACKERS] Writeable CTE patch

I wrote: Attached is the latest version of this patch. Here's that same patch in context diff format. Sorry for the noise. Regards, Marko Tiikkaja *** a/doc/src/sgml/queries.sgml --- b/doc/src/sgml/queries.sgml *** *** 1499,1505 SELECT 3, 'three'; SEL

Re: [HACKERS] Writeable CTE patch

op-level statement or not. I'll send an updated patch in a couple of days. Regards, Marko Tiikkaja -- 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] Syntax for partitioning

the same Oracle uses, and I think it's nice for the general case, but I think the reversed operator weirdness is a bit too much. Maybe we should use something like PARTITION bar VALUES OPERATOR 0 when the user specifies the operator? Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailin

Re: [HACKERS] Syntax for partitioning

t doesn't sound like a bad idea.. Regards, Marko Tiikkaja -- 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] Writeable CTE patch

#x27;t arise often enough to justify keeping such a wart in the executor. Under the circumstances I'd lean towards this option. Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Using results from INSERT ... RETURNING

Hello. Here's a patch(WIP) that implements INSERT .. RETURNING inside a CTE. Should apply cleanly against CVS head. The INSERT query isn't rewritten so rules and default values don't work. Recursive CTEs don't work either. Regards, Marko Tiikkaja *** a/src/backend/comm

Re: [HACKERS] Using results from INSERT ... RETURNING

slot isn't allocated in InitPlan(). Seems to be one of the many places where the code isn't aware that there can be a non-top-level DML statement. Thanks for testing. Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to you

Re: [HACKERS] Using results from INSERT ... RETURNING

but the idea was that if the DML node has a RETURNING clause, the node returns the projected tuple and ExecutePlan sends it to the DestReceiver. In cases where there is no RETURNING clause, the node would return a dummy tuple. Comments are welcome. Regards, Marko Tiikkaja -- Sent vi

Re: [HACKERS] Using results from INSERT ... RETURNING

On 7/31/2009, "Marko Tiikkaja" wrote: > .. I seem to be having problems with my email client. The patch should be attached this time. Sorry for the noise. Regards, Marko Tiikkaja patch3 Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql

Re: [HACKERS] plpgsql.warn_shadow

variables plpgsql.compile_warnings = 'list'default = 'none' plpgsql.compile_errors = 'list'default = 'none' Only possible values in 9.4 are 'shadow', 'all', 'none' I'm fine with this. I'm starting to think th

Re: [HACKERS] plpgsql.warn_shadow

into 9.4 would be such a good idea. Especially since it's not necessary at all. Regards, Marko Tiikkaja -- 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] plpgsql.warn_shadow

es my issues. Thanks for your work here. Regards, Marko Tiikkaja -- 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] Review: plpgsql.extra_warnings, plpgsql.extra_errors

ero. I'm not sure what exactly you mean by this. If the only allowed values are "none", "variable_shadowing" and "all", how is the behaviour for those going to change if we make it a list for 9.5? Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailin

Re: [HACKERS] pg_dump --pretty-print-views

asking me about this feature for pg_extractor No, the idea was rejected. Regards, Marko Tiikkaja -- 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] Supporting multiple column assignment in UPDATE (9.5 project)

uld be parsed unambiguously, though it's perhaps a bit ugly. Regards, Marko Tiikkaja -- 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] pg_get_viewdefs() indentation considered harmful

quot;; I've switched to using SELECT 1 in EXISTS for this reason, but perhaps other people haven't yet done that.. Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

<    2   3   4   5   6   7