public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Steve Midgley <[email protected]>
Cc: Kirmo Uusitalo <[email protected]>
Cc: Samed YILDIRIM <[email protected]>
Cc: [email protected]
Subject: Re: Postgresql long transaction support
Date: Wed, 14 Dec 2022 16:13:32 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAJexoSJ2M=S5p21jzzxyy97yhNFLOmqjZaR3G+6Dp5iZpA9ang@mail.gmail.com>
References: <CAH2dGSOY+8amTEE12_WkYkPs17=Y0Cy1dbQ+bsvhmBB6cFSRmw@mail.gmail.com>
	<CAAo1mb=fgrfDzP-+5-0i7tDQiWUphZc-Pw5eGNzp7mQ+spOsgA@mail.gmail.com>
	<CAH2dGSPW4jVzB1fLwNpZiaL3u1BBsZYACTRzerMy-RnpprMk-A@mail.gmail.com>
	<CAJexoSJ2M=S5p21jzzxyy97yhNFLOmqjZaR3G+6Dp5iZpA9ang@mail.gmail.com>

Steve Midgley <[email protected]> writes:
> This seems pretty complex to address at any layer! But it would be a useful
> feature for some situations, for sure. It seems like the approach taken by
> Ruby/Rails and similar frameworks for "db migrations" might have some
> useful design patterns for you. Each transaction has a link to its future
> and past transaction. If the system wants to traverse from "migration 6 to
> migration 3" and the DB is currently at migration 6 (stored a version
> number in the db itself), it runs the exit function to downgrade to
> migration 5, then runs the logic for migration 5, then runs the downgrade
> to 4, etc.

> It can be slow, as implemented, but it allows you to attach logic to every
> step forward and backward in time that ensures you can handle even
> structure changes in the tables, etc (as well as changing lookup values in
> tables, etc).

> Might be worth considering as a design model?

If you end up building things that way, PG's "extensions" could be a
useful way to package it.  What Steve is calling a "migration" corresponds
to an extension version, and you can provide scripts to go in either
direction between versions.

			regards, tom lane

view thread (5+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Postgresql long transaction support
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox