On 10/8/2024 23:39, Laurenz Albe wrote:
On Wed, 2024-10-09 at 04:22 +, senor wrote:
I was under the impression that all transactions must end with a commit or a
rollback but watching stats doesn't support this. Web searches tend to return
info on what a transaction is or the ratio of commi
Another possibility is orphaned files.
See
https://www.dbi-services.com/blog/can-there-be-orphaned-data-files-in-postgresql/
and https://github.com/bdrouvot/pg_orphaned
--
Sergey
On Wed, 9 Oct 2024 at 19:02, Greg Sabino Mullane wrote:
>
> On Wed, Oct 9, 2024 at 4:10 AM Mikael Petterson
> wrote
On Wed, Oct 9, 2024 at 4:10 AM Mikael Petterson
wrote:
> Hi,
>
> I find our disk is filling up.
>
> sudo find /var/lib -type f -size +100M -exec ls -lh {} \; | awk '{ print
> $9 ": " $5 }'
>
...
Those files only add up to about 30GB. That's pretty small these days :
time for a bigger disk? Or pe
On 10/8/24 04:06, Mikael Petterson wrote:
Hi,
I find our disk is filling up.
Query the pg_stat_activity view:
https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ACTIVITY-VIEW
and look for rows that have with state showing 'idle in transaction'.
Report back what
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, 2024-10-09 at 18:07 +0800, iseki zero wrote:
> I found it difficult to understanding some paragraph in the document
> "Concurrency control" section.
>
> > The Repeatable Read mode provides a rigorous guarantee that each
> transaction sees a completely stable view of the database. Howeve
On Wed, Oct 9, 2024 at 9:02 AM Philip Semanchuk <
phi...@americanefficient.com> wrote:
>
> > On Oct 9, 2024, at 5:52 AM, Torsten Förtsch
> wrote:
> >
> > Filenames like 16665, 16665.1, 16665.2 etc all represent the same table
> (or similar). The number 16665 is called the file node.
> >
> > To ge
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 20150623 (Red Hat
> 4.8
> On Oct 9, 2024, at 5:52 AM, Torsten Förtsch wrote:
>
> Filenames like 16665, 16665.1, 16665.2 etc all represent the same table (or
> similar). The number 16665 is called the file node.
>
> To get a list of file nodes for a specific database you can run:
>
> SELECT oid::regclass::text, rel
Hello,
I found it difficult to understanding some paragraph in the document
"Concurrency control" section.
> The Repeatable Read mode provides a rigorous guarantee that each
transaction sees a completely stable view of the database. However, this
view will not necessarily always be consisten
Filenames like 16665, 16665.1, 16665.2 etc all represent the same table (or
similar). The number 16665 is called the file node.
To get a list of file nodes for a specific database you can run:
SELECT oid::regclass::text, relfilenode FROM pg_class;
The /16384/ in the path represents the database.
Hi,
I find our disk is filling up.
sudo find /var/lib -type f -size +100M -exec ls -lh {} \; | awk '{ print $9 ":
" $5 }'
/var/lib/rpm/Packages: 278M
/var/lib/pgsql/12/data/base/16384/16583: 392M
/var/lib/pgsql/12/data/base/16384/16586: 1.0G
/var/lib/pgsql/12/data/base/16384/16588: 173M
/var/lib
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/message
13 matches
Mail list logo
