{"id":15819,"date":"2021-02-26T15:24:59","date_gmt":"2021-02-26T14:24:59","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/be-careful-with-prepared-transactions-in-postgresql\/"},"modified":"2021-02-26T15:24:59","modified_gmt":"2021-02-26T14:24:59","slug":"be-careful-with-prepared-transactions-in-postgresql","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/be-careful-with-prepared-transactions-in-postgresql\/","title":{"rendered":"Be careful with prepared transactions in PostgreSQL"},"content":{"rendered":"

PostgreSQL gives you the possibility for two-phase commit<\/a>. You’ll might need that if you want an atomic distributed commit. If you check the PostgreSQL documentation<\/a> there is a clear warning about using these kind of transactions: “Unless you’re writing a transaction manager, you probably shouldn’t be using PREPARE TRANSACTION”. If you really need to use them, you need to be very careful, that prepared transactions are committed or rollback-ed as soon as possible. In other words, you need a mechanism that monitors the prepared transactions in your database and takes appropriate action if they are kept open too long. If this happens you will run into various issues and it is not immediately obvious where your issues come from.<\/p>\n

<\/p>\n

To start with, lets create a simple prepared transaction:<\/p>\n

\npostgres=# begin;\nBEGIN\npostgres=*# create table t1 (a int);\nCREATE TABLE\npostgres=*# insert into t1 values (1);\nINSERT 0 1\npostgres=*# prepare transaction 'abc';\nPREPARE TRANSACTION\n<\/pre>\n
From this point on, the transaction is not anymore associated with the session. You can verify that easily if you try to commit or rollback the transaction:<\/p>\n
\npostgres=# commit;\nWARNING:  there is no transaction in progress\nCOMMIT\n<\/pre>\n
This also means that the “t1” table that was created before we prepared the transaction is not visible to us:<\/p>\n
\npostgres=# select * from t1;\nERROR:  relation \"t1\" does not exist\nLINE 1: select * from t1;\n                      ^\n<\/pre>\n
Although we are not in any visible transaction anymore, there are locks in the background because of our prepared transaction:<\/p>\n
\npostgres=# select * from pg_locks where database = (select oid from pg_database where datname = 'postgres') and mode like '%Exclusive%';\n locktype | database | relation | page | tuple | virtualxid | transactionid | classid | objid | objsubid | virtualtransaction | pid |        mode         | granted | fastpath | waitstart \n----------+----------+----------+------+-------+------------+---------------+---------+-------+----------+--------------------+-----+---------------------+---------+----------+-----------\n relation |    12969 |    24582 |      |       |            |               |         |       |          | -1\/562             |     | RowExclusiveLock    | t       | f        | \n relation |    12969 |    24582 |      |       |            |               |         |       |          | -1\/562             |     | AccessExclusiveLock | t       | f        | \n(2 rows)\n<\/pre>\n
There is one AccessExclusiveLock lock, wihch is the lock on the “t1” table. The other lock, “RowExclusiveLock”, is the lock that protects the row we inserted above. How can we know that? Well, currently this is only a guess, as the “t1” table is not visible:<\/p>\n
\npostgres=# select relname from pg_class where oid = 24582;\n relname \n---------\n(0 rows)\n<\/pre>\n
Once we commit the prepared transaction, we can verify, that it really was about “t1”:<\/p>\n
\npostgres=# commit prepared 'abc';\nCOMMIT PREPARED\npostgres=# select relname from pg_class where oid = 24582;\n relname \n---------\n t1\n(1 row)\n\npostgres=# select * from t1;\n a \n---\n 1\n(1 row)\n<\/pre>\n
We can also confirm that by again taking a look the locks:<\/p>\n
\npostgres=# select * from pg_locks where database = (select oid from pg_database where datname = 'postgres') and mode like '%Exclusive%';\n locktype | database | relation | page | tuple | virtualxid | transactionid | classid | objid | objsubid | virtualtransaction | pid | mode | granted | fastpath | waitstart \n----------+----------+----------+------+-------+------------+---------------+---------+-------+----------+--------------------+-----+------+---------+----------+-----------\n(0 rows)\n<\/pre>\n
These locks are gone as well. So, not a big deal, as soon as the prepared transaction is committed all is fine. This is the good case and if it goes like that you will probabyl not hit any issue.<\/p>\n
Lets create another prepared transaction:<\/p>\n
\npostgres=# begin;\nBEGIN\npostgres=*# insert into t1 values(2);\nINSERT 0 1\npostgres=*# prepare transaction 'abc';\nPREPARE TRANSACTION\n<\/pre>\n
First point to remember: Once you create a prepared transaction it is fully stored on disk:<\/p>\n
\npostgres=# ! ls -la $PGDATA\/pg_twophase\/*\n-rw------- 1 postgres postgres 212 Feb 26 11:24 \/u02\/pgdata\/DEV\/pg_twophase\/00000233\n<\/pre>\n
Once it is committed the file is gone:<\/p>\n
\npostgres=# commit prepared 'abc';\nCOMMIT PREPARED\npostgres=# ! ls -la $PGDATA\/pg_twophase\/\ntotal 8\ndrwx------  2 postgres postgres 4096 Feb 26 11:26 .\ndrwx------ 20 postgres postgres 4096 Feb 26 10:49 ..\n<\/pre>\n
Why is that? The answer is, that a prepared transaction even can be committed or rollback-ed if the server crashes. But this also means, that prepared transactions are persistent across restarts of the instance:<\/p>\n
\npostgres=# begin;\nBEGIN\npostgres=*# insert into t1 values(3);\nINSERT 0 1\npostgres=*# prepare transaction 'abc';\nPREPARE TRANSACTION\npostgres=# ! pg_ctl restart \nwaiting for server to shut down.... done\nserver stopped\nwaiting for server to start....2021-02-26 11:28:51.226 CET - 1 - 10576 -  - @ LOG:  redirecting log output to logging collector process\n2021-02-26 11:28:51.226 CET - 2 - 10576 -  - @ HINT:  Future log output will appear in directory \"pg_log\".\n done\nserver started\npostgres=# ! ls -la  $PGDATA\/pg_twophase\/\ntotal 12\ndrwx------  2 postgres postgres 4096 Feb 26 11:28 .\ndrwx------ 20 postgres postgres 4096 Feb 26 11:28 ..\n-rw-------  1 postgres postgres  212 Feb 26 11:28 00000234\n<\/pre>\n
Is that an issue? Imagine someone prepared a transaction and forgot to commit or rollback the transaction. A few days later someone wants to modify the application and tries to add a column to the “t1” table:<\/p>\n
\npostgres=# alter table t1 add column b text;\n<\/pre>\n
This will be blocked for no obvious reason. Looking at the locks once more:<\/p>\n
\n locktype | database | relation | page | tuple | virtualxid | transactionid | classid | objid | objsubid | virtualtransaction |  pid  |        mode         | granted | fastpath |           waitstart           \n----------+----------+----------+------+-------+------------+---------------+---------+-------+----------+--------------------+-------+---------------------+---------+----------+-------------------------------\n relation |    12969 |    24582 |      |       |            |               |         |       |          | 3\/4                | 10591 | AccessExclusiveLock | f       | f        | 2021-02-26 11:30:30.303512+01\n relation |    12969 |    24582 |      |       |            |               |         |       |          | -1\/564             |       | RowExclusiveLock    | t       | f        | \n(2 rows)\n<\/pre>\n
We can see that pid 10591 is trying to get the look but cannot get in (granted=’f’). The other entry has no pid entry and this is the prepared transaction. The pid will always be empty for prepared transactions, so if you already know this, it might point you to the correct solution for this. If you don’t, then you are almost stuck. There is no session you can terminate, as nothing is reported about that in pg_stat_activity<\/a>:<\/p>\n
\npostgres=# select datid,datname,pid,wait_event_type,wait_event,state,backend_type from pg_stat_activity ;\n datid | datname  |  pid  | wait_event_type |     wait_event      | state  |         backend_type         \n-------+----------+-------+-----------------+---------------------+--------+------------------------------\n       |          | 10582 | Activity        | AutoVacuumMain      |        | autovacuum launcher\n       |          | 10584 | Activity        | LogicalLauncherMain |        | logical replication launcher\n 12969 | postgres | 10591 | Lock            | relation            | active | client backend\n 12969 | postgres | 10593 |                 |                     | active | client backend\n       |          | 10580 | Activity        | BgWriterHibernate   |        | background writer\n       |          | 10579 | Activity        | CheckpointerMain    |        | checkpointer\n       |          | 10581 | Activity        | WalWriterMain       |        | walwriter\n(7 rows)\n<\/pre>\n
You will not see any blocking sessions (blocked_by=0):<\/p>\n
\npostgres=# select pid\npostgres-#      , usename\npostgres-#      , pg_blocking_pids(pid) as blocked_by\npostgres-#      , query as blocked_query\npostgres-#   from pg_stat_activity\npostgres-#   where cardinality(pg_blocking_pids(pid)) > 0;\n  pid  | usename  | blocked_by |           blocked_query           \n-------+----------+------------+-----------------------------------\n 10591 | postgres | {0}        | alter table t1 add column b text;\n<\/pre>\n
Even if you restart the instance the issue will persist. The only solution to that is, to either commit or rollback the prepared transactions;<\/p>\n
\npostgres=# select * from pg_prepared_xacts;\n transaction | gid |           prepared            |  owner   | database \n-------------+-----+-------------------------------+----------+----------\n         564 | abc | 2021-02-26 11:28:37.362649+01 | postgres | postgres\n(1 row)\npostgres=# rollback prepared 'abc';\nROLLBACK PREPARED\npostgres=# \n<\/pre>\n
As soon this completed the other session will be able to complete it’s work:<\/p>\n
\npostgres=# alter table t1 add column b text;\nALTER TABLE\n<\/pre>\n
Remember: When things look really weird, it might be, because you have ongoing prepared transactions.<\/p>\n","protected":false},"excerpt":{"rendered":"
PostgreSQL gives you the possibility for two-phase commit. You’ll might need that if you want an atomic distributed commit. If you check the PostgreSQL documentation there is a clear warning about using these kind of transactions: “Unless you’re writing a transaction manager, you probably shouldn’t be using PREPARE TRANSACTION”. If you really need to use […]<\/p>\n","protected":false},"author":29,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[229],"tags":[77],"type_dbi":[],"class_list":["post-15819","post","type-post","status-publish","format-standard","hentry","category-database-administration-monitoring","tag-postgresql"],"acf":[],"yoast_head":"\nBe careful with prepared transactions in PostgreSQL - dbi Blog<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.dbi-services.com\/blog\/be-careful-with-prepared-transactions-in-postgresql\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Be careful with prepared transactions in PostgreSQL\" \/>\n<meta property=\"og:description\" content=\"PostgreSQL gives you the possibility for two-phase commit. You’ll might need that if you want an atomic distributed commit. If you check the PostgreSQL documentation there is a clear warning about using these kind of transactions: “Unless you’re writing a transaction manager, you probably shouldn’t be using PREPARE TRANSACTION”. If you really need to use […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/be-careful-with-prepared-transactions-in-postgresql\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2021-02-26T14:24:59+00:00\" \/>\n<meta name=\"author\" content=\"Daniel Westermann\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@westermanndanie\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Daniel Westermann\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"6 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/be-careful-with-prepared-transactions-in-postgresql\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/be-careful-with-prepared-transactions-in-postgresql\\\/\"},\"author\":{\"name\":\"Daniel Westermann\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/8d08e9bd996a89bd75c0286cbabf3c66\"},\"headline\":\"Be careful with prepared transactions in PostgreSQL\",\"datePublished\":\"2021-02-26T14:24:59+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/be-careful-with-prepared-transactions-in-postgresql\\\/\"},\"wordCount\":576,\"commentCount\":0,\"keywords\":[\"PostgreSQL\"],\"articleSection\":[\"Database Administration & Monitoring\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/be-careful-with-prepared-transactions-in-postgresql\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/be-careful-with-prepared-transactions-in-postgresql\\\/\",\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/be-careful-with-prepared-transactions-in-postgresql\\\/\",\"name\":\"Be careful with prepared transactions in PostgreSQL - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#website\"},\"datePublished\":\"2021-02-26T14:24:59+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/8d08e9bd996a89bd75c0286cbabf3c66\"},\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/be-careful-with-prepared-transactions-in-postgresql\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/be-careful-with-prepared-transactions-in-postgresql\\\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/be-careful-with-prepared-transactions-in-postgresql\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Be careful with prepared transactions in PostgreSQL\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#website\",\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/\",\"name\":\"dbi Blog\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/8d08e9bd996a89bd75c0286cbabf3c66\",\"name\":\"Daniel Westermann\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/31350ceeecb1dd8986339a29bf040d4cd3cd087d410deccd8f55234466d6c317?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/31350ceeecb1dd8986339a29bf040d4cd3cd087d410deccd8f55234466d6c317?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/31350ceeecb1dd8986339a29bf040d4cd3cd087d410deccd8f55234466d6c317?s=96&d=mm&r=g\",\"caption\":\"Daniel Westermann\"},\"description\":\"Daniel Westermann is Principal Consultant and Technology Leader Open Infrastructure at dbi services. He has more than 15 years of experience in management, engineering and optimization of databases and infrastructures, especially on Oracle and PostgreSQL. Since the beginning of his career, he has specialized in Oracle Technologies and is Oracle Certified Professional 12c and Oracle Certified Expert RAC\\\/GridInfra. Over time, Daniel has become increasingly interested in open source technologies, becoming \u201cTechnology Leader Open Infrastructure\u201d and PostgreSQL expert. \u00a0Based on community or EnterpriseDB tools, he develops and installs complex high available solutions with PostgreSQL. He is also a certified PostgreSQL Plus 9.0 Professional and a Postgres Advanced Server 9.4 Professional. He is a regular speaker at PostgreSQL conferences in Switzerland and Europe. Today Daniel is also supporting our customers on AWS services such as AWS RDS, database migrations into the cloud, EC2 and automated infrastructure management with AWS SSM (System Manager). He is a certified AWS Solutions Architect Professional. Prior to dbi services, Daniel was Management System Engineer at LC SYSTEMS-Engineering AG in Basel. Before that, he worked as Oracle Developper &\u00a0Project Manager at Delta Energy Solutions AG in Basel (today Powel AG). Daniel holds a diploma in Business Informatics (DHBW, Germany). His branch-related experience mainly covers the pharma industry, the financial sector, energy, lottery and telecommunications.\",\"sameAs\":[\"https:\\\/\\\/x.com\\\/westermanndanie\"],\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/author\\\/daniel-westermann\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Be careful with prepared transactions in PostgreSQL - dbi Blog","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.dbi-services.com\/blog\/be-careful-with-prepared-transactions-in-postgresql\/","og_locale":"en_US","og_type":"article","og_title":"Be careful with prepared transactions in PostgreSQL","og_description":"PostgreSQL gives you the possibility for two-phase commit. You’ll might need that if you want an atomic distributed commit. If you check the PostgreSQL documentation there is a clear warning about using these kind of transactions: “Unless you’re writing a transaction manager, you probably shouldn’t be using PREPARE TRANSACTION”. If you really need to use […]","og_url":"https:\/\/www.dbi-services.com\/blog\/be-careful-with-prepared-transactions-in-postgresql\/","og_site_name":"dbi Blog","article_published_time":"2021-02-26T14:24:59+00:00","author":"Daniel Westermann","twitter_card":"summary_large_image","twitter_creator":"@westermanndanie","twitter_misc":{"Written by":"Daniel Westermann","Est. reading time":"6 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/be-careful-with-prepared-transactions-in-postgresql\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/be-careful-with-prepared-transactions-in-postgresql\/"},"author":{"name":"Daniel Westermann","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/8d08e9bd996a89bd75c0286cbabf3c66"},"headline":"Be careful with prepared transactions in PostgreSQL","datePublished":"2021-02-26T14:24:59+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/be-careful-with-prepared-transactions-in-postgresql\/"},"wordCount":576,"commentCount":0,"keywords":["PostgreSQL"],"articleSection":["Database Administration & Monitoring"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/be-careful-with-prepared-transactions-in-postgresql\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/be-careful-with-prepared-transactions-in-postgresql\/","url":"https:\/\/www.dbi-services.com\/blog\/be-careful-with-prepared-transactions-in-postgresql\/","name":"Be careful with prepared transactions in PostgreSQL - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"datePublished":"2021-02-26T14:24:59+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/8d08e9bd996a89bd75c0286cbabf3c66"},"breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/be-careful-with-prepared-transactions-in-postgresql\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/be-careful-with-prepared-transactions-in-postgresql\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/be-careful-with-prepared-transactions-in-postgresql\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Be careful with prepared transactions in PostgreSQL"}]},{"@type":"WebSite","@id":"https:\/\/www.dbi-services.com\/blog\/#website","url":"https:\/\/www.dbi-services.com\/blog\/","name":"dbi Blog","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/8d08e9bd996a89bd75c0286cbabf3c66","name":"Daniel Westermann","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/31350ceeecb1dd8986339a29bf040d4cd3cd087d410deccd8f55234466d6c317?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/31350ceeecb1dd8986339a29bf040d4cd3cd087d410deccd8f55234466d6c317?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/31350ceeecb1dd8986339a29bf040d4cd3cd087d410deccd8f55234466d6c317?s=96&d=mm&r=g","caption":"Daniel Westermann"},"description":"Daniel Westermann is Principal Consultant and Technology Leader Open Infrastructure at dbi services. He has more than 15 years of experience in management, engineering and optimization of databases and infrastructures, especially on Oracle and PostgreSQL. Since the beginning of his career, he has specialized in Oracle Technologies and is Oracle Certified Professional 12c and Oracle Certified Expert RAC\/GridInfra. Over time, Daniel has become increasingly interested in open source technologies, becoming \u201cTechnology Leader Open Infrastructure\u201d and PostgreSQL expert. \u00a0Based on community or EnterpriseDB tools, he develops and installs complex high available solutions with PostgreSQL. He is also a certified PostgreSQL Plus 9.0 Professional and a Postgres Advanced Server 9.4 Professional. He is a regular speaker at PostgreSQL conferences in Switzerland and Europe. Today Daniel is also supporting our customers on AWS services such as AWS RDS, database migrations into the cloud, EC2 and automated infrastructure management with AWS SSM (System Manager). He is a certified AWS Solutions Architect Professional. Prior to dbi services, Daniel was Management System Engineer at LC SYSTEMS-Engineering AG in Basel. Before that, he worked as Oracle Developper &\u00a0Project Manager at Delta Energy Solutions AG in Basel (today Powel AG). Daniel holds a diploma in Business Informatics (DHBW, Germany). His branch-related experience mainly covers the pharma industry, the financial sector, energy, lottery and telecommunications.","sameAs":["https:\/\/x.com\/westermanndanie"],"url":"https:\/\/www.dbi-services.com\/blog\/author\/daniel-westermann\/"}]}},"_links":{"self":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/15819","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/users\/29"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/comments?post=15819"}],"version-history":[{"count":0,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/15819\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=15819"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=15819"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=15819"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=15819"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}