Re: How to perform a long running dry run transaction without blocking

>> Anyway, thanks so much for your help. This discussion has been very useful, >> and I think I will proceed at first, exactly how you suggested, by queuing >> every validation job (using celery). Then I will explore whether or not I >> can apply the "on timeout" strategy in a small patch. >>

Re: How to perform a long running dry run transaction without blocking

On 2/7/25 10:20, Robert Leach wrote: Anyway, thanks so much for your help.  This discussion has been very useful, and I think I will proceed at first, exactly how you suggested, by queuing every validation job (using celery).  Then I will explore whether or not I can apply the "on timeout"

Re: How to get a notification

On 2/7/25 11:43, Igor Korot wrote: Hi, Adrian, It is not about the interface it is about, from link above: "pg_event_trigger_ddl_commands returns a list of DDL commands executed by each user action, when invoked in a function attached to a ddl_command_end event trigger."

Re: How to get a notification

Hi, Adrian, On Fri, Feb 7, 2025, 1:13 PM Adrian Klaver wrote: > > > On 2/7/25 11:02 AM, Igor Korot wrote: > > Hi, Adrian, > > > > On Fri, Feb 7, 2025 at 11:07 AM Adrian Klaver > wrote: > >> > >> On 2/5/25 23:21, Igor Korot wrote: > >>> Hi, ALL, > >>> In my code I'm running following: > >>> >

Re: How to get a notification

On 2/7/25 11:02 AM, Igor Korot wrote: Hi, Adrian, On Fri, Feb 7, 2025 at 11:07 AM Adrian Klaver wrote: On 2/5/25 23:21, Igor Korot wrote: Hi, ALL, In my code I'm running following: queries.push_back( L"CREATE FUNCTION __watch_schema_changes() RETURNS event_trigger LANGUAGE

Re: How to get a notification

Hi, Adrian, On Fri, Feb 7, 2025 at 11:07 AM Adrian Klaver wrote: > > On 2/5/25 23:21, Igor Korot wrote: > > Hi, ALL, > > In my code I'm running following: > > > > queries.push_back( L"CREATE FUNCTION > > __watch_schema_changes() RETURNS event_trigger LANGUAGE plpgsql AS $$ > > BEGIN

Re: Lookup tables

On 2025-02-07 09:22:13 +0100, Michał Kłeczek wrote: > > > On 6 Feb 2025, at 22:03, Peter J. Holzer wrote: > > On 2025-02-04 22:41:38 +0100, Thiemo Kellner wrote: > > > I might see what you want to point out. E.g. the table is COLOURS. The > rec with id 1 is RED, the on

Re: How to perform a long running dry run transaction without blocking

>> I'd run across a stackexchange answer >> that suggested setting a >> statement timeout (specific to postgres) in a django view. If I did that >> for the validation view, it wouldn't necessarily 100% correspond to a >> blocking issue, but since

Re: How to get a notification

On 2/5/25 23:21, Igor Korot wrote: Hi, ALL, In my code I'm running following: queries.push_back( L"CREATE FUNCTION __watch_schema_changes() RETURNS event_trigger LANGUAGE plpgsql AS $$ BEGIN NOTIFY tg_tag; END; $$;" ); queries.push_back( L"CREATE EVENT TRIGGER schema_ch

Re: How to perform a long running dry run transaction without blocking

On 2/7/25 05:49, Robert Leach wrote: Ccing list Alright I am trying to reconcile this with from below, 'The largest studies take just under a minute'. The context of the 'The largest studies take just under a minute' statement is that it's not loading the hefty/time-consuming raw data. It's

Re: Commit Latency

On 2/7/25 14:00, ravi k wrote: > Thanks for the suggestions! > > It looks the issue is happening at the time of wal creation, does > wal_init_zero off is good option? > It's impossible to say if that option will help, considering how little info about the system you provided. I suggest you start

Re: libc to libicu via pg_dump/pg_restore?

On 2/6/25 22:32, Paul Foerster wrote: Hi Adrian, On 6 Feb 2025, at 17:31, Adrian Klaver wrote: 1) Log into postgres database and do: a) DROP DATABASE mydb; b) CREATE DATABASE mydb ; 2) pg_restore -d mydb mydb.dump.gz With create database being "template template0", this is what my scrip

Re: libc to libicu via pg_dump/pg_restore?

On 2/7/25 06:53, Greg Sabino Mullane wrote: I'm not sure why we are focused on the other errors - the database fails to get dropped (or created), so future errors are to be expected. It is already created before the pg_restore is run. The OP says it works for ~40 other databases they are upgra

Re: libc to libicu via pg_dump/pg_restore?

I'm not sure why we are focused on the other errors - the database fails to get dropped (or created), so future errors are to be expected. pg_restore should be run with the --exit-on-error flag, and handle the errors one by one as someone mentioned upthread. I would use the --section=pre-data --s

Re: libc to libicu via pg_dump/pg_restore?

Paul Foerster wrote: > >> pg_restore: error: could not execute query: ERROR: insert or update on > >> table "table_1" violates foreign key constraint "..._fk" > >> DETAIL: Key (dokument_id)=(133680) is not present in table "...". > > > > Is dokument_id an integer field? > > Yes, i

Re: Commit Latency

Thanks for the suggestions! It looks the issue is happening at the time of wal creation, does wal_init_zero off is good option? Best On Wed, 5 Feb, 2025, 9:07 pm Álvaro Herrera, wrote: > Hello > > On 2025-Feb-05, Ramakrishna m wrote: > > > I have a system handling *300 TPS*, with resource usa

Re: Lookup tables

06.02.2025 22:04:34 Peter J. Holzer : >> I might see what you want to point out. E.g. the table is COLOURS. The >> rec with id 1 is RED, the one with id 2 is BLUE, 3 is GREE and so on. >> Now you load these values into the dropdown box that sports RED, BLUE, >> GREE and so on. While someone select

Re: Lookup tables

> On 6 Feb 2025, at 22:03, Peter J. Holzer wrote: > > On 2025-02-04 22:41:38 +0100, Thiemo Kellner wrote: >> >> I might see what you want to point out. E.g. the table is COLOURS. The >> rec with id 1 is RED, the one with id 2 is BLUE, 3 is GREE and so on. >> Now you load these values into the