Re: pgAdmin 4 (APT) installation error

[Martín Marqués]

Hi Robert,

What does `lsb_release
 -cs`
return in your system? If you are on bionic, it should return that. If it
doesn't you have a broken lsb.


El dom., 27 feb. 2022 22:41, robert  escribió:

> Hi,
>
> Great work. the page:
>
> https://www.pgadmin.org/download/pgadmin-4-apt/
>
> has a series of commands one of which is to create a repository the line
> is:
>
> sudo sh -c 'echo "deb 
> https://ftp.postgresql.org/pub/pgadmin/pgadmin4/apt/$(lsb_release -cs) 
> pgadmin4 main" > /etc/apt/sources.list.d/pgadmin4.list && apt update'
>
> I believe it should be:
>
> sudo sh -c 'echo "deb 
> https://ftp.postgresql.org/pub/pgadmin/pgadmin4/apt/bionic pgadmin4 main" > 
> /etc/apt/sources.list.d/pgadmin4.list && apt update'
>
> based on Widuranga Dilruksha 
>  reply here:
> https://stackoverflow.com/questions/68808730/the-repository-https-apt-postgresql-org-pub-repos-apt-trusty-pgdg-release-do
>
> best regards
>
> Robert
>
>

Query size limitation missing in documentation

[Martín Marqués]

Hello,

I was looking at https://www.postgresql.org/docs/current/limits.html
(was brought up by a customer) and found we are missing the limitation
of the string of the SQL to be executed (it's 1GB which is the longest
string postgres can hold)

```
/* It's possible we could use a different value for this in frontend code */
#define MaxAllocSize((Size) 0x3fff) /* 1 gigabyte - 1 */
```

Would there be any objections to adding such limitations in the list
from the link above?

Attached in a proposed patch which adds this to the documentation. I
also added a paragraph mentioning why the field and query length are
limited by 1GB.

-- 
Martín Marqués
It’s not that I have something to hide,
it’s that I have nothing I want you to see
diff --git a/doc/src/sgml/limits.sgml b/doc/src/sgml/limits.sgml
index 7713ff7177..b9c0a05b75 100644
--- a/doc/src/sgml/limits.sgml
+++ b/doc/src/sgml/limits.sgml
@@ -68,6 +68,12 @@
  
 
 
+
+ query string length
+ 1 GB
+ 
+
+
 
  identifier length
  63 bytes
@@ -111,6 +117,11 @@
   stored inside the heap tuple.
  
 
+ 
+  Both the field size and the query string length are limited to 1GB as that
+  is the maximum size of a string representation.
+ 
+ 
  
   Columns that have been dropped from the table also contribute to the maximum
   column limit.  Moreover, although the dropped column values for newly

Update maintenance_work_mem/autovacuum_work_mem to reflect the 1GB limitation with VACUUM

[Martín Marqués]

Hi,

There's a well known limitation in the amount of memory that any
VACUUM process can use, capped at 1GB now. This is not reflected in
the documentation

https://www.postgresql.org/docs/current/runtime-config-resource.html

We should add a line that indicates that there is a limitation (that
should be IMO, backported to documentation of earlier versions as it
affects all supported versions), at least until such limitation is
lifted.

Kind regards, Martín

-- 
Martín Marqués
It’s not that I have something to hide,
it’s that I have nothing I want you to see

Re: Update section on NFS

[Martín Marqués]

El 23/4/19 a las 07:10, Peter Eisentraut escribió:
> Attached is a patch that rewrites the section on NFS.  The old section
> was ancient and didn't seem very helpful.
> 
> AFAIK, the only strict requirement for using NFS with PostgreSQL is the
> hard mount.  Anything else we should mention?

Didn''t read the proposed patch, but would like to point out that I
would also add that it has to be mounted without file attribute caching.

Regards,

-- 
Martín Marquéshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Re: Incorrect description of autovacuum_vacuum_threshold and autovacuum_vacuum_scale_factor

[Martín Marqués]

El jue., 27 sept. 2018 a las 18:05, Alvaro Herrera
() escribió:
>
> I suggest adding "This number is added to the number coming from the
> autovacuum_vacuum_scale_factor parameter for each table" just before the
> "This parameter can only be set" phrase.  So we'd end up with this:
>
> autovacuum_vacuum_threshold (integer)
> Specifies the minimum number of updated or deleted tuples needed to trigger a 
> VACUUM in any one table. The default is 50 tuples. This number is added to 
> the number coming from the autovacuum_vacuum_scale_factor parameter for each 
> table.  This parameter can only be set in the postgresql.conf file or on the 
> server command line; but the setting can be overridden for individual tables 
> by changing table storage parameters.
>
> autovacuum_vacuum_scale_factor (floating point)
> Specifies a fraction of the table size to add to autovacuum_vacuum_threshold 
> when deciding whether to trigger a VACUUM. The default is 0.2 (20% of table 
> size). This number is added to the autovacuum_vacuum_threshold parameter for 
> each table.  This parameter can only be set in the postgresql.conf file or on 
> the server command line; but the setting can be overridden for individual 
> tables by changing table storage parameters.

That looks very good IMO.

--
Martín Marqués
It’s not that I have something to hide,
it’s that I have nothing I want you to see

Re: Mistakes between an example and its description

[Martín Marqués]

2018-05-10 16:04 GMT-03:00 Eugene Wang :
> Unique Constraint and Unique Index should be the same in this single-column
> case, right?

The unique index is what enforces the uniqueness of the field with a
UNIQUE constraint, but a unique index is not necessarily a constraint.

For example, you can use a unique index to create a primary key
constraint with the USING clause, but you can't use the UNIQUE index
created by a UNIQUE CONSTRAINT for this action.

> Because, according to CONSTRAINT page in Postgres Documentation, Unique
> Constraint on single column is realized as Unique B-TREE index.
>
> I have just realized that it is still a btree index, but I think this
> example is not exactly a regular btree example. At least I will put the
> example as: CREATE INDEX title_idx ON films USING BTREE(title);

Yes, I agree on dropping the UNIQUE, just like Alvaro. There's another
example which creates a UNIQUE index later in the doc, and not the
best choice for a first example.

Regards,

-- 
Martín Marquéshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Re: Mistakes between an example and its description

[Martín Marqués]

El 09/05/18 a las 18:52, PG Doc comments form escribió:
> The following documentation comment has been logged on the website:
> 
> Page: https://www.postgresql.org/docs/9.6/static/sql-createindex.html
> Description:
> 
> In Postgres Doc: Index
> page(https://www.postgresql.org/docs/9.6/static/sql-createindex.html), there
> is an mismatch between an example description and an example SQL statement.
> 
> 
> The description is below :
> To create a B-tree index on the column title in the table films:
> 
> Meanwhile, the example provided is an UNIQUE constrain.
> CREATE UNIQUE INDEX title_idx ON films (title);

It's not exactly a unique constraint, but it is a unique index, and it
should be mentioned in the title of the documentation.

-- 
Martín Marquéshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services