Hi,
Short summary:
If I run a single INSERT against an updateable VIEW on top of a partitioned
table, it's run against all the tables/partitions. I'd expect that with UPDATE
and DELETE, but not with INSERT. Result is multiple rows for a single INSERT,
one for each table.
I ran into this on 9
On Jul 24, 2013, at 2:37 PM, Terje Elde wrote:
> Short summary:
> If I run a single INSERT against an updateable VIEW on top of a partitioned
> table, it's run against all the tables/partitions. I'd expect that with
> UPDATE and DELETE, but not with INSERT. Result
Hi,
Short summary:
If I run a single INSERT against an updateable VIEW on top of a partitioned
table, it's run against all the tables/partitions. I'd expect that with UPDATE
and DELETE, but not with INSERT. Result is multiple rows for a single INSERT,
one for each table.
I ran into this on 9
On 8. aug. 2013, at 14:39, Tom Lane wrote:
> This doesn't seem like a remarkably good idea from here, mainly because
> entries in pg_hba.conf are critically order-dependent. Dropping random
> entries into a conf.d-like directory could produce unexpected results
> --- and in this case, "unexpected
On Aug 30, 2013, at 11:23 PM, Tom Lane wrote:
> Sounds like a bug all right, but I'm not convinced it explains Terje's
> report. The thing this theory doesn't explain is why would Terje be
> having trouble reproducing the failure? Seems like re-running the same
> query ought to produce the same
On Aug 30, 2013, at 10:46 PM, te...@elde.net wrote:
> The following bug has been logged on the website:
That didn't work out too well, rendering-wize.
Sending the explain analyze by email as well, hoping it'll be more readable:
On 30. aug. 2013, at 23:05, Andres Freund wrote:
> No need, found the bug. And I think can build a testcase myself.
Sounds good. :)
Please do let me know if there's anything I can do.
Terje
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscriptio
On Aug 30, 2013, at 11:49 PM, Andres Freund wrote:
> Even better explanation: The merge append is some steps below a LockRows
> node, so the number of rescans might depend on the concurrency because
> we'll do the EvalPlanQual dance on a concurrent row update.
>
> Terje, do you use read committed
On Aug 31, 2013, at 12:22 AM, Tom Lane wrote:
> Or even more to the point, can you apply the just-posted patch and see
> if the problem goes away for you?
Will do.
At our current organic load though, we likely wouldn't get any good
confirmation either way this week.
I'll see if I can set up so
On Oct 11, 2013, at 9:21 AM, Dimitri Fontaine wrote:
> Inter function dependencies is a hard topic indeed. I still would like
> to see some kind of progress being made someday. The general case is
> turing complete tho, because you can use EXECUTE against programatically
> generated SQL.
>
> You
10 matches
Mail list logo
