Re: Clarification on the docs

[David G. Johnston]

On Sat, Apr 19, 2025 at 4:17 PM Igor Korot  wrote:

>
> Could you indicate the default value for every option here?
>
>>
>>
The descriptions clearly indicate the defaults for nearly all of them, and
the one exception is a single click away (gin_pending_list_limit).

I don't find that the information is hard to understand so no, I'm not
going to spend my time summarizing it in an email.

David J.

Re: Clarification on the docs

[Igor Korot]

Hi, Dvid,

On Fri, Apr 11, 2025, 9:04 PM David G. Johnston 
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]
>> 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 index methods all accept this
>> parameter:
>> [/quote]
>>
>>
> These are the index methods and the valid lists for each.  The docs are
> correct in how they remove duplication.  I'm undecided on whether that is
> the best presentation choice.  I would at minimum place a new paragraph
> after "own set of allowed storage parameters." so that "The B-tree,
> hash..." begins its own line.
>
> B-tree:
> fillfactor
> deduplicate_items
>
> Hash:
> fillfactor
>
> Gist:
> fillfactor
> buffering
>
> SP-Gist:
> fillfactor
>
> GIN:
> fastupdate
> gin_pending_list_limit
>
> BRIN:
> pages_per_range
> autosummarize
>

Could you indicate the default value for every option here?

Thank you.


> David J.
>
>

Re: Clarification on the docs

[Igor Korot]

David,



On Sat, Apr 19, 2025, 7:21 PM David G. Johnston 
wrote:

> On Sat, Apr 19, 2025 at 4:17 PM Igor Korot  wrote:
>
>>
>> Could you indicate the default value for every option here?
>>
>>>
>>>
> The descriptions clearly indicate the defaults for nearly all of them, and
> the one exception is a single click away (gin_pending_list_limit).
>
> I don't find that the information is hard to understand so no, I'm not
> going to spend my time summarizing it in an email.
>

I just wanted to make it clear that if someone will put it like this in the
docs - there should be a 3 column for the default value.

Sorry for the confusion..

Thank you.


> David J.
>
>

Re: verify checksums online

[Vijaykumar Jain]

iirc there used to be a Google snippet that did online checksum
verification. it worked pretty well , but I did not let it run the tests of
the extension, so it may not be 100% , I just used it for a quick check if
there were other problems visible.

if it's archived now well :)

https://github.com/google/pg_page_verification


Thanks,
Vijay

Open to work
Resume - Vijaykumar Jain 

On Sat, Apr 19, 2025, 9:00 PM Greg Sabino Mullane 
wrote:

> On Fri, Apr 18, 2025 at 5:18 PM Jeremy Schneider 
> wrote:
>
>> but i wanted to confirm with someone - my easiest options for online
>> verifying checksums would be to trigger pg_basebackup then check
>> pg_stat_database, or to install michael's utility?
>>
>
> Your easiest option is to just use pgbackrest, which verifies checksums as
> part of its process. So you are guaranteed to have every page verified at
> least as often as every full backup.
>
> Cheers,
> Greg
>
> --
> Crunchy Data - https://www.crunchydata.com
> Enterprise Postgres Software Products & Tech Support
>
>

Re: Error while updating a table

[sivapostg...@yahoo.com]

 So far, I couldn't find the query that caused the error.   Is there any way to 
unlock it?  
Re-start, Format and fresh install of windows, etc. ?
Happiness Always
BKR Sivaprakash
On Friday 18 April, 2025 at 04:50:52 pm IST, sivapostg...@yahoo.com 
 wrote:  
 
  If the query caused an error 
Does it mean that other reasons might also be there?
Nevertheless, I'll check the log file to find the query...
Happiness Always
BKR Sivaprakash
On Friday 18 April, 2025 at 03:53:06 pm IST, Laurenz Albe 
 wrote:  
 
 On Fri, 2025-04-18 at 07:31 +, sivapostg...@yahoo.com wrote:
> For the second part, how to identify that culprit query?

If the query caused an error, and you left "log_min_messages" at the
default setting, the error and the statement that caused it should
be in the PostgreSQL log.

Yours,
Laurenz Albe

Re: Error while updating a table

[Laurenz Albe]

On Sat, 2025-04-19 at 12:38 +, sivapostg...@yahoo.com wrote:
> So far, I couldn't find the query that caused the error.   Is there any way 
> to unlock it?  
> 
> Re-start, Format and fresh install of windows, etc. ?

On Windows you have to reboot, bow three times toward sunset,
say a prayer to Bill Gates, then reboot again.

No, seriously: randomly messing around with your machine rarely ever
gets you closer to a solution.

If you get the error

  current transaction is aborted, commands ignored until end of transaction 
block

it is 100% clear that an earlier statement in the same transaction must
have got an error.  Write your application so that it logs *every* error
that comes from the database, then you are sure to catch that error.

Also, if "log_min_messages" is "warning" (the default) or "error", you
will find the error in the PostgreSQL log.  That's all I can say to you.

Yours,
Laurenz Albe

Re: verify checksums online

[Greg Sabino Mullane]

On Fri, Apr 18, 2025 at 5:18 PM Jeremy Schneider 
wrote:

> but i wanted to confirm with someone - my easiest options for online
> verifying checksums would be to trigger pg_basebackup then check
> pg_stat_database, or to install michael's utility?
>

Your easiest option is to just use pgbackrest, which verifies checksums as
part of its process. So you are guaranteed to have every page verified at
least as often as every full backup.

Cheers,
Greg

--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support

Re: Error while updating a table

[sivapostg...@yahoo.com]

 Thanks Laurenz,
> it is 100% clear that an earlier statement in the same transaction musthave 
>got an error.  Write your application so that it logs *every* error
that comes from the database, then you are sure to catch that error.

There is an option to log every sql statement that's executed from the 
application.  Unfortunately, that option was not set at that time.   Even I 
enable it now, I can't figure out that error.   By any chance, if I get that 
statement, what should I do?  What are the Steps (or documentation) to correct 
this issue?
Happiness Always
BKR Sivaprakash
On Saturday 19 April, 2025 at 06:25:37 pm IST, Laurenz Albe 
 wrote:  
 
 On Sat, 2025-04-19 at 12:38 +, sivapostg...@yahoo.com wrote:
> So far, I couldn't find the query that caused the error.   Is there any way 
> to unlock it?  
> 
> Re-start, Format and fresh install of windows, etc. ?

On Windows you have to reboot, bow three times toward sunset,
say a prayer to Bill Gates, then reboot again.

No, seriously: randomly messing around with your machine rarely ever
gets you closer to a solution.

If you get the error

  current transaction is aborted, commands ignored until end of transaction 
block

it is 100% clear that an earlier statement in the same transaction must
have got an error.  Write your application so that it logs *every* error
that comes from the database, then you are sure to catch that error.

Also, if "log_min_messages" is "warning" (the default) or "error", you
will find the error in the PostgreSQL log.  That's all I can say to you.

Yours,
Laurenz Albe


  

Re: Error while updating a table

[David G. Johnston]

On Sat, Apr 19, 2025 at 6:06 AM sivapostg...@yahoo.com <
sivapostg...@yahoo.com> wrote:

> By any chance, if I get that statement, what should I do?
>

Read it.

What are the Steps (or documentation) to correct this issue?
>
>
Impossible to say until the statement is read.

David J.

Re: Error while updating a table

[Peter J. Holzer]

On 2025-04-19 13:06:27 +, sivapostg...@yahoo.com wrote:
> Thanks Laurenz,
> > it is 100% clear that an earlier statement in the same transaction must
> > have got an error.  Write your application so that it logs *every* error
> > that comes from the database, then you are sure to catch that error.
> 
> There is an option to log every sql statement that's executed from the
> application.  Unfortunately, that option was not set at that time.

You don't have to log every sql statement. Just the ones which cause
errors. As Laurenz mentioned, that happens automatically with the
default settings.

> Even I enable it now, I can't figure out that error.   

Just search the logs for the string "ERROR".

> By any chance, if I get that statement, what should I do?

1) Read the error message.
2) Figure out what caused the error
3) Fix the problem

hjp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature