Обсуждение: 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

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

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.

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