Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: Marina Polyakova <m(dot)polyakova(at)postgrespro(dot)ru>, pgsql-hackers(at)postgresql(dot)org, Ildus Kurbangaliev <i(dot)kurbangaliev(at)postgrespro(dot)ru>, Teodor Sigaev <teodor(at)sigaev(dot)ru>
Subject: Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors
Date: 2018-06-13 19:59:24
Message-ID: 20180613195924.tcrdisjrat2se2rt@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On 2018-Jun-13, Fabien COELHO wrote:

> > > > With that, is there a need for elog()? In the backend we have
> > > > it because $HISTORY but there's no need for that here -- I
> > > > propose to lose elog() and use only ereport everywhere.
> See commit 8a07ebb3c172 which turns some ereport into elog...

For context: in the backend, elog() is only used for internal messages
(i.e. "can't-happen" conditions), and ereport() is used for user-facing
messages. There are many things ereport() has that elog() doesn't, such
as additional message fields (HINT, DETAIL, etc) that I think could have
some use in pgbench as well. If you use elog() then you can't have that.

Another difference is that in the backend, elog() messages are never
translated, while ereport() message are translated. Since pgbench is
translatable I think it would be best to keep those things in sync, to
avoid confusion. (Although of course you could do it differently in
pgbench than backend.)

One thing that just came to mind is that pgbench uses some src/fe_utils
stuff. I hope having ereport() doesn't cause a conflict with that ...

BTW I think abort() is not the right thing, as it'll cause core dumps if
enabled. Why not just exit(1)?

Álvaro Herrera
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Haribabu Kommi 2018-06-13 20:20:51 Re: [HACKERS] Pluggable storage
Previous Message Jeff Davis 2018-06-13 19:53:10 Re: Spilling hashed SetOps and aggregates to disk