Re: Moving to Postgresql database

On Tue, Jan 16, 2024 at 11:05 AM Dominique Devienne wrote: > On Tue, Jan 16, 2024 at 5:07 PM Adrian Klaver > wrote: > >> On 1/16/24 00:06, Dominique Devienne wrote: >> > On Mon, Jan 15, 2024 at 5:17 AM veem v > > > wrote: >> > Is any key design/architectural

Re: Moving to Postgresql database

On 1/17/24 5:31 AM, Dominique Devienne wrote: Is the pg_statement_rollback technically wrong? Can't what it does be done better and more efficiently if it was in the core itself? Is it a lot of code? I took a quick look at that extension, and it's doing pretty much what you'd do if this was

Re: Moving to Postgresql database

Dominique Devienne writes: > On Tue, Jan 16, 2024 at 10:59 PM Tom Lane wrote: >> The problem is that now you have a switch somewhere (whether a GUC >> or something else, still a switch) that fundamentally changes the >> transactional semantics seen by applications. Run an application >> in the

Re: Moving to Postgresql database

On Tue, Jan 16, 2024 at 10:59 PM Tom Lane wrote: > Dominique Devienne writes: > > But sure, I take your point, you can emulate statement-level (implicit) > > rollback via an explicit SAVEPOINT, and ROLLBACK to the savepoint > instead. > > > But my point remains, that something like what that

Re: Moving to Postgresql database

Dominique Devienne writes: > But sure, I take your point, you can emulate statement-level (implicit) > rollback via an explicit SAVEPOINT, and ROLLBACK to the savepoint instead. > But my point remains, that something like what that extension does should > be an option of PostgreSQL itself, not

Re: Moving to Postgresql database

On 1/16/24 11:59 AM, Ron Johnson wrote: >      > Hi. One of the biggest pitfall of PostgreSQL, from the app-dev >     perspective, >      > is the fact any failed statement fails the whole transaction, with >      > ROLLBACK as the only recourse. > >     

Re: Moving to Postgresql database

On Tue, Jan 16, 2024 at 1:09 PM Adrian Klaver wrote: > On 1/16/24 09:59, Ron Johnson wrote: > > > Performance-killing alternatives are not really altternatives. > > Unless it is the only one that solves your problem. > Amputating one head cures one's migraines, but nobody thinks it's a viable

Re: Moving to Postgresql database

On 1/16/24 09:59, Ron Johnson wrote: Performance-killing alternatives are not really altternatives. Unless it is the only one that solves your problem. -- Adrian Klaver adrian.kla...@aklaver.com

Re: Moving to Postgresql database

On 1/16/24 09:23, Dominique Devienne wrote: On Tue, Jan 16, 2024 at 6:10 PM Adrian Klaver > wrote: Technically, it's still a ROLLBACK, so that is indeed the only recourse. Actually ROLLBACK TO: https://www.postgresql.org/docs/current/sql-rollback-to.html

Re: Moving to Postgresql database

On Tue, Jan 16, 2024 at 12:10 PM Adrian Klaver wrote: > On 1/16/24 09:04, Dominique Devienne wrote: > > On Tue, Jan 16, 2024 at 5:07 PM Adrian Klaver > > wrote: > > > > On 1/16/24 00:06, Dominique Devienne wrote: > > > On Mon, Jan 15, 2024 at 5:17 AM

Re: Moving to Postgresql database

On Tue, Jan 16, 2024 at 6:10 PM Adrian Klaver wrote: > On 1/16/24 09:04, Dominique Devienne wrote: > > On Tue, Jan 16, 2024 at 5:07 PM Adrian Klaver > > wrote: > > > > On 1/16/24 00:06, Dominique Devienne wrote: > > > On Mon, Jan 15, 2024 at 5:17 AM

Re: Moving to Postgresql database

On 1/16/24 09:04, Dominique Devienne wrote: On Tue, Jan 16, 2024 at 5:07 PM Adrian Klaver > wrote: On 1/16/24 00:06, Dominique Devienne wrote: > On Mon, Jan 15, 2024 at 5:17 AM veem v mailto:veema0...@gmail.com> >

Re: Moving to Postgresql database

On Tue, Jan 16, 2024 at 5:07 PM Adrian Klaver wrote: > On 1/16/24 00:06, Dominique Devienne wrote: > > On Mon, Jan 15, 2024 at 5:17 AM veem v > > wrote: > > Is any key design/architectural changes should the app development > > team [...], should really aware

Re: Moving to Postgresql database

On 1/16/24 00:06, Dominique Devienne wrote: On Mon, Jan 15, 2024 at 5:17 AM veem v > wrote: Is any key design/architectural changes should the app development team [...], should really aware about Hi. One of the biggest pitfall of PostgreSQL, from the

Re: Moving to Postgresql database

On Mon, Jan 15, 2024 at 5:17 AM veem v wrote: > Is any key design/architectural changes should the app development team > [...], should really aware about > Hi. One of the biggest pitfall of PostgreSQL, from the app-dev perspective, is the fact any failed statement fails the whole transaction,

Re: Moving to Postgresql database

You can find a lot information in this link https://docs.aws.amazon.com/dms/latest/oracle-to-aurora-postgresql-migration-playbook/chap-oracle-aurora-pg.html To actually perform the migration, you can use some AWS tools such as SCT + DMS:

Re: Moving to Postgresql database

On 2024-01-15 14:16, veem v wrote: Hello Experts, If some teams are well versed with the Oracle database architecture and its optimizers working and designing applications on top of this. Now moving same team to work on AWS aurora postgresql databases design/development projects. Is any key