Re: To take backup of Postgresql Database without large objects

2025-04-11 Thread David G. Johnston
On Friday, April 11, 2025, Adrian Klaver wrote: > On 4/11/25 22:06, sivapostg...@yahoo.com wrote: > > Either my command should be wrong or I'm missing something. >> > > This was explained in my post as quoted below. Yeah, the short version. Then you added a long version that just confused the

Re: To take backup of Postgresql Database without large objects

2025-04-11 Thread Adrian Klaver
On 4/11/25 22:06, sivapostg...@yahoo.com wrote: Either my command should be wrong or I'm missing something. This was explained in my post as quoted below. Happiness Always BKR Sivaprakash On Friday 11 April, 2025 at 08:31:31 pm IST, Adrian Klaver wrote: On 4/11/25 05:55, sivapostg...

Re: To take backup of Postgresql Database without large objects

2025-04-11 Thread Christophe Pettus
> On Apr 11, 2025, at 22:34, sivapostg...@yahoo.com wrote: > Then I've misunderstood large objects. Is there document to explain large > objects? Large objects are a relatively old and now little-used feature of PostgreSQL that predates the bytea type: https://www.postgresql.org/d

Re: To take backup of Postgresql Database without large objects

2025-04-11 Thread sivapostg...@yahoo.com
Thanks.Then I've misunderstood large objects.  Is there document to explain large objects?  We store images in bytea column. Happiness Always BKR Sivaprakash On Saturday 12 April, 2025 at 10:44:21 am IST, David G. Johnston wrote: On Friday, April 11, 2025, sivapostg...@yahoo.com wrot

Re: To take backup of Postgresql Database without large objects

2025-04-11 Thread David G. Johnston
On Friday, April 11, 2025, sivapostg...@yahoo.com wrote: > > > bytea field also included in the backup. > Bytea typed columns are completely separate things than large objects. You cannot exclude individual columns using pg_dump. David J.

Re: To take backup of Postgresql Database without large objects

2025-04-11 Thread sivapostg...@yahoo.com
I tried all the combinations, as mentioned in the documenthttps://www.postgresql.org/docs/current/app-pgdump.html "E:\DBBackup\bin\pg_dump.exe" -h 192.168.1.1 -p 5432 -U --no-blobs -F c -v -f "E:\DBBackup\demo6_110420251637.bak" demo6  "E:\DBBackup\bin\pg_dump.exe" -h 192.168.1.1 -p 5432 -U

Re: Clarification on the docs

2025-04-11 Thread David G. Johnston
On Friday, April 11, 2025, Igor Korot wrote: > Hi, David, > > On Fri, Apr 11, 2025 at 9:04 PM David G. Johnston < > david.g.johns...@gmail.com> wrote: > >> On Fri, Apr 11, 2025 at 6:49 PM Igor Korot wrote: >> >>> Hi, ALL, >>> On the https://www.postgresql.org/docs/17/sql-createindex.html# >>> SQ

Re: Clarification on the docs

2025-04-11 Thread Igor Korot
Hi, David, On Fri, Apr 11, 2025 at 9:04 PM David G. Johnston < david.g.johns...@gmail.com> wrote: > On Fri, Apr 11, 2025 at 6:49 PM Igor Korot wrote: > >> Hi, ALL, >> On the >> https://www.postgresql.org/docs/17/sql-createindex.html#SQL-CREATEINDEX-STORAGE-PARAMETERS >> its said: >> >> [quote] >

Re: Clarification on the docs

2025-04-11 Thread David G. Johnston
On Fri, Apr 11, 2025 at 6:49 PM Igor Korot wrote: > Hi, ALL, > On the > https://www.postgresql.org/docs/17/sql-createindex.html#SQL-CREATEINDEX-STORAGE-PARAMETERS > its said: > > [quote] > The optional WITH clause specifies storage parameters for the index. > Each index method has its own set of

Clarification on the docs

2025-04-11 Thread Igor Korot
Hi, ALL, On the https://www.postgresql.org/docs/17/sql-createindex.html#SQL-CREATEINDEX-STORAGE-PARAMETERS its said: [quote] The optional WITH clause specifies storage parameters for the index. Each index method has its own set of allowed storage parameters. The B-tree, hash, GiST and SP-GiST ind

Re: Interesting case of IMMUTABLE significantly hurting performance

2025-04-11 Thread Merlin Moncure
On Thu, Apr 10, 2025 at 10:51 PM Tom Lane wrote: > Merlin Moncure writes: > > I guess the real problems here are lack of feedback on a number of > fronts: > > *) the server knows the function is not immutable but lets you create it > > anyway, even though it can have negative downstream conseque

Re: To take backup of Postgresql Database without large objects

2025-04-11 Thread Ron Johnson
On Fri, Apr 11, 2025 at 8:56 AM sivapostg...@yahoo.com < sivapostg...@yahoo.com> wrote: > Hello, > > Using PostgreSQL 15.1, compiled by Visual C++ build 1914, 64-bit in > Windows 10. > That's 11 patch releases behind current. > Trying to take backup of a database, using pg_dump, where one table

Re: To take backup of Postgresql Database without large objects

2025-04-11 Thread Adrian Klaver
On 4/11/25 05:55, sivapostg...@yahoo.com wrote: Hello, Using PostgreSQL 15.1, compiled by Visual C++ build 1914, 64-bit in Windows 10. Trying to take backup of a database, using pg_dump, where one table contains bytea datatype, which I don't want to include in the backup. My command was: "

Re: To take backup of Postgresql Database without large objects

2025-04-11 Thread sivapostg...@yahoo.com
Hello, Using PostgreSQL 15.1, compiled by Visual C++ build 1914, 64-bit in Windows 10. Trying to take backup of a database, using pg_dump, where one table contains bytea datatype, which I don't want to include in the backup. My command was:"E:\DBBackup\bin\pg_dump.exe"  -h 192.168.1.1 -p 5432 -U

Re: pg_restore causing ENOSPACE on the WAL partition

2025-04-11 Thread Dimitrios Apostolou
Happened again even with max_wal_size=32GB on the 128GB WAL partition. At this point I'm quite sure what happens: + a checkpoint is going on for several minutes (because of I/O contention on the archival drive) + meanwhile data keeps coming in through several processes of pg_restore + data is

Re: Interesting case of IMMUTABLE significantly hurting performance

2025-04-11 Thread Dominique Devienne
On Fri, Apr 11, 2025 at 5:52 AM Tom Lane wrote: > Merlin Moncure writes: > > I guess the real problems here are lack of feedback on a number of fronts: > > *) the server knows the function is not immutable but lets you create it > > anyway, even though it can have negative downstream consequences