Hi Craig,
I remove all the bdr packages and reinstall it and setup again the BDR
cluster, still facing the same issue on 3rd node.
On Tue, Dec 22, 2015 at 10:58 AM, Amit Bondwal
wrote:
>
> On Tue, Dec 22, 2015 at 10:05 AM, Craig Ringer
> wrote:
>
>> select * from bdr.bdr_connections;
>>
>
>
>
On Tue, Dec 22, 2015 at 1:42 AM, Stephen Frost wrote:
> Oleg,
>
> * oleg yusim (olegyu...@gmail.com) wrote:
>> tcp_keepalives_idle = 900
>> tcp_keepalives_interval=0
>> tcp_keepalives_count=0
>>
>> Doesn't terminate connection to database in 15 minutes of inactivity of
>> psql prompt. So, it looks
Hi,
a table in our database with about 3 million rows ended up in a state
where its seems to have duplicated entries (duplicated primary key values):
# \d some_table;
Table "public.some_table"
Column |Type |Modifi
=?UTF-8?Q?Aleksander_=C5=81ukasz?= writes:
> a table in our database with about 3 million rows ended up in a state
> where its seems to have duplicated entries (duplicated primary key values):
> ...
> Do you have any idea what could be happening and what measures should be
> undertaken to fix this
Please. Always, ALWAYS, give the PostgreSQL version and O/S when reporting
a problem.
First, WHAT IS THE POSTGRESQL VERSION?
WHAT IS THE O/S?
Then try this:
select a.ctid, a.id, a.field1,
b.ctid, b.id, b.field1
from some_table a,
some_table b
WHERE a.ct
(previously posted to the pgsql-performance list)
Hello,
We're in the process of designing the database for a new service, and
some of our tables are going to be using UUID primary key columns.
We're trying to decide between:
* UUIDv1 (timestamp/MAC uuid) and
* UUIDv4 (random uuid)
And the
On Tue, 22 Dec 2015 11:07:30 -0600
Brendan McCollam wrote:
> (previously posted to the pgsql-performance list)
>
> Hello,
>
> We're in the process of designing the database for a new service, and
> some of our tables are going to be using UUID primary key columns.
>
> We're trying to decide b
Hi, thanks for your reply.
2015-12-22 16:34 GMT+01:00 Melvin Davidson :
> Please. Always, ALWAYS, give the PostgreSQL version and O/S when reporting
> a problem.
>
> First, WHAT IS THE POSTGRESQL VERSION?
>WHAT IS THE O/S?
>
# select version();
Thanks Michael, you are right, that is a very good alternative solution.
Oleg
On Tue, Dec 22, 2015 at 6:27 AM, Michael Paquier
wrote:
> On Tue, Dec 22, 2015 at 1:42 AM, Stephen Frost wrote:
> > Oleg,
> >
> > * oleg yusim (olegyu...@gmail.com) wrote:
> >> tcp_keepalives_idle = 900
> >> tcp_keep
The fact that you have rows with an identical id of 2141750 verifies a
corrupted primary index.
To correct it, you need to decide which row to keep.
So review the results of
SELECT * FROM some_table WHERE ctid = (79664,59) OR ctid = (79772,23)
DELETE FROM some_table
WHERE id = 2147150
AND fi
Greetings,
I'm looking at the following security control right now:
*The DBMS must prevent unauthorized and unintended information transfer via
shared system resources.*
The purpose of this control is to prevent information, including encrypted
representations of information, produced by the act
On Tue, Dec 22, 2015 at 04:52:23PM -0600, oleg yusim wrote:
> Greetings,
>
> I'm looking at the following security control right now:
>
> The DBMS must prevent unauthorized and unintended information transfer via
> shared system resources.
>
> The purpose of this control is to prevent informatio
On 12/22/2015 2:52 PM, oleg yusim wrote:
/The DBMS must prevent unauthorized and unintended information
transfer via shared system resources./
you realize the database *itself* is a shared system resource and of
and by itself has no idea about unauthorized/unintended information
transf
John,
Absolutely. But we are not talking about that type of data leakage here. We
are talking about potential situation when user, who doesn't have access to
database, but has (or gained) access to the Linux box DB is installed one
and gets his hands on data, database processes stored in memory (m
On 12/21/15 8:22 AM, Bill Moran wrote:
Why? Just because a disk isn't enterprise-grade doesn't mean it has to lie
> >about fsync, which is the only thing diskchecker.pl tests for.
> >
>
>I was thinking that since the disk have a 32M write-cache (with not
>battery) it would lie to the OS (and pos
On 12/22/15 1:31 PM, Melvin Davidson wrote:
The fact that you have rows with an identical id of 2141750 verifies a
corrupted primary index.
To correct it, you need to decide which row to keep.
So review the results of
SELECT * FROM some_table WHERE ctid = (79664,59) OR ctid = (79772,23)
DELETE
On 12/22/15 6:03 PM, oleg yusim wrote:
Absolutely. But we are not talking about that type of data leakage here.
We are talking about potential situation when user, who doesn't have
access to database, but has (or gained) access to the Linux box DB is
installed one and gets his hands on data, data
BTW, Jim is referring to the O/S logs for hardware errors, not the
PostgreSQL logs.
Also, another way of deleting the bad row would be
DELETE FROM some_table where ctid = '(79664,59)';
or
DELETE FROM some_table where ctid = '(79772,23)';
On Tue, Dec 22, 2015 at 9:44 PM, Jim Nasby wrote:
> On
Jim,
Yes, you are right. Generally the security control here is encryption of
data at rest (TDE), but PostgreSQL doesn't support it, to my knowledge. I
know about that vulnerability, but here I posed the question on different
one. I agree it is smaller one, compare to the absence of TDE, but I wou
I have a company with four employees who participate in a Secret Santa
program, where each buys a gift for an employee chosen at random. (For
now, I do not mind if an employee ends up buying a gift for himself.)
How can I make this work with an SQL statement?
Here is my Secret Santa table:
On 23 December 2015 at 16:49, Lou Duchez wrote:
> I have a company with four employees who participate in a Secret Santa
> program, where each buys a gift for an employee chosen at random. (For
> now, I do not mind if an employee ends up buying a gift for himself.) How
> can I make this work wi
21 matches
Mail list logo
