On 2019-Feb-11, Tom Lane wrote:
> I've pushed this now. I made one additional change, which was to fix
> things so that if both an INTERNAL and an EXTENSION dependency exist,
> the first loop will reliably complain about the EXTENSION dependency.
> It only takes one more if-test to do that now
On Mon, Feb 11, 2019 at 11:46 AM Tom Lane wrote:
> I think we're done with this thread, though I still need to look at
> the problem I complained of in <26527.1549572...@sss.pgh.pa.us>.
Right, we're done with this thread now. Thanks again!
--
Peter Geoghegan
I've pushed this now. I made one additional change, which was to fix
things so that if both an INTERNAL and an EXTENSION dependency exist,
the first loop will reliably complain about the EXTENSION dependency.
It only takes one more if-test to do that now that we're postponing
the error report
On 2019-Feb-10, Tom Lane wrote:
> Alvaro Herrera writes:
> > If we disregard the scenario were people downgrade across minor
> > versions, it's likely possible to produce SQL queries to transform from
> > the old arrangement to the new one, and include those in release notes
> > or a wiki page;
Alvaro Herrera writes:
> On 2019-Feb-10, Peter Geoghegan wrote:
>> On Sun, Feb 10, 2019 at 8:13 AM Tom Lane wrote:
>>> Just to be be clear, my inclination is to do nothing about this in v11.
>>> It's not apparent to me that any fix is possible given the v11 dependency
>>> data, at least not
On 2019-Feb-10, Peter Geoghegan wrote:
> On Sun, Feb 10, 2019 at 8:13 AM Tom Lane wrote:
> > Just to be be clear, my inclination is to do nothing about this in v11.
> > It's not apparent to me that any fix is possible given the v11 dependency
> > data, at least not without downsides that'd
Alvaro Herrera writes:
> On 2019-Feb-10, Tom Lane wrote:
>> Primary and secondary partition dependencies behave identically
>> except that the primary dependency is preferred for use in error
>> messages; hence, a partition-dependent object should have one
>> primary partition dependency and one
On 2019-Feb-10, Tom Lane wrote:
>Primary and secondary partition dependencies behave identically
>except that the primary dependency is preferred for use in error
>messages; hence, a partition-dependent object should have one
>primary partition dependency and one
On Sun, Feb 10, 2019 at 11:34 AM Tom Lane wrote:
> After looking closer, I find that it's valid SGML to collapse the two
> items into one entry
I'll have to remember that detail -- seems like it'll come in handy again.
>
> DEPENDENCY_PARTITION_PRI
> (P)
>
Peter Geoghegan writes:
> I think that the wording for this example needs to be tweaked.
> Other than that, looks good to me.
After looking closer, I find that it's valid SGML to collapse the two
items into one entry, so how about:
DEPENDENCY_PARTITION_PRI
(P)
On Sun, Feb 10, 2019 at 8:50 AM Tom Lane wrote:
> >>> [ invent separate primary and secondary partition dependencies? ]
> Here's a version of the patch that does it that way.
Now that I see separate DEPENDENCY_PARTITION_PRI and
DEPENDENCY_PARTITION_SEC dependency types, I agree that it's
On Sun, Feb 10, 2019 at 8:13 AM Tom Lane wrote:
> How about this comment text?
>
> /*
> * The current target object should have been added to
> * targetObjects while processing the owning object; but it
> * probably got only the
I wrote:
> Peter Geoghegan writes:
>>> [ invent separate primary and secondary partition dependencies? ]
>> I lean towards changing these on HEAD, ...
> Me too.
Here's a version of the patch that does it that way.
regards, tom lane
diff --git
Peter Geoghegan writes:
> On Fri, Feb 8, 2019 at 8:15 AM Tom Lane wrote:
>> * The other such issue is a pre-existing bug, which maybe we ought to
>> back-patch, though I can't recall seeing any field reports that seem
>> to match it: after recursing to an internal/extension dependency,
>> we
On 2019-Feb-09, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2019-Feb-09, Tom Lane wrote:
> >> Uh-huh. And what happens after DETACH PARTITION ... are you going to run
> >> around and recreate these triggers?
>
> > Yep, that's there too.
>
> OK, then I guess it's fine.
Thanks for
Alvaro Herrera writes:
> On 2019-Feb-09, Tom Lane wrote:
>> Uh-huh. And what happens after DETACH PARTITION ... are you going to run
>> around and recreate these triggers?
> Yep, that's there too.
OK, then I guess it's fine.
regards, tom lane
On 2019-Feb-09, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2019-Feb-09, Tom Lane wrote:
> >> Oh ... then why don't we go ahead and get rid of the constraint entry,
> >> too?
>
> > Because each partition has its own pg_constraint entry. (Otherwise
> > there's no place to put the column
Alvaro Herrera writes:
> On 2019-Feb-09, Tom Lane wrote:
>> Oh ... then why don't we go ahead and get rid of the constraint entry,
>> too?
> Because each partition has its own pg_constraint entry. (Otherwise
> there's no place to put the column numbers into -- they can differ from
> partition
On 2019-Feb-09, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2019-Feb-09, Tom Lane wrote:
> >> Well, the question that's begged here is exactly why it's okay to
> >> remove the trigger and dependency link despite the fact that the
> >> constraint needs it. I suppose the answer is that we'll
Alvaro Herrera writes:
> On 2019-Feb-09, Tom Lane wrote:
>> Well, the question that's begged here is exactly why it's okay to remove
>> the trigger and dependency link despite the fact that the constraint needs
>> it. I suppose the answer is that we'll subsequently insert a new trigger
>>
On 2019-Feb-09, Alvaro Herrera wrote:
> I'll put this in the comment.
Attached.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
diff --git a/src/backend/commands/tablecmds.c b/src/backend/commands/tablecmds.c
On Sun, Feb 10, 2019 at 2:13 AM Tom Lane wrote:
>
> Amit Langote writes:
> > Reading Tom's reply to my email, I wondered if performDeletion won't
> > do more than what the code is already doing (except calling the right
> > trigger deletion function which the current code doesn't), because the
>
On 2019-Feb-09, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2019-Feb-09, Tom Lane wrote:
> >> I think you're doing it to get rid of the INTERNAL dependency so that
> >> deletion won't recurse across that, but why is that a good idea? Needs
> >> a comment at least.
>
> > Yeah, it's deleting
Amit Langote writes:
> Reading Tom's reply to my email, I wondered if performDeletion won't
> do more than what the code is already doing (except calling the right
> trigger deletion function which the current code doesn't), because the
> trigger in question is an internal trigger without any
Alvaro Herrera writes:
> On 2019-Feb-09, Tom Lane wrote:
>> I think you're doing it to get rid of the INTERNAL dependency so that
>> deletion won't recurse across that, but why is that a good idea? Needs
>> a comment at least.
> Yeah, it's deleting the INTERNAL dependency, because otherwise the
On Sun, Feb 10, 2019 at 1:50 AM Alvaro Herrera wrote:
> On 2019-Feb-09, Tom Lane wrote:
> > Alvaro Herrera writes:
> > > On 2019-Feb-09, Tom Lane wrote:
> > >> No, that's still the back end of the deletion machinery, and in
> > >> particular
> > >> it would fail to clean pg_depend entries for
On 2019-Feb-09, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2019-Feb-09, Tom Lane wrote:
> >> No, that's still the back end of the deletion machinery, and in particular
> >> it would fail to clean pg_depend entries for the trigger. Going in by the
> >> front door would use
Alvaro Herrera writes:
> On 2019-Feb-09, Tom Lane wrote:
>> No, that's still the back end of the deletion machinery, and in particular
>> it would fail to clean pg_depend entries for the trigger. Going in by the
>> front door would use performDeletion(). (See deleteOneObject() to get
>> an idea
On 2019-Feb-09, Tom Lane wrote:
> Amit Langote writes:
> > On Sat, Feb 9, 2019 at 9:41 AM Tom Lane wrote:
> >> +1. The best solution would presumably be to go through the normal
> >> object deletion mechanism; though possibly there's a reason that
> >> won't work given you're already inside
Amit Langote writes:
> On Sat, Feb 9, 2019 at 9:41 AM Tom Lane wrote:
>> +1. The best solution would presumably be to go through the normal
>> object deletion mechanism; though possibly there's a reason that
>> won't work given you're already inside some other DDL.
> Maybe:
> -
On Sat, Feb 9, 2019 at 9:41 AM Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2019-Feb-08, Tom Lane wrote:
> >> Also, I came across some coding in CloneFkReferencing() that looks fishy
> >> as hell: that function imagines that it can delete an existing trigger
> >> with nothing more than a
Alvaro Herrera writes:
> On 2019-Feb-08, Tom Lane wrote:
>> Also, I came across some coding in CloneFkReferencing() that looks fishy
>> as hell: that function imagines that it can delete an existing trigger
>> with nothing more than a summary CatalogTupleDelete(). I didn't do
>> anything about
On Fri, Feb 8, 2019 at 8:15 AM Tom Lane wrote:
> > * Partition dependencies are not singletons. They should *always*
> > come in pairs, one on the parent partitioned object (partitioned
> > index, constraint, trigger, etc) and one on the child partitioned
> > table.
> > * Partition dependencies
On 2019-Feb-08, Tom Lane wrote:
> Also, I came across some coding in CloneFkReferencing() that looks fishy
> as hell: that function imagines that it can delete an existing trigger
> with nothing more than a summary CatalogTupleDelete(). I didn't do
> anything about that here, but if it's not
I wrote:
> I believe that we need to establish the following principles:
>
> * The terminology "internal_auto" is disastrously unhelpful.
> I propose calling these things "partition" dependencies instead.
>
> * Partition dependencies are not singletons. They should *always*
> come in pairs, one
On Thu, Feb 7, 2019 at 7:35 PM Tom Lane wrote:
> I have a working patch now, but I think I'm too tired to explain it,
> so I'm going to post it tomorrow instead. It's a big enough change
> that it might be advisable for someone to review it --- are you
> interested?
I'd be happy to review it.
Peter Geoghegan writes:
> On Wed, Feb 6, 2019 at 9:15 PM Tom Lane wrote:
>> I have a mostly-working patch along these lines that I hope to
>> finish up and post tomorrow.
> Do you think that you'll end up pushing the HEAD-only fix shortly?
I have a working patch now, but I think I'm too tired
On Wed, Feb 6, 2019 at 9:15 PM Tom Lane wrote:
> I have a mostly-working patch along these lines that I hope to
> finish up and post tomorrow.
Do you think that you'll end up pushing the HEAD-only fix shortly? It
would be nice to avoid immediate bitrot of an upcoming revision of the
nbtree patch
I wrote:
>>> I've got much of the code for it already (in the wreckage of my failed
>>> attempts), so I'll go back and finish that up.
So I've been poking at that for most of the day, and I've despaired of
being able to fix this in v11. The problem is that somebody was rolling
dice while
Peter Geoghegan writes:
> On Tue, Feb 5, 2019 at 2:08 PM Tom Lane wrote:
>> I've got much of the code for it already (in the wreckage of my failed
>> attempts), so I'll go back and finish that up. I was just waiting to see
>> how loudly people would howl about using object type as a condition
On Tue, Feb 5, 2019 at 2:08 PM Tom Lane wrote:
> I've got much of the code for it already (in the wreckage of my failed
> attempts), so I'll go back and finish that up. I was just waiting to see
> how loudly people would howl about using object type as a condition for
> figuring out what a
Alvaro Herrera writes:
> On 2019-Jan-29, Tom Lane wrote:
>> It strikes me however that we can stick with the existing catalog contents
>> by making this definition: of the INTERNAL_AUTO dependencies of a given
>> object, the "true owner" to be reported in errors is the dependency
>> that is of
On 2019-Jan-29, Tom Lane wrote:
> The closest I could get to solving it along the original lines
> went like this:
>
> * In addition, we support INTERNAL_AUTO dependencies, which alter the
> * rules for this. If the target has both INTERNAL and INTERNAL_AUTO
> * dependencies,
Alvaro Herrera writes:
> On 2019-Jan-18, Peter Geoghegan wrote:
>> I thought that your ALTER OBJECT DEPENDS ON EXTENSION example made the
>> case for fixing that directly inarguable. I'm slightly surprised that
>> you're not fully convinced of this already. Have I missed some
>> subtlety?
> I
On Fri, Jan 18, 2019 at 4:06 PM Peter Geoghegan wrote:
> > * Objects-to-drop output from DROP ROLE is still unstable. I suppose
> > this would be fixed by also doing sorting in that code path, but
> > I've not looked into it.
>
> The nbtree patch is not dependent on doing better here, since the
On 2019-Jan-18, Peter Geoghegan wrote:
> On Fri, Jan 18, 2019 at 3:34 PM Tom Lane wrote:
> > * There is still instability in which object you get told to drop
> > when attempting to drop an index partition or trigger, as a consequence
> > of there being two possible DEPENDENCY_INTERNAL_AUTO
On Fri, Jan 18, 2019 at 4:24 PM Tom Lane wrote:
> > I thought that your ALTER OBJECT DEPENDS ON EXTENSION example made the
> > case for fixing that directly inarguable. I'm slightly surprised that
> > you're not fully convinced of this already. Have I missed some
> > subtlety?
>
> It's clear that
Peter Geoghegan writes:
> On Fri, Jan 18, 2019 at 3:34 PM Tom Lane wrote:
>> Attached is a draft patch to sort objects before the recursion step
>> in findDependentObjects. I found that sorting by descending OID is
>> really the right thing; if we sort by increasing OID then we get a
>> whole
On Fri, Jan 18, 2019 at 3:34 PM Tom Lane wrote:
> I think the tiebreaker idea is just a hack, because it'd only be stable
> to the extent that the added tiebreaker values are stable, and they
> wouldn't be very much so if the counter state is only kept per-backend.
>
> Attached is a draft patch
Peter Geoghegan writes:
> On Thu, Jan 17, 2019 at 4:40 PM Tom Lane wrote:
>> We're going to stick all these items into an ObjectAddress array anyway,
>> so at worst it'd be 2X growth, most likely a lot less since we'd only
>> be sorting one level of dependency at a time.
> It sounds like we
On Thu, Jan 17, 2019 at 5:09 PM Peter Geoghegan wrote:
> In the kludgey patch that I posted, the 4-byte value is manufactured
> artificially within a backend in descending order. That may have a
> slight advantage over object oid, even after the pg_depend correctness
> issues are addressed. A
On Thu, Jan 17, 2019 at 4:40 PM Tom Lane wrote:
> Yeah, that's the policy we've followed so far, but I remain concerned
> about its effects on the regression tests. There are a lot of places
> where we print full DROP CASCADE output because "it hasn't failed yet".
> I fear every one of those is
Peter Geoghegan writes:
> On Thu, Jan 17, 2019 at 12:42 PM Tom Lane wrote:
>> Now, perhaps we should make such stability a design goal, as it'd allow
>> us to get rid of some "suppress the cascade outputs" hacks in the
>> regression tests. But it's a bit of a new feature. If we wanted to
>> do
On Thu, Jan 17, 2019 at 12:42 PM Tom Lane wrote:
> So I poked around for awhile with running the regression tests under
> ignore_system_indexes. There seem to be a number of issues involved
> here. To a significant extent, they aren't bugs, at least not according
> to the original conception of
I wrote:
> Also, I am suspicious that this implementation fails on point 3
> anyway ... If nothing else, it looks like ALTER OBJECT DEPENDS ON
> EXTENSION can be used to attach a random dependency to just
> about anything.
Yup:
regression=# drop table if exists idxpart cascade;
DROP TABLE
On Thu, Jan 17, 2019 at 3:20 PM Tom Lane wrote:
> Alvaro Herrera writes:
> > There is a symmetry to these that led me to have the same kind of
> > dependency from the index partition to the other two.
>
> It's symmetric as long as you suppose that the above are the only
> requirements. However,
Alvaro Herrera writes:
> On 2019-Jan-17, Tom Lane wrote:
>> Hm. Still, I can't believe that it's appropriate for a partitioned index
>> to have exactly the same kind of dependency on the master index as it
>> does on the associated table.
> So there are three necessary features:
> * The
On 2019-Jan-17, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2019-Jan-17, Tom Lane wrote:
> >> DEPENDENCY_INTERNAL_AUTO, however, broke this completely, as the code
> >> has no hesitation about making multiple entries of that kind. After
> >> rather cursorily looking at that code, I'm
Alvaro Herrera writes:
> On 2019-Jan-17, Tom Lane wrote:
>> DEPENDENCY_INTERNAL_AUTO, however, broke this completely, as the code
>> has no hesitation about making multiple entries of that kind. After
>> rather cursorily looking at that code, I'm leaning to the position
>> that
On 2019-Jan-17, Tom Lane wrote:
> DEPENDENCY_INTERNAL_AUTO, however, broke this completely, as the code
> has no hesitation about making multiple entries of that kind. After
> rather cursorily looking at that code, I'm leaning to the position
> that DEPENDENCY_INTERNAL_AUTO is broken-by-design
I wrote:
> I propose that we handle this case by adding a new DEPFLAG_IS_SUBOBJECT
> flag to the column object's flags, denoting that we know the whole table
> will be dropped later. The only effect of this flag is to suppress
> reporting of the column object in reportDependentObjects.
Here's a
Peter Geoghegan writes:
> On Tue, Dec 18, 2018 at 2:26 PM Tom Lane wrote:
>> Hm, that definitely leads me to feel that we've got bug(s) in
>> dependency.c. I'll take a look sometime soon.
> Thanks!
> I'm greatly relieved that I probably won't have to become an expert on
> dependency.c after
On Tue, Dec 18, 2018 at 2:26 PM Tom Lane wrote:
> Hm, that definitely leads me to feel that we've got bug(s) in
> dependency.c. I'll take a look sometime soon.
Thanks!
I'm greatly relieved that I probably won't have to become an expert on
dependency.c after all. :-)
--
Peter Geoghegan
Peter Geoghegan writes:
> On Tue, Dec 18, 2018 at 2:11 PM Tom Lane wrote:
>> Do you mean "same" output, or "sane" output? I'd certainly expect
>> the latter.
> I meant sane.
> --ignore-system-indexes leads to slightly wrong answers in a number of
> the diagnostic messages run by the
On Tue, Dec 18, 2018 at 2:11 PM Tom Lane wrote:
> > Interesting.
> > Note that if the standard that we're going to hold a solution to here
> > is "must produce sane output with --ignore-system-indexes", then my
> > solution will not meet that standard.
>
> Do you mean "same" output, or "sane"
Peter Geoghegan writes:
> On Tue, Dec 18, 2018 at 1:20 PM Alvaro Herrera
> wrote:
>> I can reproduce the
>> reported problem without your patch by using that flag. Here's a
>> recipe:
> Interesting.
> Note that if the standard that we're going to hold a solution to here
> is "must produce
On Tue, Dec 18, 2018 at 1:20 PM Alvaro Herrera wrote:
>
> On 2018-Dec-18, Peter Geoghegan wrote:
> Hmm, interesting. I wonder if this is just a case of never testing this
> code under "postgres --ignore-system-indexes".
I suppose that you could say that. The regression tests will fail at
many
On 2018-Dec-18, Peter Geoghegan wrote:
> Well, you also have cases like this:
>
> --- a/contrib/earthdistance/expected/earthdistance.out
> +++ b/contrib/earthdistance/expected/earthdistance.out
> @@ -972,7 +972,7 @@ SELECT abs(cube_distance(ll_to_earth(-30,-90),
> '(0)'::cube) / earth() - 1) <
>
On Tue, Dec 18, 2018 at 10:26 AM Tom Lane wrote:
> Yeah, I've been wondering about that as well. The original intention
> for dependency traversal was that it'd work independently of the ordering
> of entries in pg_depend. If it's not doing so, I'd call that a bug in
> dependency traversal
On Tue, Dec 18, 2018 at 10:07 AM Alvaro Herrera
wrote:
> Is there any case of this that doesn't involve DEPENDENCY_INTERNAL_AUTO
> entries? I wonder if I just haven't broken the algorithm when
> introducing that, and I worry that we're adding a complicated kludge to
> paper over that problem.
Alvaro Herrera writes:
> On 2018-Nov-05, Peter Geoghegan wrote:
>> I've realized that my patch to make nbtree keys unique by treating
>> heap TID as a tie-breaker attribute must use ASC ordering, for reasons
>> that I won't go into here. Now that I'm not using DESC ordering, there
>> are changes
On 2018-Nov-05, Peter Geoghegan wrote:
> I've realized that my patch to make nbtree keys unique by treating
> heap TID as a tie-breaker attribute must use ASC ordering, for reasons
> that I won't go into here. Now that I'm not using DESC ordering, there
> are changes to a small number of
On Mon, Dec 17, 2018 at 10:52 PM Andrey Lepikhov
wrote:
> I did many tests of your solution inside the 'quick vacuum' strategy [1]
> and the background worker called 'heap cleaner' [2]. I must admit that
> when I use your patch, there is no problem with dependencies.
Cool.
> This patch needs
On 08.12.2018 6:58, Peter Geoghegan wrote:
I have no idea what you mean here. I'm proposing a patch that stops
it being a game of chance, while preserving the existing
slightly-random behavior to the greatest extent possible. I think that
my patch would have stopped that problem altogether.
On Thu, Dec 6, 2018 at 8:52 PM Andrey Lepikhov
wrote:
> I want to say that we need to localize the rules for the order of the
> diagnostic messages as much as possible in dependency.c.
But the issue *isn't* confined to dependency.c, anyway. It bleeds into
a couple of other modules, like
On 06.12.2018 11:52, Peter Geoghegan wrote:
On Wed, Dec 5, 2018 at 10:35 PM Andrey Lepikhov
wrote:
This solution changes pg_depend relation for solve a problem, which
exists only in regression tests. Very rarely it can be in the
partitioning cases. Or is it not?
I don't think it's a
On Wed, Dec 5, 2018 at 10:35 PM Andrey Lepikhov
wrote:
> This solution changes pg_depend relation for solve a problem, which
> exists only in regression tests. Very rarely it can be in the
> partitioning cases. Or is it not?
I don't think it's a matter of how rarely this will happen. We're
On 14.11.2018 11:28, Peter Geoghegan wrote:
We're already relying on the scan order being in reverse chronological
order, so we might as well formalize the dependency. I don't think
that it's possible to sort the pg_depend entries as a way of fixing
the breakage while avoiding storing this extra
On Thu, Nov 15, 2018 at 10:52 AM Robert Haas wrote:
> I think that the solution that you are proposing sorta sucks, but it's
> better than hacking objsubid to do it, which did in fact pass the
> laugh test, in that I laughed when I read it. :-)
Probably a good idea to get another cup of coffee
On Wed, Nov 14, 2018 at 1:28 AM Peter Geoghegan wrote:
> We're already relying on the scan order being in reverse chronological
> order, so we might as well formalize the dependency. I don't think
> that it's possible to sort the pg_depend entries as a way of fixing
> the breakage while avoiding
On Tue, Nov 13, 2018 at 1:29 PM Peter Geoghegan wrote:
> A solution does occur to me that I'm kind of embarrassed to suggest,
> but that would nonetheless probably do the job:
> Why not vary the objsubid value among entries that don't use it
> anyway, so that they have a negative integer
On Mon, Nov 5, 2018 at 7:46 PM Andrey Lepikhov
wrote:
> Problem No. 1 will be amplified with new asynchronous operations,
> background workers and distributing query execution. It is not problem
> of DBMS. The solution is change the tests: include sorting of query
> results, sorting of system
In my opinion, your patch detected three problems:
1. Unsteady order of query results/system messages ('DROP...CASCADE'
detects it).
2. Hide info about a child object dropping ('drop cascades to 62
other objects' detects it).
3. Possible non-informative messages about dependencies ('drop
83 matches
Mail list logo
