On Fri, May 10, 2024 at 11:31 AM Lok P wrote:
> For the initial installation the extensions may need superuser privileges.
>
>>
>>
Thank you. Yes, I got it. For the initial installation for the extensions
,it will need super user privilege. But once that is done for the day to
day use , does the
For the initial installation the extensions may need superuser privileges.
On Fri, May 10, 2024 at 10:04 AM yudhi s
wrote:
> Hello All,
> We want to make sure to keep minimal privileges for the users based on
> their roles and responsibility. We have one user group who will be working
> on analy
Hello All,
We want to make sure to keep minimal privileges for the users based on
their roles and responsibility. We have one user group who will be working
on analyzing/debugging into performance issues in the databases. Basically
this group will be operating on extensions like apg_plan_management
On Thu, May 9, 2024 at 06:33:39PM -0400, Greg Sabino Mullane wrote:
>
> https://wiki.postgresql.org/wiki/Multimaster
>
>
> That is a pretty old page. There are other solutions, such as pgedge, but the
> three most important questions when it comes to active-active replication are:
>
> * Do
> https://wiki.postgresql.org/wiki/Multimaster
>
That is a pretty old page. There are other solutions, such as pgedge, but
the three most important questions when it comes to active-active
replication are:
* Do you really, really need it? (hint: the answer is no)
* What problem are you trying to
On 5/9/24 00:32, Daniel McKenzie wrote:
We've had this running in live now for years without a hiccup so we are
surprised to learn that we have this massive race condition and it just
so happens that the hardware is fast enough to process the transaction
before the .NET application can react t
Sorry, to correct myself. The pg_xact bit is written with the next
checkpoint. But the COMMIT record in the WAL is there.
On Thu, May 9, 2024 at 5:14 PM Torsten Förtsch
wrote:
> I would not find this behavior surprising in particular if you have a
> synchronous replica. According to the document
I would not find this behavior surprising in particular if you have a
synchronous replica. According to the documentation of synchronous_commit:
The local behavior of all non-off modes is to wait for local flush of
WAL to disk.
This is when the logical decoder sees the item. But that does not
On 5/9/24 00:32, Daniel McKenzie wrote:
Asynchronous commit introduces the risk of data loss. There is a short
time window between the report of transaction completion to the client
and the time that the transaction is truly committed.
To get anywhere with this issue you will need
Hi
You can use BDR, you can have a look on the following link.
https://wiki.postgresql.org/wiki/Multimaster
Thanks
Kashif Zeeshan
Bitnine Global
On Thu, May 9, 2024 at 3:28 PM Vidyashree H S
wrote:
> Hi,
>
> I'm using Postgresql 15.4 version on RISCV architecture
> I'm trying to implement act
Hi,
I'm using Postgresql 15.4 version on RISCV architecture
I'm trying to implement active-active nodes in cluster, I have gone through
various websites, there they have mentioned the theory concept of it. But I
want to implement to verify how active-active nodes actually work.
Are there any re
>
> Asynchronous commit introduces the risk of data loss. There is a short
> time window between the report of transaction completion to the client
> and the time that the transaction is truly committed.
The documentation speaks about synchronous_commit changing how transactions
change behaviour
12 matches
Mail list logo
