On Wed, Jan 7, 2026 at 1:52 PM tushar <[email protected]> wrote:

>
>
> On Tue, Jan 6, 2026 at 11:56 AM Mahendra Singh Thalor <[email protected]>
> wrote:
>
>>
>>
>>
>> We have another thread for this. We have patches also. Last year, we
>> planned to block these databases at creation time.
>>
>> >
>> > It's probably harmless, we connect to the databases further down to do
>> actual work. But it's also not nice. The toc.glo seems to have a bunch of
>> extraneous entries of type COMMENT and CONNECT. Why is that? As far as
>> poible this should have output pretty much  identical to a plain pg_dumpall.
>> >
>> >
>> > cheers
>> >
>> >
>> > andrew
>>
>> If we don't dump those comments in non-text format, then the output of
>> "pg_restore -f filename dump_non_text" will not be the same as the
>> plain dump of pg_dumpall.
>>
>> Here, I am attaching an updated patch for the review and testing.
>>
>>
> Hi Mahendra,
>
> I found a scenario  in which the table is not
> restored if --transaction-size switch is used  at the time of pg_restore
> operation
>
> Please refer this scenario:
> Case A --pg_restore operation with "--transaction-size" against the  dump
> (taken using pg_dump) -
> create a table ( create table t(n int); )
> perform pg_dump ( ./pg_dump -Ft postgres -f xyz.tar)
> create a database (create database test;)
> perform pg_restore using switch "--transaction-size" ( ./pg_restore
> --transaction-size=1 -d test xyz.tar)
> table is restored into test database
>
> Case B --pg_restore operation with "--transaction-size" against the  dump
> (taken using pg_dumpall) -
> create a table ( create table t(n int); )
> perform pg_dumpall ( ./pg_dumpall -Ft -f abc.tar)
> create a new cluster, start the server against a different port
> perform pg_restore using switch "--transaction-size" (./pg_restore -Ft
> --transaction-size=10 -d postgres abc.tar -p 9000 -C)
> table is not restored
>
> if i remove --transaction-size switch then this works.
>
> right, it seems like we are encountering a recurring issue where
pg_restore operations fail if the user account already exists
in the target database and due to that got this error:
pg_restore: error: could not execute query: ERROR:  role "xyz" already
exists

We need to implement a check to handle existing roles gracefully.

regards,

Reply via email to