El día Dienstag, Mai 12, 2020 a las 05:17:33 -0700, Adrian Klaver escribió:
> > > insert into swd_auftrag ..
> > >
> > > COMMIT?
> >
> > This question (if it was a question) I don't understand.
>
> From your original message:
>
> "The INSERT of 1 row into table swd_daten was OK and commit'ed (
El día Dienstag, Mai 12, 2020 a las 08:01:15 -0400, Tom Lane escribió:
> Matthias Apitz writes:
> > And in the log the line logged is:
> > [1471] [12.05.2020 15:48:50:476]: ecpg_process_output on line 1744: OK:
> > INSERT 0 1
> > What I wanted to have is:
> > [1471] [12.05.2020 15:48:50:476]: ec
At Tue, 12 May 2020 17:29:50 +0200, Laurenz Albe
wrote in
> On Tue, 2020-05-12 at 09:40 +, Mariya Rampurawala wrote:
> > > but if the target cluster ran for a long time after the divergence,
> > > the old WAL files might no longer be present. In that case, they can
> > > be manually copied f
On 5/12/20 4:52 PM, Matthias Apitz wrote:
El día Dienstag, Mai 12, 2020 a las 12:30:17 -0700, Adrian Klaver escribió:
On 5/12/20 12:14 PM, Matthias Apitz wrote:
To answer also the question of Adrian Klaver:
The database in question has ~400 tables and the ESQL/C application has
for each tabl
Matthias Apitz writes:
> And in the log the line logged is:
> [1471] [12.05.2020 15:48:50:476]: ecpg_process_output on line 1744: OK:
> INSERT 0 1
> What I wanted to have is:
> [1471] [12.05.2020 15:48:50:476]: ecpg_process_output on line 1744 of
> swd_daten.pgc: OK: INSERT 0 1
> i.e. have added
El día Dienstag, Mai 12, 2020 a las 12:30:17 -0700, Adrian Klaver escribió:
> On 5/12/20 12:14 PM, Matthias Apitz wrote:
> >
> > To answer also the question of Adrian Klaver:
> >
> > The database in question has ~400 tables and the ESQL/C application has
> > for each table its own ESQL/C source
On 5/12/20 2:51 PM, TalGloz wrote:
Adrian Klaver-4 wrote
On 5/11/20 2:45 PM, TalGloz wrote:
Well I tried your steps, both Postgres 10 and 12 are in perfect running
conditions and were shut down using the "systemctl" command. When I
execute:
/usr/pgsql-12/bin/pg_upgrade --old-bindir=/usr/pgsql-
On 5/12/20 1:55 PM, Peter Devoy wrote:
Is is possible to have two entries which have the same
address_identifier_general, street and postcode, but different
descriptions?
Unfortunately, yes. The data comes from gov't systems to
regulate the development/alteration of arbitrary pieces of propert
On Tue, 12 May 2020, Peter Devoy wrote:
Is is possible to have two entries which have the same
address_identifier_general, street and postcode, but different
descriptions?
Unfortunately, yes. The data comes from gov't systems to regulate the
development/alteration of arbitrary pieces of proper
Adrian Klaver-4 wrote
> On 5/11/20 2:45 PM, TalGloz wrote:
>> Well I tried your steps, both Postgres 10 and 12 are in perfect running
>> conditions and were shut down using the "systemctl" command. When I
>> execute:
>>
>> /usr/pgsql-12/bin/pg_upgrade --old-bindir=/usr/pgsql-10/bin/
>> --new-bindi
On Tue, May 12, 2020 at 09:55:56PM +0100, Peter Devoy wrote:
> >Is is possible to have two entries which have the same
> >address_identifier_general, street and postcode, but different
> >descriptions?
>
> Unfortunately, yes. The data comes from gov't systems to
> regulate the development/alterat
>Is is possible to have two entries which have the same
>address_identifier_general, street and postcode, but different
>descriptions?
Unfortunately, yes. The data comes from gov't systems to
regulate the development/alteration of arbitrary pieces of property and
those pieces do not always have a
On 5/12/20 12:14 PM, Matthias Apitz wrote:
To answer also the question of Adrian Klaver:
The database in question has ~400 tables and the ESQL/C application has
for each table its own ESQL/C source file. It would be possible but a
nightmare to share the code and it's better to discuss the probl
To answer also the question of Adrian Klaver:
The database in question has ~400 tables and the ESQL/C application has
for each table its own ESQL/C source file. It would be possible but a
nightmare to share the code and it's better to discuss the problem based
on the ESQL/c log file or I have to
Johannes.
On Tue, May 12, 2020 at 8:05 PM Johannes Linke wrote:
> since 9.4, VACUUM FREEZE just sets a flag bit instead of overwriting xmin
> with FrozenTransactionId [1]. This makes it harder to build applications with
> a focus on data reduction.
> We have an app that lets people anonymously
On Mon, May 11, 2020 at 10:55 PM Tory M Blue wrote:
>
>
> On Mon, May 11, 2020 at 9:01 PM Thomas Munro
> wrote:
>
>> On Tue, May 12, 2020 at 2:52 PM Tory M Blue wrote:
>> > It took the change but didn't help. So 10GB of shared_buffers in 12 is
>> still a no go. I'm down to 5GB and it works, but
Hi!
since 9.4, VACUUM FREEZE just sets a flag bit instead of overwriting xmin with
FrozenTransactionId [1]. This makes it harder to build applications with a
focus on data reduction.
We have an app that lets people anonymously vote on stuff exactly once. So we
save the vote in one table withou
On 2020-05-12 10:49:22 +1000, Tim Cross wrote:
> Peter Devoy writes:
> > I need to store addresses for properties (as in real estate) so in my
> > naivety I created a unique constraint like this:
> >
> > ALTER TABLE properties
> > ADD CONSTRAINT is_unique_address
> > UNIQUE (
> > d
On Mon, May 11, 2020 at 11:09 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Monday, May 11, 2020, David G. Johnston
> wrote:
>
>> Repost, edited subject by mistake...
>>
>> On Monday, May 11, 2020, Tory M Blue wrote:
>>>
>>> And just to repeat. Same exact hardware, same kernel,
Matthias Apitz writes:
> We're facing in our ESQL/C written application a situation where a
> commit'ed INSERT into a table is rolled back.
Kind of hard to believe ... is there any sign of distress in the
postmaster log?
> I have here the ESQL/C
> logging of the problem:
> ...
> [1471] [12.05.2
On Mon, May 11, 2020 at 3:13 PM Alvaro Herrera
wrote:
> On 2020-May-11, Michael Lewis wrote:
>
> > Afaik, hash partition doesn't have real world expected use cases just
> yet.
>
> I don't think I agree with this assertion.
>
I didn't mean to be critical at all, or even make a statement of fact.
Thanks for yous suggestions Michael and David.
On Fri, May 8, 2020 at 4:11 PM Michael Lewis wrote:
> autovacuum_naptime being only 5 seconds seems too frequent. A lock_timeout
> might be 1-5 seconds depending on your system. Usually, DDL can fail and
> wait a little time rather than lock the ta
On Tue, 2020-05-12 at 09:40 +, Mariya Rampurawala wrote:
> > but if the target cluster ran for a long time after the divergence,
> > the old WAL files might no longer be present. In that case, they can
> > be manually copied from the WAL archive to the pg_wal directory, or
> > fetched on startu
On 5/12/20 7:53 AM, Matthias Apitz wrote:
Hello,
We're facing in our ESQL/C written application a situation where a
commit'ed INSERT into a table is rolled back. I have here the ESQL/C
logging of the problem:
...
[1471] [12.05.2020 15:48:50:476]: ecpg_execute on line 1744: query: insert into
On 5/12/20 5:27 AM, Kouber Saparev wrote:
I am trying to upgrade PostgreSQL from 9.5 to 12 using pg_upgrade.
/usr/lib/postgresql/12/bin/pg_upgrade \
--old-datadir=/var/lib/postgresql/9.5/main \
--new-datadir=/var/lib/postgresql/12/main \
--old-bindir=/usr/lib/postgresql/9.5/bin \
--n
Hello,
We're facing in our ESQL/C written application a situation where a
commit'ed INSERT into a table is rolled back. I have here the ESQL/C
logging of the problem:
...
[1471] [12.05.2020 15:48:50:476]: ecpg_execute on line 1744: query: insert into
swd_daten ( katkey , aktion , reserv , id ,
Hi,
Thank you for the response.
> but if the target cluster ran for a long time after the divergence,
> the old WAL files might no longer be present. In that case, they can
> be manually copied from the WAL archive to the pg_wal directory, or
> fetched on startup by configuring pr
I am trying to upgrade PostgreSQL from 9.5 to 12 using pg_upgrade.
/usr/lib/postgresql/12/bin/pg_upgrade \
--old-datadir=/var/lib/postgresql/9.5/main \
--new-datadir=/var/lib/postgresql/12/main \
--old-bindir=/usr/lib/postgresql/9.5/bin \
--new-bindir=/usr/lib/postgresql/12/bin \
--old-o
Hello.
At Tue, 12 May 2020 06:32:30 +, Mariya Rampurawala
wrote in
> I am working on providing HA for replication, using automation scripts.
> My set up consists on two nodes, Master and Slave. When master fails, The
> slave is promoted to master. But when I try to re-register the old mast
Just to reply for completeness.
MWM was high enough (4GB) .
Apparently we were having max_worker_processes = 18 and 16 subscriptions
running, leaving no room for additional processes. What an oversight.
Once mwp was bumped (to 42 on 64 core machine), everything started working
as expected.
On Sat
Hello,
Can someone please help me with the below query?
Regards,
Mariya
From: Mariya Rampurawala
Date: Sunday, 10 May 2020 at 2:55 PM
To: "pgsql-general@lists.postgresql.org" ,
"pgsql-gene...@postgresql.org"
Subject: PostgreSQL-12 replication failover, pg_rewind fails
Hi,
I am working on pro
31 matches
Mail list logo
