Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v66ju-00GvOA-Jm for pgsql-admin@arkaria.postgresql.org; Tue, 07 Oct 2025 12:24:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1v66js-00GrNN-5v for pgsql-admin@arkaria.postgresql.org; Tue, 07 Oct 2025 12:24:21 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v66jr-00GrNE-IP for pgsql-admin@lists.postgresql.org; Tue, 07 Oct 2025 12:24:20 +0000 Received: from mail-ed1-x531.google.com ([2a00:1450:4864:20::531]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1v66jo-000URm-2F for pgsql-admin@lists.postgresql.org; Tue, 07 Oct 2025 12:24:19 +0000 Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-61cc281171cso12734524a12.0 for ; Tue, 07 Oct 2025 05:24:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1759839855; x=1760444655; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=+Gm0RFlmU1ihV/8EeyeE2FTOSkvXCQ5n6p4yP+u3+bg=; b=EEGFyd97XdEjtLehuSEyrZrlYIpNEq2O3vurXQoov5RbBSBSDgxtZTLKRsMP1/KqxY zD7zzdZQAAKg5Ysh2JvG0iNDgU47TQn3Vy4inleCBplUVDu742t8JJGeenZN9iTqHWK2 cjxryY/ARu4Qh9p6iTttUSk3rClXJQWuWdmem0+aKPAhyCMzo7TdDDfDcrLIyJxM03OK 8xWbSR4wEepRC3rD7+4Tkw0pHxX3jFwJeVvk2xLGxwrqanYQ7eJtcwmB13/Sa1CIX1cJ N0rJi1Wg4mfTxtdqZMItKKMhS7srwa02dpTPG1wy5bOPCx0wKACSWBEphZJvKyYj+lQb swNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759839855; x=1760444655; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=+Gm0RFlmU1ihV/8EeyeE2FTOSkvXCQ5n6p4yP+u3+bg=; b=Gmrn6pkocNVoo4M37tR2+E33llQE7EnKWQYUCBaCiYkyWxkF0+TEr3ETZQKOoyXohM tqJPwmK2xLc5IfITHmisHz7flvYyPTxjkMwIFC/AzlA9ZiTOvhv+XA8C0NLjrEfetSOK mzpHaoN6Uyrsvow/99NFusURGj5kldYJFnvg4ZqpQ58ZQiXEgurNyHd48fTd+wk5iSR7 aySPLRusVyXgiev+MYbHi23M05qwESAc0WqcyoONTY6iJgfc11/7nQg9y5xsrbxTq+PR CqbPgjFjhfLDX42SnmNzQPK1T2yqczMolpCdMyx4G7tOZYOzT7NggoD1DYjIL/pST15b P7AA== X-Gm-Message-State: AOJu0Yxw8XlwYfH8Dbu9OnNSMznp9trQDcIr+qhmxXrfjizjP8nj7GEv ujK6+ASMT2jvZn2Bb1tGoSsuLPlsI83IevEZB4ub5vZrWSmahED0pD7UyEZCkqGj6xWbSZakDsn T+VFzy4ILFVm16ECWPn4EaLphy5gtU/zkFA== X-Gm-Gg: ASbGncvdfdySLQcR27SER1OaPQPntgMrn+OjztnYRKXS0JA2VeTE6p86DKntVQf5Jjx vyP2hDFlBCStTnfcAowjmwiipkRazLsaOWcy9NFb+XiR46dXZcWHbx/7OEW/J3RYvWR8+N0mbVo TOJb+BHEoa2PIcWYpHXzhBjb1yw2jz1DxpLqY3o9pdNuqTP5Lw9Nd+lEKx/ad8txBd5YrD+TBjq 4iwFSMA74WSSa92oTFTqWU0KnkNjZuh/9pv3XkgoXad+2ZD/MR+dOb6lkYCMI2D X-Google-Smtp-Source: AGHT+IEYQwl+ih2lsBnnkd8dqUuiuR6lQE44sbXaO2G2tke660p/kK5p+WHZ++pxiS7vtrpD++5mJbqQyhViDZSflCs= X-Received: by 2002:a05:6402:4399:b0:634:4d7a:4d94 with SMTP id 4fb4d7f45d1cf-63939c2d2ffmr16215856a12.34.1759839854945; Tue, 07 Oct 2025 05:24:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Abhishek Singh Date: Tue, 7 Oct 2025 17:54:02 +0530 X-Gm-Features: AS18NWAYVylJBcSh0hMFWGuQZQtkab9lcHs2WMODMFv5dfcdafmJ27GxOQ8nR90 Message-ID: Subject: Re: Effect of COMMIT on WAL-Buffers + Effect of Check pointer. To: "Subramanian,Ramachandran" Cc: Pgsql-admin Content-Type: multipart/alternative; boundary="0000000000006a7291064090a5d1" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000006a7291064090a5d1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, No, a checkpoint record does not directly force a write of the Write-Ahead-Logging (Wal) buffer to the WAL files. Instead, the checkpoint concludes with writing a checkpoint record to the WAL, but the WAL records for transactions committed before the checkpoint have already been written and flushed to the WAL files on disk. Here is a breakdown of the process in PostgreSQL: Transactions are written to the WAL buffer. When a transaction occurs, the changes are first written to the WAL buffer, which is a shared memory area. WAL is flushed at commit. When a transaction commits, its WAL records are flushed from the WAL buffer to the WAL files on disk. This guarantees that committed transactions are durable, surviving a system crash. The checkpointer process is triggered. A checkpoint is a background process that is triggered periodically by time, log size, or an explicit command. The main purpose of a checkpoint is to flush all dirty data pages from the shared buffers to disk. The checkpoint record is written last. After all the data pages have been flushed to disk, the checkpointer writes a special "checkpoint record" to the WAL. This record's location is saved in the pg_control file and serves as a point of reference for crash recovery. Older WAL segments are removed. After a checkpoint, any WAL segments that came before the checkpoint record are no longer needed for crash recovery and can be recycled. *Note:* Regular WAL flushing- The WAL buffer is routinely flushed to the permanent WAL files on disk during regular operation. This primarily happens at transaction commit time (unless synchronous_commit is off), and also by a dedicated WAL writer background process. *Commit in PostgreSQL* =E2=97=8F WAL Writes- Backend processes write WAL records from WAL Buffers = to File System buffer cache. =E2=97=8F WAL Flush- The WAL Records gets flushed/written to WAL Segments o= n Disk. =E2=97=8F Commit-> WAL Writes + WAL Flush (synchronous_commit) =E2=97=8F With async commit, the WAL Writer flushes the WAL records and NOT= the Backend processes =E2=97=8F WAL Record Inserts (local): WAL records are first created in WAL buffers(XLogInsertRecord). Since multiple backend processes will be creating the WAL records at a time, it is properly protected by locks. The writing of WAL records in wal_buffers gets continuously written/flushed(XLogFlush) to WAL segments by different backend processes(WAL Writes). If the sychronous_commit is completely off, the flush won=E2=80=99t be happening immediately but relies on wal_writer_delay settings =E2=97=8F How much data we lose if we opt for full asynchronous commit (synchronous_commit =3D off) =E2=97=8F The answer is slightly complex, and it depends on wal_writer_dela= y settings. By default it is 200ms. That means WALs will be flushed in every wal_writer_delay to disk. The WAL writer periodically wakes up and calls XLogBackgroundFlush(). This checks for completely filled WAL pages. If they are available, it writes all the buffers up to that point =E2=97=8F commit_delay-Sets the delay in microseconds between transaction c= ommit and flushing WAL to disk * Flushes WAL Records from WAL Buffers (3% of shared_buffers) to WAL Files/Segments on disk (wal_segment_size=3D16MB) . If a transaction is too large and exceeds WAL Records > wal_buffer_size even uncommitted changes will get flushed to WAL Segments on disk. But during applying WAL Records to data files *during crash/instance recovery* only committed records since last checkpoint will get applied (the CLOG records help to identify committed transactions) =E2=97=8F PG 17- Increased the WAL segment size from 16MB to 64MB. This enh= ancement has resulted in a 10%-20% performance improvement with various workloads. =E2=97=8F So WAL Records are flushed from WAL Buffers to Disk not only duri= ng transaction commit but also when WAL buffers get filled. =E2=97=8F Every Checkpoint maintains a Checkpoint record in WAL Segments so= that the WAL Records prior to the checkpoint record can be reused/deleted when WAL segments need to be overwritten. Also Archiving will need to archive only completely filled WAL Segments before they get overwritten/recycled. But WAL Segments can be switched without getting full either by setting archive_timeout or pg_switch_wal. Best Regards, Abhishek Singh M.E., Coburg University, Germany Profile: *https://linkedin.com/in/abhi15 * ------------------------------------ On Tue, 7 Oct, 2025, 4:53=E2=80=AFpm Subramanian,Ramachandran, < ramachandran.subramanian@alte-leipziger.de> wrote: > Hello, > > > > > > > > Coming from a Db2 =E2=80=93 mainframe world trying to understand Postgres= . Kindly > forgive my ignorance and the somewhat long winded question. > > > > > > When a particular transaction TRAN1, inserts/updates/deletes data, the > changes are made to the memory blocks in the Shared Buffer ( data buffer= s > ) and corresponding Undo and Redo Logs are written to the Log buffers. > While > > TRAN1 is running , TRAN2 TRAN3 =E2=80=A6. TRAN4 can run concurrently and = be > writing information tot he WAL-Buffers. > > > > > > Let us assume that TRAN1 began at 0000 Hours and at has updated 1 rows > at 0001 Hours. > > > > Let us further assume for simplicity that TRAN1 TRAN2 TRAN3 and TRAN4 > have updated 1 row each and written 2 WAL-Records each in the WAL-Buffer > BUT NOT issued a COMMIT yet. > > > > Now at 0002 Hours TRAN4 alone has issued a COMMIT. > > > > Will all the 8 WAL-Buffer records be written to the WAL files? Obviousl= y > TRAN1 2 and 3 are IN-FLIGHT ( un committed ) at 0002 Hours, while TRAN4 = is > committed. ( This is how DB2 works . When a COMMIT is issued by any > transaction ALL the log buffers are written to disk, immaterial of if the= y > are commited or not. There is a BEGIN Unit of Recovery Log record, a END > Unit of Recovery log Record associated with each transaction . Each Unit = of > Recovery is an unique identifier. Every log record that belongs to this > Unit of Recovery ID has this identifier in it. So after a crash, the log= s > are scanned forward since the last check point and only those logrecords > with a matching BEGIN UR and END UR are redone, and those with just a BEG= IN > UR and no matching END UR are rolled back. > > > > Does a COMMIT even cause the ALL the WAL-Buffers to be written to > WAL-Files in Postgres? > > > > If not what exactly does a COMMIT do? how can one force a write of the > WAL-Buffers to disk with a SQL command? > > > > > > > > > Additionally, after the check pointer externalizes all the comitted Share= d > Buffer Data to disk, does it write a check point record to the WAL-Buffer > alone? > > > > if the check point information is just written to the WAL-Buffer by the > Check-Pointer background process and before it is copied down to a file o= n > the disk, Postgres crashes, is this check point not lost ? Does a Chec= k > point record force a WAL-Buffer write to WAL-Files ? > > > > > > > > > > > > > > > > Thank you for your time. > > > > > > Ram > > > > Freundliche Gr=C3=BC=C3=9Fe > > *i. A. Ramachandran Subramanian* > > Zentralbereich Informationstechnologie > > Alte Leipziger Lebensversicherung a. G. > > Hallesche Krankenversicherung a. G. > > ______________________ > > ALH Gruppe > Alte Leipziger-Platz 1, 61440 Oberursel > > Tel: +49 (6171) 66-4882 > Fax: +49 (6171) 66-800-4882 > E-Mail: ramachandran.subramanian@alte-leipziger.de > www.alte-leipziger.de > www.hallesche.de > > Alte Leipziger Lebensversicherung a. G., Alte Leipziger-Platz 1, 61440 > Oberursel > > > Vors. des Aufsichtsrats: Dr. Walter Botermann =C2=B7 Vorstand: Christoph = Bohn > (Vors.), Dr. J=C3=BCrgen Bierbaum (stv. Vors.), Frank Kettnaker, Dr. Joch= en > Kriegmeier, Alexander Mayer, Christian Pape, Wiltrud Pekarek, Udo Wilcsek > > Sitz Oberursel (Taunus) =C2=B7 Rechtsform VVaG =C2=B7 Amtsgericht Bad Hom= burg v. d. > H. HRB 1583 =C2=B7 USt.-IdNr. DE 114106814 > > Hallesche Krankenversicherung a. G., L=C3=B6ffelstra=C3=9Fe 34-38, 70597 = Stuttgart > > > Vors. des Aufsichtsrats: Dr. Walter Botermann =C2=B7 Vorstand: Christoph = Bohn > (Vors.), Dr. J=C3=BCrgen Bierbaum (stv. Vors.), Frank Kettnaker, Dr. Joch= en > Kriegmeier, Alexander Mayer, Christian Pape, Wiltrud Pekarek, Udo Wilcsek > > Sitz Stuttgart =C2=B7 Rechtsform VVaG =C2=B7 Amtsgericht Stuttgart HRB 26= 86 =C2=B7 > USt.-IdNr. DE 147802285 > > Beitr=C3=A4ge zu privaten Kranken- und Pflegekrankenversicherungen unterl= iegen > nicht der Versicherungsteuer (=C2=A7 4 (1) Nr. 5 b VersStG) =C2=B7 > Versicherungsleistungen sowie Ums=C3=A4tze aus > Versicherungsvertreter-/Maklert=C3=A4tigkeiten sind umsatzsteuerfrei > > Pflichtangaben der ALH Gruppe > gem=C3=A4=C3=9F =C2=A7 35a GmbHG bzw. =C2=A7 80 AktG > --0000000000006a7291064090a5d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

No= , a checkpoint record does not directly force a write of the Write-Ahead-Lo= gging (Wal) buffer to the WAL files. Instead, the checkpoint concludes with= writing a checkpoint record to the WAL, but the WAL records for transactio= ns committed before the checkpoint have already been written and flushed to= the WAL files on disk.

= =C2=A0
Here is a breakdown of the process in PostgreSQL:

Transactions are written = to the WAL buffer. When a transaction occurs, the changes are first written= to the WAL buffer, which is a shared memory area.
<= br>
WAL is flushed at commit= . When a transaction commits, its WAL records are flushed from the W= AL buffer to the WAL files on disk. This guarantees that committed transact= ions are durable, surviving a system crash.

The checkpointer process is triggered. A checkpoint is = a background process that is triggered periodically by time, log size, or a= n explicit command. The main purpose of a checkpoint is to flush all dirty = data pages from the shared buffers to disk.

The checkpoint record is written last. After all the da= ta pages have been flushed to disk, the checkpointer writes a special "= ;checkpoint record" to the WAL. This record's location is saved in= the pg_control file and serves as a point of reference for crash recovery.=

Older WAL segments are = removed. After a checkpoint, any WAL segments that came before the checkpoi= nt record are no longer needed for crash recovery and can be recycled.

Note:=C2=A0
Regular WAL flushing- The WAL buffer is routinely flushed to = the permanent WAL files on disk during regular operation. This primarily ha= ppens at transaction commit time (unless synchronous_commit is off), and al= so by a dedicated WAL writer background process.=C2=A0

Commit in PostgreSQL
=E2=97=8F WAL Writes- Backend processes write WAL records fro= m WAL Buffers to File System buffer cache.
=E2=97=8F WAL Flush- The WAL Records gets flushed/w= ritten to WAL Segments on Disk.
=E2=97=8F Commit-> WAL Writes + WAL Flush (synch= ronous_commit)
=E2=97=8F With async commit, the WAL Writer flushes= the WAL records and NOT the Backend processes
=E2=97=8F WAL Record Inserts (local): WAL records a= re first created in WAL buffers(XLogInsertRecord). Since multiple=20
backend processes will be creating the WAL records = at a time, it is properly protected by locks. The writing of=20
WAL records in wal_buffers gets continuously writte= n/flushed(XLogFlush) to WAL segments by different=20
backend processes(WAL Writes). If the sychronous_co= mmit is completely off, the flush won=E2=80=99t be happening=20
immediately but relies on wal_writer_delay settings
=E2=97=8F How much data we = lose if we opt for full asynchronous commit (synchronous_commit =3D off)
=E2=97=8F The answer is slightly complex, an= d it depends on wal_writer_delay settings. By default it is 200ms. That mea= ns=20
WALs will be flushed in every wal_writer_delay to d= isk. The WAL writer periodically wakes up and calls=20
XLogBackgroundFlush(). This checks for completely f= illed WAL pages. If they are available, it writes all the buffers up to tha= t point
=E2=97=8F commit_delay-Sets the delay in mic= roseconds between transaction commit and flushing WAL to disk
* Flushes WAL Records from WAL Buffers (3% of shared_buffers) to = WAL Files/Segments on disk
(wal_segment_size=3D16MB) . If a transaction is too= large and exceeds WAL Records > wal_buffer_size even
uncommitted changes will get flushed to WAL Segment= s on disk. But during applying WAL Records to data files
during crash/instance recovery only c= ommitted records since last checkpoint will get applied (the CLOG records h= elp to identify committed transactions)
=E2=97=8F PG= 17- Increased the WAL segment size from 16MB to 64MB. This enhancement has= resulted in a 10%-20% performance improvement with various workloads.
=E2=97=8F So WAL Records are flushed from WAL Buffers to = Disk not only during transaction commit but also when
WAL buffers get filled.
=E2=97=8F Every Checkpoint maintains = a Checkpoint record in WAL Segments so that the WAL Records prior to the
checkpoint record can be reused/deleted when WAL se= gments need to be overwritten. Also Archiving will need to archive only com= pletely filled WAL Segments before they get overwritten/recycled. But WAL S= egments can be switched without getting full either by setting archive_time= out or pg_switch_wal.


Best Regards,=C2=A0
Abhishek Singh
M.E., Coburg Un= iversity, Germany



<= div dir=3D"auto">------------------------------------

=
On Tue, 7 Oct, 2025, 4:53=E2=80=AFpm Subramanian,Ramachandran, = <ramachand= ran.subramanian@alte-leipziger.de> wrote:

= Hello,

= =C2=A0

= =C2=A0

= =C2=A0

= Coming from a Db2 =E2=80=93 mainframe world trying to understand Postgres.= =C2=A0 Kindly forgive my ignorance and the somewhat long winded question. = =C2=A0

= =C2=A0

= =C2=A0

= =C2=A0 When a particular transaction TRAN1, inserts/updates/deletes data, t= he changes are made to the memory blocks in the =C2=A0Shared Buffer ( data = buffers ) and corresponding Undo and Redo Logs are written to the Log buffers.=C2=A0 While

= TRAN1 is running , TRAN2 TRAN3 =E2=80=A6. TRAN4 can run concurrently and be= writing information tot he WAL-Buffers.

= =C2=A0

= =C2=A0

= =C2=A0 Let us assume that TRAN1 began at 0000 Hours and at has updated 1 ro= ws at 0001 Hours.

= =C2=A0

= =C2=A0Let us further assume for simplicity that TRAN1 TRAN2 TRAN3 and TRAN4= have updated 1 row each and written 2 WAL-Records each in the WAL-Buffer B= UT =C2=A0NOT issued a COMMIT yet.

= =C2=A0

= =C2=A0Now at 0002 Hours TRAN4 alone has issued a COMMIT.

= =C2=A0

= Will all the 8 =C2=A0WAL-Buffer records be written to the WAL files?=C2=A0 = Obviously TRAN1 2 and 3 are =C2=A0IN-FLIGHT ( un committed ) at 0002 Hours,= while TRAN4 is committed. =C2=A0( This is how DB2 works . When a COMMIT is issued by any transaction ALL the log buffers are written to dis= k, immaterial of if they are commited or not. There is a BEGIN Unit of Reco= very Log record, a END Unit of Recovery log Record associated with each tra= nsaction . Each Unit of Recovery is an unique identifier. Every log record that belongs to this Unit of Rec= overy ID has this identifier in it.=C2=A0 So after a crash, the logs are sc= anned forward since the last check point and only those logrecords with a m= atching BEGIN UR and END UR are redone, and those with just a BEGIN UR and no matching END UR are rolled back. =

= =C2=A0

= Does a COMMIT even cause the ALL the WAL-Buffers to be written to WAL-Files= in Postgres?

= =C2=A0

= If not what exactly does a COMMIT do? how can one force a write of the WAL-= Buffers to disk with a SQL command?

= =C2=A0

= =C2=A0

= =C2=A0

=
Additionally, after the check pointer externalizes all the comitted Shared = Buffer Data to disk, does it write a check point record to the WAL-Buffer a= lone?

= =C2=A0

= if the check point information is just written to the WAL-Buffer=C2=A0 by t= he Check-Pointer background process and before it is copied down to a file = on the disk,=C2=A0 Postgres crashes, is this check point not lost ?=C2=A0 =C2=A0Does a Check point record force a WAL-Buffer write = to WAL-Files ?

= =C2=A0

= =C2=A0

= =C2=A0

= =C2=A0

= =C2=A0

= =C2=A0

= =C2=A0

= Thank you for your time.

= =C2=A0

= =C2=A0

= Ram

=C2=A0


Freundliche Gr=C3=BC=C3=9Fe

i. A. Ramachandran Subramanian =20

Zentralbereich Informationstechnologi= e

=20

Alte Leipziger Lebensversicherung a. G.

Hallesche Krankenversicherung a. G.

=20

______________________

ALH Gruppe
Alte Leipziger-Platz 1, 61440 Oberursel
Tel: +49 (6171) 66-48= 82
Fax: +49 (6171) 66-800-4882
E-Mail: ramach= andran.subramanian@alte-leipziger.de
www.alte-leipziger.dewww.hallesche.de

Alte Leipziger Lebensversicherung a. = G., Alte Leipziger-Platz 1, 61440 = Oberursel

Vors. des Aufsichtsrats: D= r. Walter Botermann =C2=B7 Vorstand: Christoph Bohn (Vors.), Dr. J=C3=BCrge= n Bierbaum (stv. Vors.), Frank Kettnaker, Dr. Jochen Kriegmeier, Alexander = Mayer, Christian Pape, Wiltrud Pekarek, Udo Wilcsek

Sitz Oberursel (Taunus) =C2=B7 Rechts= form VVaG =C2=B7 Amtsgericht Bad Homburg v. d. H. HRB 1583 =C2=B7 USt.-IdNr= . DE 114106814


Hallesche Krankenversicherung a. G., = L=C3=B6ffelstra=C3=9Fe 34-38= , 70597 Stuttgart

Vors. des Aufsichtsrats: Dr. Walter B= otermann =C2=B7 Vorstand: Christoph Bohn (Vors.), Dr. J=C3=BCrgen Bierbaum = (stv. Vors.), Frank Kettnaker, Dr. Jochen Kriegmeier, Alexander Mayer, Chri= stian Pape, Wiltrud Pekarek, Udo Wilcsek

Sitz Stuttgart =C2=B7 Rechtsform VVaG= =C2=B7 Amtsgericht Stuttgart HRB 2686 =C2=B7 USt.-IdNr. DE 147802285

Beitr=C3=A4ge zu privaten Kranken- un= d Pflegekrankenversicherungen unterliegen nicht der Versicherungsteuer (=C2= =A7 4 (1) Nr. 5 b VersStG) =C2=B7 Versicherungsleistungen sowie Ums=C3=A4tz= e aus Versicherungsvertreter-/Maklert=C3=A4tigkeiten sind umsatzsteuerfrei<= /p>

Pflichtangabe= n der ALH Gruppe gem=C3=A4=C3=9F =C2=A7 35a GmbHG bzw. =C2=A7 80 AktG

--0000000000006a7291064090a5d1--