Re: Backfill bgworker Extension?

From: Jeremy Finzel <finzelj(at)gmail(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Backfill bgworker Extension?
Date: 2017-12-17 21:27:54
Message-ID: CAMa1XUiQqpbrUt7oeSd6-URK0UGfMx09SSi-WY5DEpYCQ72scQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Dec 16, 2017 at 8:31 AM Peter Eisentraut <
peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:

> On 12/15/17 23:50, Jeremy Finzel wrote:
> > The common ground is some column in some table needs to be bulk updated.
> > I may not be explaining well, but in our environment we have done
> > hundreds of these using a generic framework to build a backfill. So I’m
> > not sure what you are questioning about the need? We have had to build a
> > worker to accomplish this because it can’t be done as a sql script alone.
>
> I'm trying to identify the independently useful pieces in your use case.
> A background worker to backfill large tables is a very specific use
> case. If instead we had a job/scheduler mechanism and a way to have
> server-side scripts that can control transactions, then that might
> satisfy your requirements as well (I'm not sure), but it would also
> potentially address many other uses.

I follow you now. Yes, I think it probably would. I think it would at
least provide a framework on which to build the tool I want. It would be
great to have a "worker-capable" tool inside postgres than always having to
write external logic to do things like this.

> I’m not sure what you mean by a stored procedure in the background.
> > Since it would not be a single transaction, it doesn’t fit as a stored
> > procedure at least in Postgres when a function is 1 transaction.
>
> In progress: https://commitfest.postgresql.org/16/1360/

Looking forward to this. I think this will help. A stored procedure with
subtransactions could have the logic for the backfill in it, but would
still need an external worker that could retry it in case of failure
especially when things like a server restart happens.

Thanks,
Jeremy

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2017-12-17 22:24:19 Re: [HACKERS] Something for the TODO list: deprecating abstime and friends
Previous Message Robert Haas 2017-12-17 20:29:08 Re: Top-N sorts verses parallelism