Horton
Menu

Thread

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

    tushar <tushar.ahuja@enterprisedb.com> — 2025-12-08T17:53:53Z

    Hi,
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)
"

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
qemu-x86_64:qemu-x86_64:qemu-x86_64:  QEMU internal SIGBUS {code=ADRERR,
addr=0x8c6b70}QEMU internal SIGBUS {code=ADRERR, addr=0x8c6b70}
QEMU internal SIGBUS {code=ADRERR, addr=0x8c6b70}
qemu-x86_64:qemu-x86_64:  QEMU internal SIGBUS {code=ADRERR, addr=0xa7cee0}
QEMU internal SIGBUS {code=ADRERR, addr=0xa7cee0}
qemu-x86_64: QEMU internal SIGBUS {code=ADRERR, addr=0xa7cee0}
qemu-x86_64:qemu-x86_64: QEMU internal SIGBUS {code=ADRERR, addr=0xa7cee0}
 QEMU internal SIGBUS {code=ADRERR, addr=0xa7cee0}
pg_dump: error: connection to server on socket "/tmp/.s.PGSQL.5432" failed:
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.

 The correct way is to use
./pg_dump -Ft -s -c   -v -f  schema_clean.tar1 postgres

Is there any way we can generate some error messages?

regards,

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

    Nathan Bossart <nathandbossart@gmail.com> — 2025-12-08T18:20:04Z

    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

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

    Tom Lane <tgl@sss.pgh.pa.us> — 2025-12-08T18:20:13Z

    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

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

    Tom Lane <tgl@sss.pgh.pa.us> — 2025-12-08T18:22:48Z

    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

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

    Nathan Bossart <nathandbossart@gmail.com> — 2025-12-08T18:23:28Z

    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

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

    Nathan Bossart <nathandbossart@gmail.com> — 2025-12-08T18:25:16Z

    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

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

    tushar <tushar.ahuja@enterprisedb.com> — 2025-12-09T05:32:51Z

    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,

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

    Tom Lane <tgl@sss.pgh.pa.us> — 2025-12-09T05:42:00Z

    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

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

    tushar <tushar.ahuja@enterprisedb.com> — 2025-12-09T05:53:03Z

    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,

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

    David G. Johnston <david.g.johnston@gmail.com> — 2025-12-09T06:22:15Z

    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.

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

    Srinath Reddy Sadipiralla <srinath2133@gmail.com> — 2025-12-09T16:27:08Z

    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/

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

    Tom Lane <tgl@sss.pgh.pa.us> — 2025-12-09T17:49:14Z

    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