Hi Amul,
2016-11-04 7:52 GMT+01:00 amul sul :
> Hi Guillaume,
>
> I found following issues with this patch, sorry missed in previous post:
>
>
You don't have to be sorry for me doing shitty things :)
> #1 :
> 43 @@ -392,6 +393,10 @@ main(int argc, char **argv)
> 44 dopt.output
I have Postgresql 9.3 installed on AWS instance ubuntu 14.04
The load average of the instance increase every 105 minutes even without any
database. I’ve checked the scheduled jobs but couldn’t find anything
suspicious. When the load average was at peak, I couldn’t see any process
consuming reso
On 11/4/2016 1:45 AM, Nhan Nguyen wrote:
The load average of the instance increase every 105 minutes even
without any database. I’ve checked the scheduled jobs but couldn’t
find anything suspicious. When the load average was at peak, I
couldn’t see any process consuming resources. This happen
On Thu, Nov 3, 2016 at 8:17 PM, Dmitry Karasik
wrote:
> Dear all,
>
> I'd like to ask for help or advice with choosing the best replication
> setup for
> my task.
>
> I need to listen to continuous inserts/deletes/updates over a set of
> tables,
> and serve them over http, so I would like to off-
On 03/11/2016 14:20, Adrian Klaver wrote:
The above does not make sense. You are having to recover because there
was no backup and now you want to go forward without doing a backup?
Hi Adrian, no, I don't want go forward without backups ;)
Actually, the *first* thing I did after the vacuum
>> It might raise another problem, that the nulls are generated through LEFT
>> JOINS where no rows are defined. Then the 0 or -1 value need to be
>> a computed value. Won't this throw off index lookups? (I might be
>> more confused in this area).
>
>Not following this.
The nulls are generated by
On Fri, Nov 4, 2016 at 8:08 AM, Kim Rose Carlsen wrote:
>>> It might raise another problem, that the nulls are generated through LEFT
>
>>> JOINS where no rows are defined. Then the 0 or -1 value need to be
>>> a computed value. Won't this throw off index lookups? (I might be
>>> more confused in
Since it could potentially be a security loop hole. So far the action taken to
address it falls into these two categories:
drop the PUBLIC schema altogether. One of the concerns is with some of the
system objects that have been exposed through PUBLIC schema previously, now
they will need ot
On 11/04/2016 03:20 AM, Gionatan Danti wrote:
On 03/11/2016 14:20, Adrian Klaver wrote:
The above does not make sense. You are having to recover because there
was no backup and now you want to go forward without doing a backup?
Hi Adrian, no, I don't want go forward without backups ;)
Actu
On 4 November 2016 at 14:41, Merlin Moncure wrote:
> On Fri, Nov 4, 2016 at 8:08 AM, Kim Rose Carlsen wrote:
>> The nulls are generated by something like this
>> SELECT c.circuit_id,
>>cc.customer_id
>>FROM circuit AS c
>> LEFT JOIN circuit_customer AS cc
>>
On 4 November 2016 at 11:20, Gionatan Danti wrote:
> Unfortuntaly I am working with incredible constrains from customer side;
> even buying two SAS disks seems a problem. Moreover, as an external
> consultant, I have basically no decision/buying power :|
> What I can do (and I did) is to raise a v
On 11/4/16 3:58 PM, Hu, Patricia wrote:
Since it could potentially be a security loop hole. So far the action taken to
address it falls into these two categories:
drop the PUBLIC schema altogether. One of the concerns is with some of the
system objects that have been exposed through PUBLIC
> You need to look at a replication solution like Slony, which is a trigger
> based replication solution. If you are using PostgreSQL version 9.4 or
> higher, then, you can explore "pglogical" which is WAL based and uses
> logical decoding capability.
I'm using 9.4, and I'm looking at pglogical as
Hello guys,
it is the second time (in two weeks), that have a very strange Postgresql in a
8.4.22 installation (32 bit still).
Logfile grow up (in few hours) until filling the Whole disk space.
I can read infinite series of this messages:
CachedPlan: 1024 total in 1 blocks; 640 free (0 chunks)
Job writes:
> it is the second time (in two weeks), that have a very strange Postgresql in
> a 8.4.22 installation (32 bit still).
You realize, of course, that 8.4.x has been out of support for a couple of
years now.
> Logfile grow up (in few hours) until filling the Whole disk space.
> I can
- Original Message -
> From: "Patricia Hu"
> Sent: Friday, November 4, 2016 9:58:10 AM
>
> Since it could potentially be a security loop hole. So far the action taken
> to address it falls into these two categories:
>
> drop the PUBLIC schema altogether. ...
> keep the PUBLIC s
16 matches
Mail list logo
