On 12/13/24 08:46, Adrian Klaver wrote:
On 12/12/24 22:19, PopeRigby wrote:
On 12/10/24 21:22, Adrian Klaver wrote:
On 12/10/24 19:05, PopeRigby wrote:
If I am following correctly I believe you need this one:
https://www.postgresql.org/message-id/attachment/166859/v2-0002-Use-new-style-SQL
u can specify the option when you call pg_restore.
"
This means when you run the script with:
psql -d bustrac -f bustrac-2024-12-12.sql
it will clean out the current corrupted objects and replace them with those
in the backup file.
Adrian,
That's what I thought since I wrote the
On 12/13/24 11:18 AM, Rich Shepard wrote:
On Fri, 13 Dec 2024, Adrian Klaver wrote:
This needs more information:
1) Have you backed up your database at the current state?
Adrian,
No, the current state is FUBAR'd. The cron backup script runs each night at
11:15 p.m.
2) What comman
On Fri, 13 Dec 2024, Rich Shepard wrote:
#!/usr/bin/bash
The line was separated.
Rich
On Fri, 13 Dec 2024, Adrian Klaver wrote:
This needs more information:
1) Have you backed up your database at the current state?
Adrian,
No, the current state is FUBAR'd. The cron backup script runs each night at
11:15 p.m.
2) What command did you use to create bustrac-2024-12-1
On 12/13/24 11:15 AM, Rich Shepard wrote:
On Fri, 13 Dec 2024, Ron Johnson wrote:
It's a text file. Open it up, and see if there's a DROP DATABASE in
there.
Ron,
No `drop database' but it drops constraints and tables. I could add a drop
database to the backup script
On Fri, 13 Dec 2024, Ron Johnson wrote:
It's a text file. Open it up, and see if there's a DROP DATABASE in there.
Ron,
No `drop database' but it drops constraints and tables. I could add a drop
database to the backup script after restoring yesterday's status.
Thanks,
Rich
On 12/13/24 10:21 AM, Rich Shepard wrote:
I made a careless error this morning and want to restore the database from
yesterday's backup, `bustrac-2024-12-12.sql'. If I run
psql -d bustrac -f bustrac-2024-12-12.sql
will this restore the database to yesterday's status without
I made a careless error this morning and want to restore the database from
yesterday's backup, `bustrac-2024-12-12.sql'. If I run
psql -d bustrac -f bustrac-2024-12-12.sql
will this restore the database to yesterday's status without first
deleting/removing the FUBAR'd one?
TIA,
Rich
On 12/12/24 22:19, PopeRigby wrote:
On 12/10/24 21:22, Adrian Klaver wrote:
On 12/10/24 19:05, PopeRigby wrote:
If I am following correctly I believe you need this one:
https://www.postgresql.org/message-id/attachment/166859/v2-0002-Use-new-style-SQL-function-in-earthdistance-exten.patch
I
On 12/10/24 21:22, Adrian Klaver wrote:
On 12/10/24 19:05, PopeRigby wrote:
On 12/9/24 16:31, Adrian Klaver wrote:
On 12/9/24 15:30, PopeRigby wrote:
On 12/9/24 15:23, Tom Lane wrote:
Adrian Klaver writes:
You could file an issue here:
https://www.postgresql.org/account/login/?next=/account
On 12/10/24 19:05, PopeRigby wrote:
On 12/9/24 16:31, Adrian Klaver wrote:
On 12/9/24 15:30, PopeRigby wrote:
On 12/9/24 15:23, Tom Lane wrote:
Adrian Klaver writes:
You could file an issue here:
https://www.postgresql.org/account/login/?next=/account/submitbug/
Ask if the developers could u
On 12/9/24 16:31, Adrian Klaver wrote:
On 12/9/24 15:30, PopeRigby wrote:
On 12/9/24 15:23, Tom Lane wrote:
Adrian Klaver writes:
You could file an issue here:
https://www.postgresql.org/account/login/?next=/account/submitbug/
Ask if the developers could use the mechanisms available here:
htt
SELECT pg_catalog.set_config('search_path', 'public', false);
What if this had been a pg_dump --format={custom,directory} backup?
pg_restore has a mode where it can dump out SQL to a script instead
of directly restoring to the database.
That Would Be
erences.
>>>
>>> For now in the dump file you could search for
>>>
>>> SELECT pg_catalog.set_config('search_path', '', false);
>>>
>>> and set to
>>>
>>> SELECT pg_catalog.set_config('search_path',
#x27;search_path', '', false);
>>
>> and set to
>>
>> SELECT pg_catalog.set_config('search_path', 'public', false);
>>
>
> What if this had been a pg_dump --format={custom,directory} backup?
>
pg_restore has a mode where it can dump out SQL to a script instead of
directly restoring to the database.
David J.
talog.set_config('search_path', 'public', false);
>
What if this had been a pg_dump --format={custom,directory} backup?
--
Death to , and butter sauce.
Don't boil me, I'm still alive.
lobster!
On 12/9/24 15:30, PopeRigby wrote:
On 12/9/24 15:23, Tom Lane wrote:
Adrian Klaver writes:
You could file an issue here:
https://www.postgresql.org/account/login/?next=/account/submitbug/
Ask if the developers could use the mechanisms available here:
https://www.postgresql.org/docs/current/ext
On 12/9/24 15:23, Tom Lane wrote:
Adrian Klaver writes:
You could file an issue here:
https://www.postgresql.org/account/login/?next=/account/submitbug/
Ask if the developers could use the mechanisms available here:
https://www.postgresql.org/docs/current/extend-extensions.html#EXTEND-EXTENSION
On 12/9/24 15:23, Tom Lane wrote:
Adrian Klaver writes:
You could file an issue here:
https://www.postgresql.org/account/login/?next=/account/submitbug/
Ask if the developers could use the mechanisms available here:
https://www.postgresql.org/docs/current/extend-extensions.html#EXTEND-EXTENSION
Adrian Klaver writes:
> You could file an issue here:
> https://www.postgresql.org/account/login/?next=/account/submitbug/
> Ask if the developers could use the mechanisms available here:
> https://www.postgresql.org/docs/current/extend-extensions.html#EXTEND-EXTENSIONS-RELOCATION
This wouldn't r
On 12/9/24 14:47, Adrian Klaver wrote:
On 12/9/24 14:14, PopeRigby wrote:
On 12/7/24 11:58, David G. Johnston wrote:
On Sat, Dec 7, 2024 at 12:25 PM PopeRigby
wrote:
It actually looks like setting those all to have public fixed
all the
errors, including the one with lldap. So, how
On 12/9/24 14:14, PopeRigby wrote:
On 12/7/24 11:58, David G. Johnston wrote:
On Sat, Dec 7, 2024 at 12:25 PM PopeRigby wrote:
It actually looks like setting those all to have public fixed all the
errors, including the one with lldap. So, how can I get it to not put
public there a
On 12/9/24 14:31, David G. Johnston wrote:
On Mon, Dec 9, 2024 at 3:14 PM PopeRigby wrote:
On 12/7/24 11:58, David G. Johnston wrote:
On Sat, Dec 7, 2024 at 12:25 PM PopeRigby
wrote:
It actually looks like setting those all to have public fixed
all the
er
On Mon, Dec 9, 2024 at 3:14 PM PopeRigby wrote:
> On 12/7/24 11:58, David G. Johnston wrote:
>
> On Sat, Dec 7, 2024 at 12:25 PM PopeRigby wrote:
>
>>
>> It actually looks like setting those all to have public fixed all the
>> errors, including the one with lldap. So, how can I get it to not put
On 12/7/24 11:58, David G. Johnston wrote:
On Sat, Dec 7, 2024 at 12:25 PM PopeRigby wrote:
It actually looks like setting those all to have public fixed all the
errors, including the one with lldap. So, how can I get it to not put
public there automatically for next time?
I assu
On Sat, Dec 7, 2024 at 12:25 PM PopeRigby wrote:
>
> It actually looks like setting those all to have public fixed all the
> errors, including the one with lldap. So, how can I get it to not put
> public there automatically for next time?
>
>
I assume you mean "get it to put public there" (i.e.,
earch_path setting *would* be enough to get you past that.
Having said that, the CREATE should have been seeing the new-style
definition of ll_to_earth() if the 1.2 version of earthdistance
was correctly installed.
regards, tom lane
So, is there anything I can do to fix this particu
On Thursday, December 5, 2024, Ron Johnson wrote:
> On Thu, Dec 5, 2024 at 6:24 PM David G. Johnston <
> david.g.johns...@gmail.com> wrote:
>
>> On Thu, Dec 5, 2024 at 4:04 PM Ron Johnson
>> wrote:
>>
>>> Another alternative is to open the .sql file in Notepad++, then add
>>> "public." before al
On 12/5/24 18:44, Ron Johnson wrote:
On Thu, Dec 5, 2024 at 6:24 PM David G. Johnston
mailto:david.g.johns...@gmail.com>> wrote:
On Thu, Dec 5, 2024 at 4:04 PM Ron Johnson mailto:ronljohnso...@gmail.com>> wrote:
Another alternative is to open the .sql file in Notepad++, then
On Thu, Dec 5, 2024 at 6:24 PM David G. Johnston
wrote:
> On Thu, Dec 5, 2024 at 4:04 PM Ron Johnson
> wrote:
>
>> Another alternative is to open the .sql file in Notepad++, then add
>> "public." before all the unqualified "earth" and "ll_to_earth" references.
>>
>
> And as discussed there are n
On Thu, Dec 5, 2024 at 4:04 PM Ron Johnson wrote:
> Another alternative is to open the .sql file in Notepad++, then add
> "public." before all the unqualified "earth" and "ll_to_earth" references.
>
And as discussed there are none in that file because those references are
within an extension's o
gt; > search_path setting *would* be enough to get you past that.
> >
> > Having said that, the CREATE should have been seeing the new-style
> > definition of ll_to_earth() if the 1.2 version of earthdistance
> > was correctly installed.
> >
> >
t you past that.
Having said that, the CREATE should have been seeing the new-style
definition of ll_to_earth() if the 1.2 version of earthdistance
was correctly installed.
regards, tom lane
So, is there anything I can do to fix this particular backup? I'm kind
of stuck her
the CREATE should have been seeing the new-style
definition of ll_to_earth() if the 1.2 version of earthdistance
was correctly installed.
regards, tom lane
So, is there anything I can do to fix this particular backup? I'm kind
of stuck here. There's also the i
On 12/2/24 17:17, Tom Lane wrote:
PopeRigby writes:
On 12/1/24 12:15, Tom Lane wrote:
Cool. You did actually install the new scripts into your target
installation, right?
Oh, is applying the patch and rebuilding PostgreSQL not enough?
Not unless you did "make install" in the contrib/earthdi
PopeRigby writes:
> On 12/1/24 12:15, Tom Lane wrote:
>> Cool. You did actually install the new scripts into your target
>> installation, right?
> Oh, is applying the patch and rebuilding PostgreSQL not enough?
Not unless you did "make install" in the contrib/earthdistance
directory (or somethi
On 12/1/24 12:15, Tom Lane wrote:
Cool. You did actually install the new scripts into your target
installation, right?
Oh, is applying the patch and rebuilding PostgreSQL not enough?
Adrian Klaver writes:
> On 12/1/24 13:14, Tom Lane wrote:
>> It would be useful to know what is the command at line 4102
>> of all.sql.
> It is here:
> https://gist.github.com/poperigby/fcb59eb6c22c6051800e06a0ec482b49
> CREATE TABLE public.geodata_places (
> id integer NOT NULL,
> na
On 12/1/24 13:14, Tom Lane wrote:
Adrian Klaver writes:
On 12/1/24 12:05, PopeRigby wrote:
I'm still getting this error:
psql:all.sql:4102: ERROR: type "earth" does not exist
LINE 1: ...ians($1))*sin(radians($2))),earth()*sin(radians($1)))::earth
The issue is still this:
SELECT pg_catalog
Adrian Klaver writes:
> On 12/1/24 12:05, PopeRigby wrote:
>> I'm still getting this error:
>>
>> psql:all.sql:4102: ERROR: type "earth" does not exist
>> LINE 1: ...ians($1))*sin(radians($2))),earth()*sin(radians($1)))::earth
> The issue is still this:
> SELECT pg_catalog.set_config('search_pa
On 12/1/24 12:05, PopeRigby wrote:
On 11/30/24 19:58, Tom Lane wrote:
"David G. Johnston" writes:
Ok, so the error is not emanating from your code but rather the body
of the
ll_to_earth function defined in the earthdistance extension.
Yeah. That is
CREATE FUNCTION ll_to_earth(float8, float
PopeRigby writes:
> I've applied the following patch to postgres:
> https://www.postgresql.org/message-id/attachment/122092/0002-earthdistance-sql-functions.patch
Cool. You did actually install the new scripts into your target
installation, right?
> I'm still getting this error:
> psql:all.sql:
On 11/30/24 19:58, Tom Lane wrote:
"David G. Johnston" writes:
Ok, so the error is not emanating from your code but rather the body of the
ll_to_earth function defined in the earthdistance extension.
Yeah. That is
CREATE FUNCTION ll_to_earth(float8, float8)
RETURNS earth
LANGUAGE SQL
IMMUTAB
"David G. Johnston" writes:
> Ok, so the error is not emanating from your code but rather the body of the
> ll_to_earth function defined in the earthdistance extension.
Yeah. That is
CREATE FUNCTION ll_to_earth(float8, float8)
RETURNS earth
LANGUAGE SQL
IMMUTABLE STRICT
PARALLEL SAFE
AS 'SELECT
On Saturday, November 30, 2024, PopeRigby wrote:
>
> Ok, so the error is not emanating from your code but rather the body of
> the ll_to_earth function defined in the earthdistance extension.
>
> David J.
>
> By code do you mean my sql file created by pg_dumpall? Sorry, I'm just a
> self-hoster s
On 11/30/24 19:45, David G. Johnston wrote:
On Saturday, November 30, 2024, PopeRigby wrote:
On 11/30/24 18:41, David G. Johnston wrote:
On Saturday, November 30, 2024, PopeRigby
wrote:
On 11/30/24 17:27, David G. Johnston wrote:
On Saturday, November 30, 2024, P
On Saturday, November 30, 2024, PopeRigby wrote:
> On 11/30/24 18:41, David G. Johnston wrote:
>
> On Saturday, November 30, 2024, PopeRigby wrote:
>
>> On 11/30/24 17:27, David G. Johnston wrote:
>>
>> On Saturday, November 30, 2024, PopeRigby wrote:
>>
>>> On 11/29/24 17:47, Adrian Klaver wro
CREATE EXTENSION cube;
I do not know if you might need this one as well. I am assuming that you
are working on a gist server.
CREATE EXTENSION earthdistance;
I am assuming you are working with a gist server. This ought to be useful.
https://gist.cs.berkeley.edu/pggist/
You might want to read t
On 11/30/24 18:41, David G. Johnston wrote:
On Saturday, November 30, 2024, PopeRigby wrote:
On 11/30/24 17:27, David G. Johnston wrote:
On Saturday, November 30, 2024, PopeRigby
wrote:
On 11/29/24 17:47, Adrian Klaver wrote:
On 11/29/24 17:34, PopeRigby wrot
On 11/30/24 19:26, PopeRigby wrote:
On 11/30/24 18:41, David G. Johnston wrote:
On Saturday, November 30, 2024, PopeRigby wrote:
On 11/30/24 17:27, David G. Johnston wrote:
On Saturday, November 30, 2024, PopeRigby
wrote:
On 11/29/24 17:47, Adrian Klaver wrote:
On 11/30/24 18:41, David G. Johnston wrote:
On Saturday, November 30, 2024, PopeRigby wrote:
On 11/30/24 17:27, David G. Johnston wrote:
On Saturday, November 30, 2024, PopeRigby
wrote:
On 11/29/24 17:47, Adrian Klaver wrote:
On 11/29/24 17:34, PopeRigby wrot
On Saturday, November 30, 2024, PopeRigby wrote:
> On 11/30/24 17:27, David G. Johnston wrote:
>
> On Saturday, November 30, 2024, PopeRigby wrote:
>
>> On 11/29/24 17:47, Adrian Klaver wrote:
>>
>>> On 11/29/24 17:34, PopeRigby wrote:
>>>
>>> psql:all.sql:4104: ERROR: type "earth" does not exi
On 11/30/24 17:27, David G. Johnston wrote:
On Saturday, November 30, 2024, PopeRigby wrote:
On 11/29/24 17:47, Adrian Klaver wrote:
On 11/29/24 17:34, PopeRigby wrote:
psql:all.sql:4104: ERROR: type "earth" does not exist
LINE 1:
...ians($1))*sin(radians(
On Saturday, November 30, 2024, PopeRigby wrote:
> On 11/29/24 17:47, Adrian Klaver wrote:
>
>> On 11/29/24 17:34, PopeRigby wrote:
>>
>> psql:all.sql:4104: ERROR: type "earth" does not exist
>> LINE 1: ...ians($1))*sin(radians($2))),earth()*sin(radians($1)))::earth
>>
>> QUERY: SELECT cube(cub
On 11/29/24 17:47, Adrian Klaver wrote:
On 11/29/24 17:34, PopeRigby wrote:
My HDD recently failed so I'm trying to restore my backup, but I'm
running into some errors.
I've been using a systemd service that periodically backs up my
cluster with pg_dumpall, and I'm u
On 11/29/24 17:34, PopeRigby wrote:
My HDD recently failed so I'm trying to restore my backup, but I'm
running into some errors.
I've been using a systemd service that periodically backs up my cluster
with pg_dumpall, and I'm using this command to restore:
sudo psql -f
On Fri, Nov 29, 2024 at 8:35 PM PopeRigby wrote:
> My HDD recently failed so I'm trying to restore my backup, but I'm
> running into some errors.
>
> I've been using a systemd service that periodically backs up my cluster
> with pg_dumpall, and I'm using this c
My HDD recently failed so I'm trying to restore my backup, but I'm
running into some errors.
I've been using a systemd service that periodically backs up my cluster
with pg_dumpall, and I'm using this command to restore:
sudo psql -f backup.sql postgres
I'm ge
Hello.
I try to use pg_basebackup to make backup and recover master and replica
from it.
I recover master with action "promote". Next, I recover replica from the
same
backup with action "shutdown". After it, I start replica with configured
connection
and replication slot
Postgres I
> > only keep 6 months live on the mssql db and roll everything else to
> > Postgres Arch DB.
> >
> >After I load this latest month to Postgres I just need to backup, or
> > should I just retain my .csv files as a Backup... I have 2 tables that I
&g
load this latest month to Postgres I just need to backup, or
should I just retain my .csv files as a Backup... I have 2 tables that I
load to Hist and one table holds the images...
Your choice, though the factors I would consider would be:
1) The process you use to load the CSV files into Postgres a
I'm using the DB as a History repository... I'm pulling info from a Mssql
db using a P/S script to a csv file then Import that to Postgres I only
keep 6 months live on the mssql db and roll everything else to Postgres
Arch DB.
After I load this latest month to Postgres I just need to
On 10/23/24 07:07, Andy Hartman wrote:
I have been testing different backup methods suggested and wonder if I
have all my files used to load the DB .. could that be considered a
backup... obviously need to have schema backup in case of problem, but
that seems to be easily re-created
Thoughts
I have been testing different backup methods suggested and wonder if I have
all my files used to load the DB .. could that be considered a backup...
obviously need to have schema backup in case of problem, but that seems to
be easily re-created
Thoughts?
On Fri, Oct 18, 2024 at 2:30 PM Adrian
On 10/18/24 11:25 AM, Andy Hartman wrote:
Windows Server 2022
I would like a backup process similar to what I'm used to using in the
mssql world if that's possible with Postgres... I will be
loading monthly archive data to Postgresql so that's why I probably only
nee
Windows Server 2022
I would like a backup process similar to what I'm used to using in the
mssql world if that's possible with Postgres... I will be loading monthly
archive data to Postgresql so that's why I probably only need once a backup
.. once loaded data is just viewed th
On 10/18/24 05:39, Andy Hartman wrote:
I would like to use the closest thing to a mssql backup...
As in?
Searching on 'mssql backup' returns a lot of choices. You will need to
be more specific on what you want to achieve. Also be specific about
what versions of OS and Postgr
On 10/18/24 09:52, Andy Hartman wrote:
Reply to list also
Ccing list.
Windows 22 and Postgres 16.4
Is that Windows Server 2022 or Windows 10/11 with the 22H2 update?
You also need to provide a more detailed description of what you want
the backup to do?
On Fri, Oct 18, 2024 at 12
On 10/18/24 08:34, Andy Hartman wrote:
Thanks.. I'm on a Windows platform using PG.
AFAIK pgBackRest does not run on Windows:
https://github.com/pgbackrest/pgbackrest/issues/2431
--
Adrian Klaver
adrian.kla...@aklaver.com
Thanks.. I'm on a Windows platform using PG.
On Fri, Oct 18, 2024 at 10:45 AM Adrian Klaver
wrote:
> On 10/18/24 05:39, Andy Hartman wrote:
> > I would like to use the closest thing to a mssql backup...
> >
> > How do I install pgbackrest after downloading an
On 10/18/24 05:39, Andy Hartman wrote:
I would like to use the closest thing to a mssql backup...
How do I install pgbackrest after downloading and UnZip?
Read the docs?:
https://pgbackrest.org/user-guide.html#installation
--
Adrian Klaver
adrian.kla...@aklaver.com
I would like to use the closest thing to a mssql backup...
How do I install pgbackrest after downloading and UnZip?
On Thu, Oct 17, 2024 at 6:28 AM Andy Hartman
wrote:
> This is great, thank you so much!
>
> On Thu, Oct 17, 2024 at 12:47 AM Asad Ali wrote:
>
>>
>&g
ne's multiple CPUs by using parallel jobs:
>
> pg_dump -Fc -Z 9 -j 4 --blobs -f /path/to/backup/file.dump
> your_database_name
>
>- -Fc: Custom format (supports compression and flexible restore
>options).
>- -Z 9: Maximum compression level (0-9 scale).
>- -j
on*
A more efficient option would be to use the custom format (-Fc) with
compression. You can also adjust the compression level and make use of your
machine's multiple CPUs by using parallel jobs:
pg_dump -Fc -Z 9 -j 4 --blobs -f /path/to/backup/file.dump
your_database_name
- -Fc: Cus
Hi,
you can refer the following link where many backup methods are mentioned
according to your need.
Backups in PostgreSQL. In PostgreSQL, different types of… | by Usman Khan |
Aug, 2024 | Medium
<https://medium.com/@usman.khan9805/backups-in-postgresql-2fca57c2872b>
On Thu, 17 Oct 2024
I'm on Ver16 and yes Our database has image in a bytea field.
Running on Win22 box...
On Wed, Oct 16, 2024 at 5:49 PM Peter J. Holzer wrote:
> On 2024-10-16 16:02:24 -0400, Ron Johnson wrote:
> > On Wed, Oct 16, 2024 at 4:00 PM Achilleas Mantzios <
> > a.mantz...@cloud.gatewaynet.com> wrote:
>
On 2024-10-16 16:02:24 -0400, Ron Johnson wrote:
> On Wed, Oct 16, 2024 at 4:00 PM Achilleas Mantzios <
> a.mantz...@cloud.gatewaynet.com> wrote:
> Στις 16/10/24 22:55, ο/η Ron Johnson έγραψε:
> On Wed, Oct 16, 2024 at 3:37 PM Andy Hartman
> wrote:
[...]
>
> Step 1: re
hing like
pg_dump -Fc | gzip -c > compressed.dump.gz
However, be aware that pg_dump is more an export tool than a backup
suitable for large databases / quick recovery. It won't allow doing PITR
and similar stuff.
regards
--
Adrian Klaver
adrian.kla...@aklaver.com
world. I'm looking for suggestions on DB backups. I currently
have a DB used to store Historical information that has
images it's currently around 100gig.
I'm looking to take a monthly backup as I archive a month of
data at a time. I am looki
l world. I'm
>> looking for suggestions on DB backups. I currently have a DB used to store
>> Historical information that has images it's currently around 100gig.
>>
>> I'm looking to take a monthly backup as I archive a month of data at a
>> time. I am looki
On Wed, Oct 16, 2024 at 3:52 PM Tomas Vondra wrote:
[snip]
> You didn't specify the Postgres version - that matters, because older
> pg_dump versions (before PG 16) do not support compression. Since PG 16
> you can use either -Fc or -Fd (instead of the tar format), and it'll
> compress the output
t has images it's
currently around 100gig.
I'm looking to take a monthly backup as I archive a month of data
at a time. I am looking for it to be compressed and have a machine
that has multiple cpu's and ample memory.
Suggestions on things I can try ?
I did a
>
> I'm looking to take a monthly backup as I archive a month of data at a
> time. I am looking for it to be compressed and have a machine that has
> multiple cpu's and ample memory.
>
> Suggestions on things I can try ?
> I did a pg_dump using these parms
> --format=
27;m looking to take a monthly backup as I archive a month of data at a
> time. I am looking for it to be compressed and have a machine that has
> multiple cpu's and ample memory.
>
> Suggestions on things I can try ?
> I did a pg_dump using these parms
> --format=t
I am very new to Postgres and have always worked in the mssql world. I'm
looking for suggestions on DB backups. I currently have a DB used to store
Historical information that has images it's currently around 100gig.
I'm looking to take a monthly backup as I archive a month of da
On 10/7/24 22:42, Cassandra Thrift wrote:
Hello Team,
We are facing a segfault issue while initiating backup with pg_dump.
This is for Postgresql community version 12.5 and rhel 7.4 (PostgreSQL
12.5 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red
Hat 4.8.5-39), 64-bit)
FYI
On Wed, Oct 9, 2024 at 4:08 AM Cassandra Thrift
wrote:
> Hello Team,
>
> We are facing a segfault issue while initiating backup with pg_dump.
> This is for Postgresql community version 12.5 and rhel 7.4 (PostgreSQL
> 12.5 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20
Hello Team,
We are facing a segfault issue while initiating backup with pg_dump.
This is for Postgresql community version 12.5 and rhel 7.4 (PostgreSQL 12.5
on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat
4.8.5-39), 64-bit)
The below error is showing :
from /var/log
e-walkthrough-7a0aade69b1c>
>
> On Mon, 7 Oct 2024 at 20:48, Andy Hartman wrote:
>
>> anyone use Powershell in an automated fashion to do DB backup? Would you
>> share your example?
>>
>> Thanks.
>>
>
b: The Complete Walkthrough |
by Usman Khan | Sep, 2024 | Medium
<https://medium.com/@usman.khan9805/automating-postgresql-backups-with-pg-back-web-the-complete-walkthrough-7a0aade69b1c>
On Mon, 7 Oct 2024 at 20:48, Andy Hartman wrote:
> anyone use Powershell in an automated fashion
On Mon, Oct 7, 2024 at 11:48 AM Andy Hartman
wrote:
> anyone use Powershell in an automated fashion to do DB backup? Would you
> share your example?
>
PS can execute utilities, so using it as a wrapper for pg_dump and
pg_restore (just like a bash script) is perfectly viable.
--
On 10/7/24 08:48, Andy Hartman wrote:
anyone use Powershell in an automated fashion to do DB backup? Would
you share your example?
Search engine of your choice: "powershell postgresql backup script"
Using DuckDuckGo I see 6 relevant entries right of the top.
Thanks.
--
Adr
anyone use Powershell in an automated fashion to do DB backup? Would you
share your example?
Thanks.
>
> database size: 146.9GB, database backup size: 146.9GB
> repo1: backup size: 20.6GB
It looks to me as though everything is working as expected. You took a full
backup of your system, which was around 147GB - most of which is in a
tablespace. It got compressed down to 20GB. You then
List,
pgbackrest backup what all the directories and files PgBackRest will
backup to RepoServer when performing backup using PgBackRest. ( Because of
a limited infr ( N/W bandwidth 8Mbps between DB Server and RepoServer) .
1. I am not sure the pgbackrest command finished output message in
On Thu, Aug 29, 2024 at 12:08 PM KK CHN wrote:
>
> On Thu, Aug 29, 2024 at 6:54 PM Greg Sabino Mullane
> wrote:
>
>> On Thu, Aug 29, 2024 at 2:21 AM KK CHN wrote:
>>
>>> I am doing a full backup using PgBackRest from a production server to
>>> Rep
On Thu, Aug 29, 2024 at 6:54 PM Greg Sabino Mullane
wrote:
> On Thu, Aug 29, 2024 at 2:21 AM KK CHN wrote:
>
>> I am doing a full backup using PgBackRest from a production server to
>> Reposerver.
>>
> ...
>
>> If so, does the backup process start again fro
On Thu, Aug 29, 2024 at 2:21 AM KK CHN wrote:
> I am doing a full backup using PgBackRest from a production server to
> Reposerver.
>
...
> If so, does the backup process start again from scratch ? or it
> resumes from where the backup process is stopped ?
>
It resum
List,
I am doing a full backup using PgBackRest from a production server to
Reposerver.
My connection is IPSec VPN over ILL ( 8 Mbps link) between the
Production DB Server and the remote RepoServer.
I understood the bottleneck of 8 Mbps between servers. (Server NICs 10Gbps
and switch
1 - 100 of 557 matches
Mail list logo
