This thread has stalled, and from the discussions there isn't consencus on how
to proceed (if at all?), so I'm marking this Returned with Feedback. If the
discussion and work picks up again then it can be resubmitted.
--
Daniel Gustafsson https://vmware.com/
On Fri, Sep 24, 2021 at 10:42:36AM -0300, Alvaro Herrera wrote:
> I think the most reasonable action is to push the patch in
> https://postgr.es/m/20201123193957.GA21810@alvherre.pgsql to all
> branches, closing the immediate hole, and we can see about the xact-hook
> stuff (when we have it) to
On 2021-Sep-24, Jaime Casanova wrote:
> Do you plan to work on this for this CF?
I think the most reasonable action is to push the patch in
https://postgr.es/m/20201123193957.GA21810@alvherre.pgsql to all
branches, closing the immediate hole, and we can see about the xact-hook
stuff (when we
On Wed, Mar 10, 2021 at 08:24:50AM -0500, David Steele wrote:
> On 12/1/20 5:25 PM, Justin Pryzby wrote:
> > On Tue, Dec 01, 2020 at 03:57:24PM -0300, Alvaro Herrera wrote:
> >
> > > > Another idea is if perform_work_item() were responsible for discarding
> > > > relations which disappear.
On 12/1/20 5:25 PM, Justin Pryzby wrote:
On Tue, Dec 01, 2020 at 03:57:24PM -0300, Alvaro Herrera wrote:
Another idea is if perform_work_item() were responsible for discarding
relations which disappear. Currently it does this, which is racy since it
holds no lock.
That has the property that
On Tue, Dec 01, 2020 at 03:57:24PM -0300, Alvaro Herrera wrote:
> On 2020-Dec-01, Justin Pryzby wrote:
>
> > This was an idea I made up - I don't know any of the details of this, but if
> > you give a hint I could look at it more. There'd (still) be a race window,
> > but
> > I think that's ok.
On 2020-Dec-01, Justin Pryzby wrote:
> This was an idea I made up - I don't know any of the details of this, but if
> you give a hint I could look at it more. There'd (still) be a race window,
> but
> I think that's ok.
See CommitTransaction() and friends, where AtEOXact_on_commit_actions()
On Tue, Dec 01, 2020 at 11:07:30AM -0300, Alvaro Herrera wrote:
> > Should it be done in an AtCommit hook or something like that ?
>
> I didn't like this idea much on first read, on extensibility grounds,
> but perhaps it's not so bad because we can generalize it whenever
> there's pressure to
On 2020-Nov-30, Justin Pryzby wrote:
> On Mon, Nov 30, 2020 at 08:47:32PM -0300, Alvaro Herrera wrote:
> > The more I look at this, the less I like it. This would set a precedent
> > that any action that can be initiated from an autovac work-item has a
> > requirement of silently being discarded
On Mon, Nov 30, 2020 at 08:47:32PM -0300, Alvaro Herrera wrote:
> The more I look at this, the less I like it. This would set a precedent
> that any action that can be initiated from an autovac work-item has a
> requirement of silently being discarded when it referenced a
> non-existant relation.
The more I look at this, the less I like it. This would set a precedent
that any action that can be initiated from an autovac work-item has a
requirement of silently being discarded when it referenced a
non-existant relation.
I'd rather have the code that drops the index go through the list of
On Mon, Nov 23, 2020 at 04:39:57PM -0300, Alvaro Herrera wrote:
> I think this formulation (attached v3) has fewer moving parts.
>
> However, now that I did that, I wonder if this is really the best
> approach to solve this problem. Maybe instead of doing this at the BRIN
> level, it should be
I think this formulation (attached v3) has fewer moving parts.
However, now that I did that, I wonder if this is really the best
approach to solve this problem. Maybe instead of doing this at the BRIN
level, it should be handled at the autovac level, by having the worker
copy the work-item to
On Thu, Nov 19, 2020 at 03:15:21PM -0300, Alvaro Herrera wrote:
> On 2020-Nov-19, Justin Pryzby wrote:
>
> > On Fri, Nov 13, 2020 at 12:11:21PM -0600, Justin Pryzby wrote:
>
> > > Your patch didn't actually say "try_relation_open", so didn't work.
> > > But it does works if I do that, and close
On 2020-Nov-19, Justin Pryzby wrote:
> On Fri, Nov 13, 2020 at 12:11:21PM -0600, Justin Pryzby wrote:
> > Your patch didn't actually say "try_relation_open", so didn't work.
> > But it does works if I do that, and close the table.
Thanks for fixing and testing.
> That patch broke the case that
On Fri, Nov 13, 2020 at 12:11:21PM -0600, Justin Pryzby wrote:
> On Fri, Nov 13, 2020 at 01:39:31PM -0300, Alvaro Herrera wrote:
> > On 2020-Nov-13, Justin Pryzby wrote:
> >
> > > I saw a bunch of these in my logs:
> > >
> > > log_time | 2020-10-25 22:59:45.619-07
> > > database |
> > > left
b) [0x55acf2bab59b]
postgres: autovacuum worker pryzbyj(brin_summarize_range+0x8f)
[0x55acf2b5b5bf]
postgres: autovacuum worker pryzbyj(DirectFunctionCall2Coll+0x62)
[0x55acf2f40372]
...
--
Justin
>From e08c6d3e2b10964633904ff247e70330077d31b4 Mon Sep 17 00:00:00 2001
On 2020-Nov-13, Justin Pryzby wrote:
> I saw a bunch of these in my logs:
>
> log_time | 2020-10-25 22:59:45.619-07
> database |
> left | could not open relation with OID 292103095
> left | processing work entry for relation
> "ts.child.alarms_202010_alarm_clear_time_idx"
>
> Those
I saw a bunch of these in my logs:
log_time | 2020-10-25 22:59:45.619-07
database |
left | could not open relation with OID 292103095
left | processing work entry for relation
"ts.child.alarms_202010_alarm_clear_time_idx"
Those happen following a REINDEX job on that index.
I think
19 matches
Mail list logo
