pg_dump:qemu: uncaught target signal 7 (Bus error) - core dumped

On Mon, Dec 08, 2025 at 11:23:53PM +0530, tushar wrote:

I found a scenario where, after firing the wrong way of using the pg_dump
command, not only server fail to start,
But later, I am not able to perform initdb/pg_ctl as well

Please refer to this testcase:
"
PG v19 devel, Cluster running on default port=5432
Run pg_dump (./pg_dump -Ft -s -c -v -f postgres schema_clean.tar1)
"

IIUC the problem is that you are overwriting the postgres binary. Is that
correct?

Is there any way we can generate some error messages?

Perhaps it'd be worth making pg_dump a little more cautious about
overwriting existing files (or at least have the option to avoid that).

--
nathan

tushar <tushar.ahuja@enterprisedb.com> writes:

I found a scenario where, after firing the wrong way of using the pg_dump
command, not only server fail to start,
But later, I am not able to perform initdb/pg_ctl as well

The result is :
edb@1a1c15437e7c bin]$ ./pg_dump -Ft -s -c -v -f postgres schema_clean.tar1
qemu: uncaught target signal 7 (Bus error) - core dumped

I think what you are showing here is that you ran this command in the
installation's bin directory, and where you write "-f postgres",
that caused pg_dump to overwrite the postgres executable.

Is there any way we can generate some error messages?

Don't do that. Generally speaking, you don't want installed files to
be writable at all by ordinary user accounts ... but if they are,
for heaven's sake don't cd into those directories before doing work.
You're just setting yourself up for trouble.

regards, tom lane

Nathan Bossart <nathandbossart@gmail.com> writes:

On Mon, Dec 08, 2025 at 11:23:53PM +0530, tushar wrote:

Is there any way we can generate some error messages?

Perhaps it'd be worth making pg_dump a little more cautious about
overwriting existing files (or at least have the option to avoid that).

I think we'd get way more brickbats than kudos for that.

regards, tom lane

On Mon, Dec 08, 2025 at 01:20:13PM -0500, Tom Lane wrote:

Don't do that. Generally speaking, you don't want installed files to
be writable at all by ordinary user accounts ... but if they are,
for heaven's sake don't cd into those directories before doing work.
You're just setting yourself up for trouble.

Yeah, I got a permission error when I tried this:

/usr/local/pgsql/bin$ ./pg_dump -Ft -s -c -v -f postgres schema_clean.tar1
pg_dump: error: could not open TOC file "postgres" for output: Permission denied

So you'd have to either make the binary writable or use "sudo" or something
to get in this situation, which is hopefully uncommon.

--
nathan

On Mon, Dec 08, 2025 at 01:22:48PM -0500, Tom Lane wrote:

Nathan Bossart <nathandbossart@gmail.com> writes:

On Mon, Dec 08, 2025 at 11:23:53PM +0530, tushar wrote:

Is there any way we can generate some error messages?

Perhaps it'd be worth making pg_dump a little more cautious about
overwriting existing files (or at least have the option to avoid that).

I think we'd get way more brickbats than kudos for that.

Yeah, I'm afraid you're right. We'd probably have to turn it on by default
to do any real amount of good, and there's undoubtedly someone depending on
the current behavior.

--
nathan

On Mon, Dec 8, 2025 at 11:50 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

tushar <tushar.ahuja@enterprisedb.com> writes:

I found a scenario where, after firing the wrong way of using the

pg_dump

command, not only server fail to start,
But later, I am not able to perform initdb/pg_ctl as well

The result is :
edb@1a1c15437e7c bin]$ ./pg_dump -Ft -s -c -v -f postgres

schema_clean.tar1

qemu: uncaught target signal 7 (Bus error) - core dumped

I think what you are showing here is that you ran this command in the
installation's bin directory, and where you write "-f postgres",
that caused pg_dump to overwrite the postgres executable.

Is there any way we can generate some error messages?

Don't do that. Generally speaking, you don't want installed files to
be writable at all by ordinary user accounts ... but if they are,
for heaven's sake don't cd into those directories before doing work.
You're just setting yourself up for trouble.

right, that was unintentional 😊, Instead of "postgres", if i give any

other name , i am getting an error e,g

[edb@1a1c15437e7c bin]$ ./pg_dump -Ft -s -c -v -f abc123
schema_clean.tar1
pg_dump: error: connection to server on socket "/tmp/.s.PGSQL.5432" failed:
FATAL: database "schema_clean.tar1" does not exist

So this query is a failed query and now if i give 'postgres' instead of
'abc123', Am I not supposed to get the same error , instead of
pg_dump overwriting the postgres executable.

regards,

tushar <tushar.ahuja@enterprisedb.com> writes:

So this query is a failed query and now if i give 'postgres' instead of
'abc123', Am I not supposed to get the same error , instead of
pg_dump overwriting the postgres executable.

No. You are supposed to be someone who knows better --- and if you
don't, you should not be running with write privileges on those
files. pg_dump has absolutely no way to know that that particular
output file is something important. Even if we tried to put that
knowledge into it, there are tiny variations of this case that
would still break, such as

./pg_dump ... >postgres

or for that matter

echo oops >postgres

There is no point in trying to prevent pg_dump from overwriting a
postgres executable when there are thousands of other ways to do
that, if you're foolish enough to not be more careful with file
permissions.

regards, tom lane

On Tue, Dec 9, 2025 at 11:12 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

There is no point in trying to prevent pg_dump from overwriting a
postgres executable when there are thousands of other ways to do
that, if you're foolish enough to not be more careful with file
permissions.

right. The responsibility for file caution and proper permissions rests

with the user.

regards,

On Monday, December 8, 2025, tushar <tushar.ahuja@enterprisedb.com> wrote:

So this query is a failed query and now if i give 'postgres' instead of
'abc123', Am I not supposed to get the same error , instead of
pg_dump overwriting the postgres executable.

The code chooses to initialize the archive first, then open the
connection. In hindsight, maybe that wasn’t the most user-friendly choice;
along with not having a “—clobber” option to overwrite an existing
archive. So, no, the error you get depends on whether you managed to
clobber the postgres service that is handling the connection attempt.

Personally I’d be fine with fixing both behaviors and accept any pushback
on making “—no-clobber” the new default; if someone were inclined to write
the patch. It’s a failure mode that seems sufficiently rare to not deal
with accommodating at this point though.

David J.

Hi,

This isn’t directly tied to the current thread, but it relates to the
discussion
about binaries and privileges.I have a question about the initdb success
message to start the server using pg_ctl. Can we update the -l logfile
suggestion it prints at the end to something like -l
/path/to/datadirectory/logfile instead?
Here’s the issue I’m seeing: when PostgreSQL is installed from packages
rather than built from source, the installation requires root privileges
(sudo).
That means directories like bin and lib are owned by root, and
non-superusers
can’t create new files there.
If someone runs initdb from inside the bin directory and then blindly
copy-pastes
the suggested pg_ctl command, pg_ctl will attempt to write the logfile into
the bin directory.
Since the user doesn’t have write permissions to that location, it fails.
Would it make sense for the success message to recommend a path inside
the data directory (or another writable location) instead of just -l
logfile,
which implies the current directory?, thoughts?

--
Thanks,
Srinath Reddy Sadipiralla
EDB: https://www.enterprisedb.com/

Srinath Reddy Sadipiralla <srinath2133@gmail.com> writes:

I have a question about the initdb success
message to start the server using pg_ctl. Can we update the -l logfile
suggestion it prints at the end to something like -l
/path/to/datadirectory/logfile instead?

"-l logfile" should be read as a recommendation to write to some
logfile, not as the literal text of the command. I don't think
that putting the log file into the data directory is good practice,
either.

Here’s the issue I’m seeing: when PostgreSQL is installed from packages
rather than built from source, the installation requires root privileges
(sudo).
That means directories like bin and lib are owned by root, and
non-superusers
can’t create new files there.
If someone runs initdb from inside the bin directory and then blindly
copy-pastes
the suggested pg_ctl command, pg_ctl will attempt to write the logfile into
the bin directory.

All of this seems to be predicated on the idea that someone would cd
into the bin directory and try to do work there. I don't understand
why we should regard that scenario as sufficiently probable to justify
contorting PG's behavior to make it fractionally less dangerous.

regards, tom lane