El día martes, mayo 07, 2024 a las 07:07:22 +0200, Matthias Apitz escribió:
> # ls -l /usr/local/sisis-pap/lib/libcurl*
> -rw-r--r-- 1 bin bin 1315526 May 6 10:29 /usr/local/sisis-pap/lib/libcurl.a
> -rwxr-xr-x 1 bin bin1004 May 6 10:29 /usr/local/sisis-pap/lib/libcurl.la
> -rwx
El día lunes, mayo 06, 2024 a las 07:45:52 -0700, Adrian Klaver escribió:
> On 5/6/24 07:42, Adrian Klaver wrote:
> > On 5/6/24 04:05, Matthias Apitz wrote:
>
> >
> > I see three different versions of OpenSSL:
> >
> > OPENSSL_1_1_1d -- From er
CTX_new_id
EVP_KDF_ctrl
EVP_KDF_CTX_free
EVP_KDF_derive
I have a complete different OpenSSL 3.0.x environment: all OpenSSL
consumers use /usr/local/sisis-pap.sp01/lib/libssl.so.3, also
PostgreSQL and pg_tde have been compiled against this; and this
runs fine with 'pg_tde'.
What the avove error means?
Thanks
ies = 'pg_tde';
ALTER SYSTEM
sisis=#
and the file gets modified :-(
Why it does not give an error because the shared lib isn't there?
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
: The extension must first be installed on the system where PostgreSQL is
running.
How was this option set into the file postgresql151/data/postgresql.auto.conf?
And I did not do this by hand, I wasn't even aware until today that this
file exists at all.
matthias
--
Matthias Apitz, ✉
El día viernes, marzo 22, 2024 a las 01:31:43p. m. -0400, Ron Johnson escribió:
> On Fri, Mar 22, 2024 at 1:27 PM Tom Lane wrote:
>
> > Matthias Apitz writes:
> > > We have a PostgreSQL 15.1 server in production at a customer for some
> > > weeks (migrated from
ould have caused the locks? Just to make sure that we hit the beast.
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 viernes, marzo 08, 2024 a las 12:56:16 -0800, Christophe Pettus escribió:
>
>
> > On Mar 8, 2024, at 00:53, Matthias Apitz wrote:
> > It does not say definitely that for all other versions a dump/restore is
> > required.
>
> You cannot just replac
from Sybase and Oracle
to PostgreSQL). But I think, producing the dump with the old version,
setup new cluster and load the dump with the 16.2 sql command will work.
Any comments?
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key
ly.
> "
>
> Is there any other alternative approach using some configuration files from
> client side?
An option could be to run the connection through an SSH tunnel and use
there the sshd(8) config parameter ClientAliveInterval.
HIH
matthias
--
Matthias Apitz, ✉
nd all attachments.
Interesting signature :-)
You have sent a confidential message to a mailing list with many
subscribers and which will be visible in the archive for the world until
the end of it (which could be soon).
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de
fine on RedHat and also on
SuSE Linux when the container gets pushed from RedHat to SuSE, i.e.
without rebuilding it.
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
I am not at war with Russia. Я не воюю с Россией.
I
age for debugging/testing;
I plan to have a similar PostgreSQL server outside the image, with
loaded database. Shut this down and create a tar archive of the full
server which then will be COPY'ed into the image at build time
and scripts in /entrypoint.d will arange everything.
matthias
--
o rm -r main_old/
> > or
> > sudo cp -r main_old
>
> Arrgh.
>
> sudo mv -r main_old
>
> Memo to self don't eat lunch and copy/paste at same time.
Hmmm
purism@pureos:~$ uname -s
Linux
purism@pureos:~$ mv -r foo bar
mv: invalid option -- 'r'
Try 'mv
r says something about "replication", we do
pg_basebackup?
Some more information:
- wal_sender_timeout has default value (60s)
- backup target is a local file, not a network storage
- the Linux SLES 15 server is good equipped
- nothing is logged in /var/log/messages
Any ideas
El día miércoles, octubre 25, 2023 a las 11:33:11 +0200, Andreas Kretschmer
escribió:
> Am 25.10.23 um 11:24 schrieb Matthias Apitz:
> > We have a client who run REINDEX in certain tables of the database of
> > our application (on Linux with PostgreSQL 13.x):
> >
> >
the issue that the number of
rows in some of the above tables has increased. Is this possible?
Thanks
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
I am not at war with Russia.
Я не воюю с Россией
s5/
An example presentation done with s5 is here: http://www.unixarea.de/LiHab2013/
To go through the slides just do a click in the browser.
HIH
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
] CONTEXT: while locking tuple (38,57) in
relation "d03geb"
2023-09-30 16:50:50.951 CEST [18117] STATEMENT: fetch hc_d03geb
The shown PIDs for sure are the ones of the Pos backend proc (on Linux).
Is there any chance to investigate it further?
Thanks
matthias
--
Matthias
llest to largest?
AFAIK, a simple SELECT in PostgreSQL without an ORDER BY will return the rows
in random order.
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 jueves, septiembre 07, 2023 a las 12:33:06 -0400, Stephen Frost escribió:
> * Matthias Apitz (g...@unixarea.de) wrote:
> > >
> > > There's ongoing work happening for TDE support and we'd love to hear
> > > from folks who would like to see it included. You can
; > will either.
> >
> > That's disappointing, since TDE makes PCI audits that much simpler.
>
>
> There's ongoing work happening for TDE support and we'd love to hear
> from folks who would like to see it included. You can expect an updated
> patch set for the September
g_hba.conf
Thanks
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
0 0.0.0.0:54320.0.0.0:* LISTEN
tcp6 0 0 :::5432 :::*LISTEN
unix 2 [ ACC ] STREAM LISTENING 22000/tmp/.s.PGSQL.5432
We normaly use the TCP/IP port 5432 to connect to the server.
matthias
--
Mat
;1 | grep 1196
Use of uninitialized value $row_ary[2] in concatenation (.) or string at
/home/sisis/sc/dbtool.pl line 1196.
Thanks again and
Kind Regards
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
-like
export
files. Ofc NULL values in the database are something else as '' char
strings.
How this must be distinguished with DBD::Pg?
Thanks
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
ovide that, so how else can i verify the download
You can't. You should ask EDB for MD5 or SHA256. Or you should reject
those binaries.
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
No euro for the wa
the Linux PID, correct?
Thanks
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
om dbo.counter;
count
---
41
i.e. I have to specify the schema 'dbo' to access the tables.
What I am missing here in this move?
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
14343 | 479 | 1 |
1663 |
(1 row)
What does this mean?
Thanks
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
that (and having expressed that I'm not a novice im matters of
PostgreSQL) I'm looking for a good DBA course, if possible face to face
and not online. Any pointer are welcome. I'm located in Germany, near
Munich.
Thanks in advance
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de
El día Montag, Januar 09, 2023 a las 08:15:33 -0500, Joe Conway escribió:
> On 1/9/23 07:41, Matthias Apitz wrote:
> > Please note: I'm talking about the user and group "postgres" in the
> > Linux OS and not in the PostgreSQL server.
> >
> > We're compiling
creating the cluster. As nowadays there are a lot of setup such
things in bigger installations, like LDAP or AD, etc. I'd like to know
how other installations for Linux deal with this?
Thanks
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Pu
the shell code in detail, this is clear evidence of an
attack. You must purge the full operating system and reinstall it from
scratch with better credentials of Linux and later PostgreSQL.
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key
gt;
> /dev/null 2>&1 &
>
> Had no idea somebody can add something like this externally...
Please post the content of this script.
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
Hello,
Is there some interpretation of the names of the WAL files available?
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 Dienstag, November 15, 2022 a las 10:28:11 -0500, Tom Lane escribió:
> Adrian Klaver writes:
> > On 11/15/22 04:28, Matthias Apitz wrote:
> >> I have below the full ESQL/C log and do not understand, why the
> >> PostgreSQL server is thinking &q
El día Dienstag, November 15, 2022 a las 10:28:11 -0500, Tom Lane escribió:
> Adrian Klaver writes:
> > On 11/15/22 04:28, Matthias Apitz wrote:
> >> I have below the full ESQL/C log and do not understand, why the
> >> PostgreSQL server is thinking &q
1:05:50:174]: ecpg_free_params on line 543: parameter 1 =
hc_z39t_report
[6978] [15.11.2022 11:05:50:174]: ecpg_process_output on line 543: correctly
got 0 tuples with 1 fields
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
El día Mittwoch, September 14, 2022 a las 10:31:26 +0200, Matthias Apitz
escribió:
>
> We have a C-written application server which uses ESQL/C on top
> of PostgreSQL 13.1 on Linux. The application in question always serves
> the same search in a librarian database, given t
El día viernes, septiembre 30, 2022 a las 09:56:07a. m. -0600, Rob Sargent
escribió:
> On 9/30/22 09:46, Matthias Apitz wrote:
> > Hello,
> >
> > Columns may contain NULL values. The ecpg for pre-compiling ESQL/C code
> > has an option to let return NULL values in CH
Hello,
Columns may contain NULL values. The ecpg for pre-compiling ESQL/C code
has an option to let return NULL values in CHAR columns as empty strings ""
and INTEGER as INT_MIN (-0x7fff - 1) values. Is there a similar
option for Java JDBC?
Thanks
matthias
--
Matthias
El día domingo, septiembre 18, 2022 a las 07:47:32a. m. -0700, Adrian Klaver
escribió:
> On 9/18/22 02:30, Matthias Apitz wrote:
> > El día jueves, septiembre 15, 2022 a las 08:40:24a. m. -0700, Adrian Klaver
> > escribió:
> >
> > > On 9/14/22 22:33, Matthi
El día jueves, septiembre 15, 2022 a las 08:40:24a. m. -0700, Adrian Klaver
escribió:
> On 9/14/22 22:33, Matthias Apitz wrote:
> > El día miércoles, septiembre 14, 2022 a las 07:19:31a. m. -0700, Adrian
> > Klaver escribió:
> >
> > > On 9/14/22 01:31, Matthi
El día miércoles, septiembre 14, 2022 a las 07:19:31a. m. -0700, Adrian Klaver
escribió:
> On 9/14/22 01:31, Matthias Apitz wrote:
> >
> > We have a C-written application server which uses ESQL/C on top
> > of PostgreSQL 13.1 on Linux. The application in question alway
Any ideas about this?
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
ORCE;
Why is this?
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, julio 06, 2022 a las 02:33:42p. m. -0500, Ron escribió:
> On 7/6/22 01:18, Matthias Apitz wrote:
> [snip]
> > Ofc, each table has its own primary key(s), used for example for the
> > SELECT ctid, * FROM d01buch WHERE ...
> >
> > As I said, we
El día miércoles, julio 06, 2022 a las 03:53:54p. m. +0200, Peter J. Holzer
escribió:
> On 2022-07-06 14:26:00 +0200, Matthias Apitz wrote:
> > DB layer must LOCK the row for update. It does so using the CTID. Of
> > course there is a key in the row (d01gsi, the signat
El día Mittwoch, Juli 06, 2022 a las 11:45:14 +0200, Karsten Hilbert escribió:
> Am Wed, Jul 06, 2022 at 08:18:42AM +0200 schrieb Matthias Apitz:
>
> > > On first glance, it appears that you are using the ctid as a primary key
> > > for a row, and that's highly no
El día martes, julio 05, 2022 a las 10:44:23p. m. -0700, Christophe Pettus
escribió:
>
>
> > On Jul 5, 2022, at 22:35, Matthias Apitz wrote:
> > Internally, in the DB layer, the read_where() builds the row list matching
> > the WHERE clause as a SCROLLED CURSOR of
current ctid based on the old one, but as we see this does not help
always.
Thanks
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
> (29036,11)
>
> Right. Heap-Only tuples can also vanish without autovacuum; that is why I
> suspected it might have been that.
Hi Laurenz, ist there any way to keep/freeze such tuples until the run
of the next autovaccum? Some kind of config value in 13.x or 14.x? Or
even a code chan
El día Dienstag, Juli 05, 2022 a las 10:40:40 +0200, Laurenz Albe escribió:
> On Tue, 2022-07-05 at 09:51 +0200, Matthias Apitz wrote:
> > We're using the SQL function currtid2() to get the new CTID of a row
> > when this was UPDATEd.
> >
> > Investigating cases of fa
El día Dienstag, Juli 05, 2022 a las 10:40:40 +0200, Laurenz Albe escribió:
> On Tue, 2022-07-05 at 09:51 +0200, Matthias Apitz wrote:
> > We're using the SQL function currtid2() to get the new CTID of a row
> > when this was UPDATEd.
> >
> > Investigating cases of fa
. and not the new CTID
anymore.
Why is this? And what triggers exactly that the old CTID can't be used
anymore?
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, junio 22, 2022 a las 08:39:31 +0200, Matthias Apitz escribió:
> > EXEC SQL SELECT currtid2(:table ::text, :oldCTID ::tid) INTO :newCTID;
> >
> > ...
>
> Hello Tom,
>
> We came accross cases where the above SELECT returns as :newCTID the
> s
rectly got 0 tuples with 78 fields
raising sqlcode 100 on line 2540: no data found on line 2540
Why is currtid2() returning the old CTID? Looking from another SQL
session the CITD of the row is indeed (671803,23), i.e. changed.
Thanks
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http:
al
sources.
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!
on.
Is this function currtid2() not meant to be used in ESQL/C? Or did we
something wrong in ESQL/C?
I read as well in some posting that the functions currtid2() and
currtid() should be removed... Is there some better way to get the new
CTID based on the known old (invalid) CTID?
Thanks
ma
again for a
SELECT for the CTID. Can this work?
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
ght. The time
window between creating the CURSOR and missing the CTID is only 42
seconds and I can not imagine that any other concurrent process is updating
such fee rows at midnight. Could exist any other reason why a row changes
its CTID? Full VACUUM is not used either.
Thanks
matthias
--
Mat
WITH HOLD and this
conflicts with FOR UPDATE. And this is not easy to change in our generic
generated DB-layer for all the ~400 tables.
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 Wednesday, May 25, 2022 a las 11:21:44AM +0200, Matthias Apitz escribió:
> El día martes, mayo 24, 2022 a las 12:11:49 -0400, Tom Lane escribió:
>
> > Laurenz Albe writes:
> > > It may well be that somebody deleted or updated a few rows between the
> &
El día Mittwoch, Mai 25, 2022 a las 12:51:02 +0200, Laurenz Albe escribió:
> On Wed, 2022-05-25 at 11:21 +0200, Matthias Apitz wrote:
> > Is it possible that the PostgreSQL 13.1 server does something by its own to
> > invalidate the rowid?
>
> No. PostgreSQL may remove a
rocess after the other). We're trying to figure out with the customer if
something
else was started/running at this time between 23:11 and 23:21, to shut this
off in the future. Is it possible that the PostgreSQL 13.1 server does
something by its own to invalidate the rowid?
ma
El día martes, mayo 24, 2022 a las 10:47:11 -0400, Tom Lane escribió:
> Matthias Apitz writes:
> > We have a C-written program, written in ESQL/C, of our LMS where the logic
> > crawls with FETCH through a hit list and does UPDATE on some rows which
> > match certain condi
ode 100 on line 2531: no
data found on line 2531
Why is this? Thanks
matthias
--
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
';
trenn
---
; :,.-!@%&/()=?'*+#<>[\]{|}&"
; :,.-!@%&/()=?'*+#<>[\]{|}&"
(2 Zeilen)
testdb=# select trenn::bytea from sik_fstab where name='EdvSelKenn';
ERROR: invalid input syntax for type bytea
Why is this?
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:
>
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 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 out in th
ted 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 troups and bombs h
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_patter
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
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
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 obje
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
DBC (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,
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 Apitz
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
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.unixarea.de/ +49-176
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
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
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/key.pub
August 13, 1961:
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,
no German
p/pg_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?
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
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
>
e_status/000100D9.done
About WAL the file backup_manifest contains only:
"WAL-Ranges": [
{ "Timeline": 1, "Start-LSN": "0/D9000028", "End-LSN": "0/D9000138" }
],
What is the problem here or what I've missed?
Thanks
m
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.unixarea.de
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
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 th
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 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
ed. 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...@unixarea.de, http://www.unix
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:
>
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 it much den
1 - 100 of 238 matches
Mail list logo
