Re: Backporting BackgroundPsql

On 01/07/2024 17:11, Pavan Deolasee wrote: H i Daniel, On Mon, Jul 1, 2024 at 1:09 PM Daniel Gustafsson > wrote: > On 29 Jun 2024, at 06:38, Pavan Deolasee mailto:pavan.deola...@gmail.com>> wrote: > Don't we need to add install and uninstall rules for the

Re: Backporting BackgroundPsql

H i Daniel, On Mon, Jul 1, 2024 at 1:09 PM Daniel Gustafsson wrote: > > On 29 Jun 2024, at 06:38, Pavan Deolasee > wrote: > > > Don't we need to add install and uninstall rules for the new module, > like we did in > https://git.postgresql.org/pg/commitdiff/a4c17c86176cfa712f541b81b2a026ae054b27

Re: Backporting BackgroundPsql

> On 29 Jun 2024, at 06:38, Pavan Deolasee wrote: > Don't we need to add install and uninstall rules for the new module, like we > did in > https://git.postgresql.org/pg/commitdiff/a4c17c86176cfa712f541b81b2a026ae054b275e > and > https://git.postgresql.org/pg/commitdiff/7039c7cff6736780c3bbb

Re: Backporting BackgroundPsql

On Thu, Jun 27, 2024 at 10:05 PM Heikki Linnakangas wrote: > > Ok, I pushed commits to backport BackgroundPsql down to v12. I used > "option 2", i.e. I changed background_psql() to return the new > BackgroundPsql object. > > Don't we need to add install and uninstall rules for the new module, lik

Re: Backporting BackgroundPsql

On 26/06/2024 14:54, Robert Haas wrote: On Wed, Jun 26, 2024 at 3:34 AM Heikki Linnakangas wrote: I haven't looked closely at the new PgFFI stuff but +1 on that in general, and it makes sense to backport that once it lands on master. In the meanwhile, I think we should backport BackgroundPsql a

Re: Backporting BackgroundPsql

On Wed, Jun 26, 2024 at 3:34 AM Heikki Linnakangas wrote: > I haven't looked closely at the new PgFFI stuff but +1 on that in > general, and it makes sense to backport that once it lands on master. In > the meanwhile, I think we should backport BackgroundPsql as it is, to > make it possible to bac

Re: Backporting BackgroundPsql

On 26/06/2024 03:25, Michael Paquier wrote: On Wed, Jun 26, 2024 at 02:12:42AM +0200, Alvaro Herrera wrote: FWIW I successfully used the preliminary PqFFI stuff Andrew posted to write a test program for bug #18377, which I think ended up being better than with BackgroundPsql, so I think it's a g

Re: Backporting BackgroundPsql

On Wed, Jun 26, 2024 at 02:12:42AM +0200, Alvaro Herrera wrote: > FWIW I successfully used the preliminary PqFFI stuff Andrew posted to > write a test program for bug #18377, which I think ended up being better > than with BackgroundPsql, so I think it's a good way forward. As for > back-patching

Re: Backporting BackgroundPsql

On 2024-Jun-25, Tom Lane wrote: > Daniel Gustafsson writes: > > However, since Andrew is actively aiming to replace all of this shortly, > > should > > we wait a see where that lands to avoid having to backport another library > > change? > > I would like to see what he comes up with ... but i

Re: Backporting BackgroundPsql

> On 25 Jun 2024, at 22:57, Tom Lane wrote: > > Daniel Gustafsson writes: >> Before pulling any triggers I think >> https://commitfest.postgresql.org/48/4959/ >> should be considered, since Tom found some flaws in the current code around >> how >> timers and timeouts are used. > > That's cert

Re: Backporting BackgroundPsql

Daniel Gustafsson writes: > Before pulling any triggers I think https://commitfest.postgresql.org/48/4959/ > should be considered, since Tom found some flaws in the current code around > how > timers and timeouts are used. That's certainly another issue to consider, but is it really a blocker fo

Re: Backporting BackgroundPsql

> On 25 Jun 2024, at 16:26, Tom Lane wrote: > > Andres Freund writes: >> On 2024-06-25 13:26:23 +0300, Heikki Linnakangas wrote: >>> 1. Write the new test differently on backbranches. Before 664d757531, the >>> test needs to work a lot harder to use the background psql session, calling >>> pump(

Re: Backporting BackgroundPsql

On 2024-06-25 Tu 10:26 AM, Tom Lane wrote: Andres Freund writes: On 2024-06-25 13:26:23 +0300, Heikki Linnakangas wrote: 1. Write the new test differently on backbranches. Before 664d757531, the test needs to work a lot harder to use the background psql session, calling pump() etc. That's doa

Re: Backporting BackgroundPsql

On Tue, Jun 25, 2024 at 7:40 AM Andres Freund wrote: > > Hi, > > On 2024-06-25 13:26:23 +0300, Heikki Linnakangas wrote: > > While fixing a recent bug on visibility on a standby [1], I wrote a > > regression test that uses BackgroundPsql to run some queries in a > > long-running psql session. The

Re: Backporting BackgroundPsql

Andres Freund writes: > On 2024-06-25 13:26:23 +0300, Heikki Linnakangas wrote: >> 1. Write the new test differently on backbranches. Before 664d757531, the >> test needs to work a lot harder to use the background psql session, calling >> pump() etc. That's doable, but as noted in the discussion t

Re: Backporting BackgroundPsql

Hi, On 2024-06-25 13:26:23 +0300, Heikki Linnakangas wrote: > While fixing a recent bug on visibility on a standby [1], I wrote a > regression test that uses BackgroundPsql to run some queries in a > long-running psql session. The problem is that that was refactored in v17, > commit 664d757531. Th

Re: Backporting BackgroundPsql

On 25/06/2024 13:26, Heikki Linnakangas wrote: While fixing a recent bug on visibility on a standby [1], I wrote a regression test that uses BackgroundPsql to run some queries in a long-running psql session. The problem is that that was refactored in v17, commit 664d757531. The test I wrote for

Backporting BackgroundPsql

While fixing a recent bug on visibility on a standby [1], I wrote a regression test that uses BackgroundPsql to run some queries in a long-running psql session. The problem is that that was refactored in v17, commit 664d757531. The test I wrote for v17 doesn't work as it is on backbranches. Opt