The PGReplicationStream.setAppliedLSN is only applicable for physical
replication, right? So this may not actually make a difference for my logical
replication program.
Periodically running the utility for setting the flush LSN using
PGReplicationStream.setFlushedLSN should still work for the fe
I may have misunderstood the documentation or your question, but I had
the understanding that xmin is not updated, but is only set on insert
(but yes, also for update, but updates are also inserts for Postgres as
updates are executed as delete/insert)
from https://www.postgresql.org/docs/10/ddl
Hi,
> Well, did you consume the logical data, and if so how? When you use the
> streaming interface - HIGHLY recommended - you need to send feedback
> messages as to where you've received the data.
Yes, I am consuming data using the PGReplicationStream.readPending()
method in my program.
>
On Tue, Mar 12, 2019 at 10:49 PM Nicola Contu wrote:
> Il giorno gio 7 mar 2019 alle ore 09:39 Nicola Contu
> ha scritto:
>> So the first file is on Postgres11.2 on a test server (and where I compare
>> 10 vs 11)
>> The second file, is our preprod machine running Postgres 11.2 (different
>> ha
Different code behave different, what you need to do is to study your
business model, and find a best fit.
I'm going to talk about the nontechnique thing, and hope it can help.
Mysql is spliting, when saying Mysql, we always need to think about Mysql
of Oracle or Mariadb. both database have thei
On 3/12/19 1:02 PM, Vijaykumar Jain wrote:
no i mean not we end users, postgres does it (?) via the xmin and xmax
fields from inherited tables :) if that is what you wanted in a why
or are you asking, does postgres even update those rows and i am wrong
assuming it that way?
Not sure where the
On 3/12/19 3:19 PM, Christopher Browne wrote:
On Tue, 12 Mar 2019 at 12:53, Benedict Holland
wrote:
I am not saying it is not well documented. I am saying that it isn't ACID
compliant, which it isn't, as they document.
I *love* the notion of being able to roll back DDL, but it has long
been c
On Tue, 12 Mar 2019 at 12:53, Benedict Holland
wrote:
> I am not saying it is not well documented. I am saying that it isn't ACID
> compliant, which it isn't, as they document.
I *love* the notion of being able to roll back DDL, but it has long
been common for DDL to *not* be transactional even
no i mean not we end users, postgres does it (?) via the xmin and xmax
fields from inherited tables :) if that is what you wanted in a why
or are you asking, does postgres even update those rows and i am wrong
assuming it that way?
since the values need to be atomic,
consider the below analogy
as
On 3/12/19 12:19 PM, Vijaykumar Jain wrote:
I was asked this question in one of my demos, and it was interesting one.
we update xmin for new inserts with the current txid.
Why?
now in a very high concurrent scenario where there are more than 2000
concurrent users trying to insert new data,
w
I was asked this question in one of my demos, and it was interesting one.
we update xmin for new inserts with the current txid.
now in a very high concurrent scenario where there are more than 2000
concurrent users trying to insert new data,
will updating xmin value be a bottleneck?
i know we sho
Benedict:
On Tue, Mar 12, 2019 at 5:53 PM Benedict Holland
wrote:
> I am not saying it is not well documented. I am saying that it isn't ACID
> compliant, which it isn't, as they document.
You are using the term "ACID compliant". Could you please point me to
some definition of what this is ( no
I am not saying it is not well documented. I am saying that it isn't ACID
compliant, which it isn't, as they document.
It comes up far more often than I would like, particularly with migrations
and schema changes. It is one of the huge reasons I actively refuse to work
with MySQL. I have never upg
The MySQL manual says that INNODB 'adheres closely' to the ACID model,
though there are settings where you can trade some ACID compliance for
performance.
See https://dev.mysql.com/doc/refman/5.6/en/mysql-acid.html
I've been running PostgreSQL for a client since 2005, we're on our 5th
hardware pl
Benedict:
On Tue, Mar 12, 2019 at 4:56 PM Benedict Holland
wrote:
> When you create a table in a transaction, it will commit the transaction and
> prevent a rollback. MySQL is not ACID.
And when you call COMMIT in postgres it will commit and prevent a rollback.
This does not mean MySQL is not
When you create a table in a transaction, it will commit the transaction
and prevent a rollback. MySQL is not ACID.
Thanks,
~Ben
On Tue, Mar 12, 2019 at 11:44 AM Ron wrote:
> The Percona fork of MySQL makes active-active clustering very simple to
> set up.
>
> On 3/12/19 9:10 AM, Benedict Holla
The Percona fork of MySQL makes active-active clustering very simple to set up.
On 3/12/19 9:10 AM, Benedict Holland wrote:
MySQL isn't ACID. Postgresql is a full-featured database that doesn't
allow injection. It is very safe and secure. Also, the way that PostgreSQL
has a much better user man
Hi,
(please don't send HTML only emails to this list)
On 2019-03-12 11:08:56 +, Rashmi V Bharadwaj wrote:
> We have an application that uses the PostgreSQL logical replication API to
> read
> the changes made to the PostgreSQL database and applies it to a different
> database (like Db2 etc).
Benedict:
On Tue, Mar 12, 2019 at 3:11 PM Benedict Holland
wrote:
> MySQL isn't ACID.
Are you sure of that? I mean, I stopped using it in the late nineties,
and it only had MyISAM then, certainly not ACID, but my understanding
is it's got some ACID storage backends and options ( I seem to recall
MySQL isn't ACID. Postgresql is a full-featured database that doesn't allow
injection. It is very safe and secure. Also, the way that PostgreSQL has a
much better user management system and database/table level access ACLs.
Basically, you just asked a bunch of people who have used PostgreSQL over
Hi,We have an application that uses the PostgreSQL logical replication API to read the changes made to the PostgreSQL database and applies it to a different database (like Db2 etc). We are using logical replication slots for this. Currently I am facing an issue where the replication slot is pointin
Hello,
do you have any advice on this?
Thanks a lot in advance
Il giorno gio 7 mar 2019 alle ore 09:39 Nicola Contu
ha scritto:
> So the first file is on Postgres11.2 on a test server (and where I compare
> 10 vs 11)
> The second file, is our preprod machine running Postgres 11.2 (different
> h
Laurenz Albe schrieb am 12.03.2019 um 10:05:
>> Also MySQL has a query cache that allows the results of very common queries
>> to be much faster.
>
> I have used that feature, and it has bitten me:
> https://stackoverflow.com/q/44244482/6464308
Note that the query cache was removed in MySQL 8.0
Chris Travers wrote:
> Also MySQL has a query cache that allows the results of very common queries
> to be much faster.
I have used that feature, and it has bitten me:
https://stackoverflow.com/q/44244482/6464308
I guess only some rather pathological workloads really benefit from that.
> For up
On Mon, Mar 11, 2019 at 7:32 PM Sonam Sharma wrote:
> Hi All,
>
> We are planning to migrate our database into any open source DB.
> Can someone please help me in knowing which one will be better among
> POSTGRESQL and MYSQL.
>
> In what terms postgres is better than MYSQL.
>
If course you will
25 matches
Mail list logo
