Sure. I will try that.
On Tue, Feb 23, 2021 at 4:42 PM Adrian Klaver
wrote:
> On 2/23/21 4:25 PM, Santosh Udupi wrote:
> > Yes, this is what we have been doing now:- Backup using pg_dump, create
> > the new database at the destination, manually create the tables which
> > give problems, and the
On 2/23/21 4:25 PM, Santosh Udupi wrote:
Yes, this is what we have been doing now:- Backup using pg_dump, create
the new database at the destination, manually create the tables which
give problems, and then do the pg_restore. Another solution for us is to
Well that introduces another error,
Yes, this is what we have been doing now:- Backup using pg_dump, create
the new database at the destination, manually create the tables which give
problems, and then do the pg_restore. Another solution for us is to backup
using pg_dump that comes with pgAdmin (Windows), rsync it to the
destination
On 2/23/21 12:57 PM, Santosh Udupi wrote:
So that it makes it a lot easier for the application logic just to
collect json fields and update in one column "info" instead of including
multiple columns in the insert/update statements.
I doubt it, but then again this why I don't answer Postgres/JS
So that it makes it a lot easier for the application logic just to collect
json fields and update in one column "info" instead of including multiple
columns in the insert/update statements.
On Tue, Feb 23, 2021 at 12:20 PM Adrian Klaver
wrote:
> On 2/23/21 12:15 PM, Santosh Udupi wrote:
> > Here
On 2/23/21 12:15 PM, Santosh Udupi wrote:
Here is my table structure. I will try to get the pg_dump output for
this table in both the versions.
create table tbl_main(
item_id int GENERATED ALWAYS AS IDENTITY,
-
operating_offices i
Here is my table structure. I will try to get the pg_dump output for this
table in both the versions.
create table tbl_main(
item_id int GENERATED ALWAYS AS IDENTITY,
-
operating_offices int [] GENERATED ALWAYS AS (
nullif(array[(info->>'o')::in
Santosh Udupi writes:
> Both are different versions
> The following works:
> Version: pg_dump (pgAdmin Windows) version:13.1
> The following does not work: (Does not populate the generated column
> values)
> Version: pg_dump (PostgreSQL v13.2 on Ubuntu 20.04) version 13.2
Hmm ... well, that wo
Both are different versions
The following works:
Version: pg_dump (pgAdmin Windows) version:13.1
Method: Backup using Windows connecting to the remote host:
Command: pg_dump -Fc -p 5432 -h -d mydb > mydb.backup1 -U
postgres
Restore locally on Ubuntu : pg_restore -d mydb-restore mydb.backu
Santosh Udupi writes:
> Right. pg_dump under the pgAdmin runtime folder works perfectly. pg_dump
> in postgres13 (ubuntu) does not work. Exact same syntax.
So, are these identical pg_dump versions? We did fix some things
in this area in 13.2.
regards, tom lane
Right. pg_dump under the pgAdmin runtime folder works perfectly. pg_dump
in postgres13 (ubuntu) does not work. Exact same syntax.
When I try to restore, the backup that was taken using pgAdmin's version
restores properly but the one taken using postgres13's pg_dump, restores
the database but does
On 2/23/21 7:39 AM, Santosh Udupi wrote:
Got it. Must be the version difference. I run pgAdmin on Windows PC but
direct pg_dump on Ubuntu 20.04.
The OS does not really make a difference it is the pg_dump/restore
versions and the Postgres server(s) versions that are important.
On Tue, Feb 2
Got it. Must be the version difference. I run pgAdmin on Windows PC but
direct pg_dump on Ubuntu 20.04.
On Tue, Feb 23, 2021 at 7:27 AM Adrian Klaver
wrote:
> On 2/23/21 6:36 AM, Santosh Udupi wrote:
> > The pg_restore command is actually pg_restore -Ft -d mydb mydb.tar (my
> > mistake).
> >
> >
On 2/23/21 6:36 AM, Santosh Udupi wrote:
The pg_restore command is actually pg_restore -Ft -d mydb mydb.tar (my
mistake).
I didn't provide the -h -p -U since I use the super user account to
restore (I will try adding them). The restore had always worked until I
altered the table in the source
The pg_restore command is actually pg_restore -Ft -d mydb mydb.tar (my
mistake).
I didn't provide the -h -p -U since I use the super user account to restore
(I will try adding them). The restore had always worked until I altered the
table in the source database.
After I added the column, the res
On 2/22/21 7:43 PM, Santosh Udupi wrote:
If I backup using pgAdmin, I am able to restore using pg_restore but for
some reason, pg_rsestore on the output from pg_dump does not create
values for the generated columns
To troubleshoot this:
1) Stick to one dump/restore combination. The three ve
If I backup using pgAdmin, I am able to restore using pg_restore but for
some reason, pg_rsestore on the output from pg_dump does not create values
for the generated columns
On Mon, Feb 22, 2021 at 6:20 PM Santosh Udupi wrote:
> The logs don't show errors. I came across something similar here
>
The logs don't show errors. I came across something similar here
https://www.postgresql-archive.org/Dumping-restoring-fails-on-inherited-generated-column-td6114378.html
but not sure what the solution is.
On Mon, Feb 22, 2021 at 5:57 PM Santosh Udupi wrote:
> I used the following commands for d
I used the following commands for dump
pg_dump -c mydb | gzip -9 > mydb.gz
pg_dump -C -Fc mydb > mydb.backup
pg_dump -Ft mydb > mydb.tar
For restore, I created a blank database by issuing the command "createdb
mydb" and then tried
gunzip -c mydb.gz | psql mydb
pg_restore -d mydb mydb.backup
pg_r
On 2/22/21 5:08 PM, Santosh Udupi wrote:
Hi all,
My database has tables with generated columns. I altered a table and
added a generated column as below:
alter table billing add primary_bill_to_id int GENERATED ALWAYS as
((info->>'vp')::int) stored
Now, when I do the pg_dump and pg
Hi all,
My database has tables with generated columns. I altered a table and added
a generated column as below:
alter table billing add primary_bill_to_id int GENERATED ALWAYS as
((info->>'vp')::int) stored
Now, when I do the pg_dump and pg_restore, this column does not get
populated. It rema
21 matches
Mail list logo
