El día domingo, abril 25, 2021 a las 11:51:45a. m. -0400, Tom Lane escribió:
> Matthias Apitz writes:
> > At the end of the day, it turned out that out client caused the problem.
> > Because we were hunting some other issue, the client was logging some
> > message with fpr
rochen (broken pipe)
>
These messages at 05:55:xx are caused by our automatic deployment of the
software every day which starts at 05:55:00 by cron and short after installing
all
software all servers (the PostgreSQL clients) get stopped (i.e. killed)
and restarted. The hung appears a fe
El día domingo, abril 25, 2021 a las 01:54:49p. m. +0200, Matthias Apitz
escribió:
...
> # select * from pg_stat_activity where client_port = 52288;
>
> datid | datname | pid | leader_pid | usesysid | usename |
> application_name | client_addr | cli
El día lunes, abril 26, 2021 a las 07:38:40a. m. +0200, Matthias Apitz escribió:
> Having solved this issue, one last question: Is there any good way for a
> C-written or ESQL/C-written client to get the local port number or even
> the PID of the PostgreSQL server process on the other e
uence for encoding "UTF8": 0xed 0xaf 0xbf
This error can't be caused by a BLOB or bytea column. Only char or vchar
columns can cause (and did cause) such errors in our Oracle/Sybase to
PostgreSQL migrations.
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, h
h chars (non ASCII) in file names, I count as a bad
idea.
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
¡Con Cuba no te metas! «» Don't mess with Cuba! «» Leg Dich nicht mit Kuba
an!
http:/
y ideas? Thx
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
¡Con Cuba no te metas! «» Don't mess with Cuba! «» Leg Dich nicht mit Kuba
an!
http://www.cubadebate.cu/noticias/2020/12/25/en-video-con-cuba-no-te-metas/
o use it as a
starting point.
Thanks in advance for any hints.
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
El día lunes, julio 26, 2021 a las 09:05:39a. m. +0200, Pavel Stehule escribió:
> po 26. 7. 2021 v 8:56 odesílatel Matthias Apitz napsal:
>
> >
> > Hello,
> >
> > Nearly 20 years ago, I ordered some 50 vi-reference coffee mugs like this
> > one here (not
El día martes, julio 27, 2021 a las 08:32:45p. m. +0200, Matthias Apitz
escribió:
> Thank you, Pavel. This is ofc to much for a coffee mug. For using it as
> a Reference Card in paper form, it's a pity that it is not written in English.
>
> I'm working on my own for the mu
ely look into using different font sizes and
> colors and make it much denser, for one thing.
I'm attaching as well the source for libreoffice calc, so you are free
to make a nicer version. Do not forget the final size in PDF as
7.5cm x 16cm.
Thanks
matthias
--
Matthias Apit
El día miércoles, julio 28, 2021 a las 06:58:08p. m. +0200, Matthias Apitz
escribió:
> > I'm *not* going to get into this, because I know I'm capable of spending
> > days on it. I would definitely look into using different font sizes and
> > colors and make i
El día miércoles, julio 28, 2021 a las 07:30:24p. m. +0200, Matthias Apitz
escribió:
> I printed the PDF on paper, cut it to the size of 7.5cm x 16cm and
> wrapped it around the mugs I have here. 16cm is not correct. My mugs have
> more or less 7-8cm as diameter which gives around:
>
7;-d' was not specified. I was expecting in this case an
error like this:
testpos@srap53dxr1:~> export PGDATABASE=testpos
testpos@srap53dxr1:~> psql -Usisis
psql: error: FATAL: database »testpos« does not exist
What do I uderstand wrong?
matthias
--
Matthias Apitz, ✉ g..
El día viernes, agosto 06, 2021 a las 09:07:56a. m. +0200, Guillaume Lelarge
escribió:
> Le ven. 6 août 2021 à 08:53, Matthias Apitz a écrit :
>
> >
> > Hello,
> >
> > testpos@srap53dxr1:~> psql --help
> > ...
> > -d, --dbname=DBNAME d
E database name to connect to (default: "testpos")
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
Tear it down! Defund the Humboldt Forum!
https://www.jungewelt.de/artikel/406715.humboldt-forum-feudaler-themenpark.html
El día sábado, agosto 07, 2021 a las 08:06:14p. m. +0200, Karsten Hilbert
escribió:
> Am Fri, Aug 06, 2021 at 08:09:03PM +0200 schrieb Matthias Apitz:
>
> > The prototype is ready.
>
> Nice. Now the elephant needs to fade into the background.
It is already in the bac
AL parsing failed for timeline 1
The base files are there:
$ find /data/postgresql13 -name 1101524
/data/postgresql13/data/base/1076178/1101524
$ find /data/postgresql13 -name pg_wal
/data/postgresql13/data/pg_wal
What we do wrong here with pg_verifybackup?
Thanks
matthias
--
Matt
#x27;ve read exactly this page, but missed the sentence about "tar" format
because I jumped to fast to the options sections. Sorry, my fault.
Thanks
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixar
54
archive_status/000100D9.done
About WAL the file backup_manifest contains only:
"WAL-Ranges": [
{ "Timeline": 1, "Start-LSN": "0/D928", "End-LSN": "0/D9000138" }
],
What is the problem here or what I've missed?
Th
El día martes, agosto 10, 2021 a las 09:23:34a. m. +0200, Matthias Apitz
escribió:
> I've studied now the fine docs again and have some additional questions. The
> backup was done fine to the directory /data/postgresql133/backup-20210810-1
> which contains now:
>
> $ ls -l
El día martes, agosto 10, 2021 a las 11:38:57a. m. +0200, Matthias Apitz
escribió:
> I think, I sorted it out by doing this:
>
> I moved away the tar-archives:
>
> $ cd /data/postgresql133/backup-20210810-1
> $ mkdir ../saved
> $ mv *.tar.gz ../saved
>
> I unpacked
_wal$ tar xzf pg_wal.tar.gz
> ...
This is exactly the point of my question (and I figured it out too):
Where is this explained that «pg_wal.tar.gz file has to uncompressed in
pg_wal dir»?
Or, wouldn't it even be better that the files in
pg_wal.tar.gz would have the dir pg_wal in front?
What does the term 'over 20Lakh rows' mean? Thanks
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
August 13, 1961: Better a wall than a war. And, while the GDR was still
existing,
e talking about https://en.wikipedia.org/wiki/Lakh
and 20 Lakh are only 2.000.000 rows, which isn't a very big number.
Can't help with your query, though.
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/ke
n the SELECT fails to show the
row.
What could be the reason for this? Thanks
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
El día martes, noviembre 23, 2021 a las 10:09:36 +0100, Thomas Kellerer
escribió:
> > Broken index could. Then this anomaly shoud have gone after reindex table.
>
> Ilya refers to the problems decribed here:
>
> https://wiki.postgresql.org/wiki/Locale_data_changes
>
>
Thanks for the pointer
install architecture-independent files in PREFIX
--exec-prefix=EPREFIX install architecture-dependent files in EPREFIX for
instance `--prefix=$HOME'.
--libdir=DIRobject code libraries [EPREFIX/lib]
Thanks
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixa
El día Mittwoch, Dezember 01, 2021 a las 08:11:34 -0500, Tom Lane escribió:
> Matthias Apitz writes:
> > Below the top level directory (--prefix) the lib directory changed with
> > version 14.x now from .../lib to .../lib64:
>
> > ls -ld /usr/local/sisis-pap/pgsql-*/l
El día Mittwoch, Dezember 01, 2021 a las 08:11:34 -0500, Tom Lane escribió:
> Matthias Apitz writes:
> > Below the top level directory (--prefix) the lib directory changed with
> > version 14.x now from .../lib to .../lib64:
>
> > ls -ld /usr/local/sisis-pap/pgsql-*/l
Hello,
We're using pg_dumpall (from 14.1) to dump older clusters and
restore them into a new 14.1 cluster. The dump contains some databases
together with roles etc.
Is there some easy way to restore only one database out of this dump
file?
Thanks in advance
matthias
--
Matthias
JDBC (postgresql-42.2.24.jar on
Linux).
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
May, 9: Спаси́бо освободители! Thank you very much, Russian liberators!
Hello,
Does the PostgreSQL (11.4 or 13.1) record somewhere in system tables
the creation of INDEXes (or other objects)?
Thanks
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
August 13, 1961
On Fri, 21 Jan 2022 23:38:44 -0700, David G. Johnston wrote:
> On Fri, Jan 21, 2022 at 5:39 AM Matthias Apitz wrote:
>
>>
>> Hello,
>>
>> Does the PostgreSQL (11.4 or 13.1) record somewhere in system tables
>> the creation of INDEXes (or other objects)?
>&g
Planning Time: 2.028 ms
Execution Time: 1349.593 ms
(10 Zeilen)
Why is this (ignoring the Index) and what could be done?
Thanks
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
El día miércoles, enero 26, 2022 a las 12:20:08 +0100, Josef Šimánek escribió:
> st 26. 1. 2022 v 11:55 odesílatel Matthias Apitz napsal:
> >
> >
> > Hello,
> >
> > We face in a PostgreSQL 11.4 installation on a potent Linux host a
> > serious performan
hints
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
El día miércoles, enero 26, 2022 a las 11:21:12p. m. +0800, Julien Rouhaud
escribió:
> Hi,
>
> On Wed, Jan 26, 2022 at 11:07 PM Matthias Apitz wrote:
> >
> > We changed two relevant Indexes to
> >
> > CREATE INDEX d01ort ON d01buch(d01ort bpchar_pattern_o
are sorted at the end after all others. Why?
Thanks
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
August 13, 1961: Better a wall than a war. And, while the GDR was still
existing,
no German tro
El día jueves, febrero 03, 2022 a las 11:14:55 +0100, Matthias Apitz escribió:
>
> Hello,
>
> With ESQL/C on a PostgreSQL 13.1 server I see the result of this query:
>
> select katkey,normform from swd_anzeige where normform >= 'A' ORDER BY ASC;
>
> coming
El día jueves, febrero 03, 2022 a las 10:00:37 -0500, Tom Lane escribió:
> Matthias Apitz writes:
> > El día jueves, febrero 03, 2022 a las 11:14:55 +0100, Matthias Apitz
> > escribió:
> >> With ESQL/C on a PostgreSQL 13.1 server I see the result of this query:
> >
El día Donnerstag, Februar 03, 2022 a las 10:00:37 -0500, Tom Lane escribió:
> Matthias Apitz writes:
> > El día jueves, febrero 03, 2022 a las 11:14:55 +0100, Matthias Apitz
> > escribió:
> >> With ESQL/C on a PostgreSQL 13.1 server I see the result of this query:
>
lKenn';
trenn
---
; :,.-!@%&/()=?'*+#<>[\]{|}&"
; :,.-!@%&/()=?'*+#<>[\]{|}&"
(2 Zeilen)
testdb=# select trenn::bytea from sik_fstab where name='EdvSelKenn';
ERROR: invalid input syntax fo
libs and just upgrade the PgSQL server to
> the highest minor version of the major version that you support.
> ...
This is exactly the plan. For all the three versions the cluster will be
migrated to 16.5 and the client side will stay for the released version
with what they currently use
16.2 --> 16.5
Especially the version V7.2 (released in 2021) can't be updated on the
client side, the cluster will be migrated to 16.5. I assume that
CVE-2024-10979 affects the server side, and not the client side.
Any further comments on this?
Thanks
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
El día lunes, marzo 24, 2025 a las 07:27:21a. m. +0100, Laurenz Albe escribió:
> On Mon, 2025-03-24 at 06:57 +0100, Matthias Apitz wrote:
> > El día lunes, febrero 24, 2025 a las 12:41:05p. m. +0100, Laurenz Albe
> > escribió:
> > > Perhaps I need not say that, but ALT
Hello,
When the Linux OS is updated, for example from SLES 15 SP5 to SP6, the
version of the glibc is sometimes updated, for example from 2.31 to 2.38.
For existing databases this gives on SQL a warning as:
user@rechner: $SC_SQL -Usisis sisis
WARNING: database "sisis" has a collation version mis
ION;
ERROR: schema "de_de" does not exist
What do I wrong?
Matthia
On Mon, Feb 24, 2025 at 11:32 AM Jeremy Schneider
wrote:
> On Mon, 24 Feb 2025 11:08:43 +0100
> Matthias Apitz wrote:
>
> >
> > What is the procedure on 13.1 to bring the external (glibc) version
be right, the correct
procedure would be:
pgsql -Usisis sisis
sisis=# REINDEX (VERBOSE) DATABASE sisis;
sisis=# ALTER COLLATION "de_DE.utf8" REFRESH VERSION;
ALTER COLLATION
Correct?
On Mon, Feb 24, 2025 at 12:35 PM Dominique Devienne
wrote:
> On Mon, Feb 24, 2025 at 12:33 PM Matth
Laurenz Albe
wrote:
> On Mon, 2025-02-24 at 12:53 +0100, Matthias Apitz wrote:
> > If I understand the other reply from Laurenz Albe right, the correct
> procedure would be:
> >
> > pgsql -Usisis sisis
> > sisis=# REINDEX (VERBOSE) DATABASE sisis;
> &g
does it
make sense to ALTER COLLATION in these databases as well?
Thanks
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
Annalena Baerbock: "We are fighting a war against Russia ..." (25.1
201 - 251 of 251 matches
Mail list logo
