Postgres has spent several decades creating a data store that does its best
to make sure data is accessible and never accidentally lost. The cobc8of a
secure forensic wipe is anathama to the product goals. To have any hope of
implementing such a thing with confidence you'd need to drop most of thos
If you're talking about space on drive then you can expect the new one to
be smaller generally as it has been straight efficient writes rather than a
bunch of updates and deletes which create "holes" in the physical file
space.
It helps if you are more detailed as to what you've observed if you wa
Interesting and useful article, Fabio. I'm actually quite curious about
your evaluation of MongoDB & Postgres. I've been operating under the
opinion that MongoDB has been obsoleted in every respect by Postgres and am
curious as to whether there are any credible use cases where, given the
opportunit
On Tue, Jul 17, 2018, 3:33 AM Joshua D. Drake wrote:
> -general.
>
> Over the last year as I have visited many meetups and interacted with
> people at conferences etc... There are three prevailing issues that
> continue to come up in contributing to the community. This email is
> about one of the
Linux compatibility. :-)
Seriously. Our organization does not use Windows anywhere and we're a
serious Postgres shop.
-- Ben Scherrey
On Sun, Jul 15, 2018 at 11:59 PM, Dmitry Igrishin wrote:
> Hello all,
>
> Colleagues. There is an idea to develop a commercial IDE for PostgreSQL
> under Wind
I would also add that AWS' I/O capabilities are quite poor and expensive. I
assume that you have tried purchasing additional IOOPs on that setup to see
whether you got an expected speed up? If not you should try that as a
diagnostic tool even if you wouldn't want to pay that on an ongoing basis.
W
In my experience it refers to development directly via SQL against the
Postgres server rather than via an ORM like Django or the like. A
remarkably high percentage of applications backed by Postgres have been
written by developers that have never actually seen or written SQL code
directly. It's all
On Wed, Jun 6, 2018 at 2:12 AM, Christophe Pettus wrote:
>
> > On Jun 5, 2018, at 12:06, Benjamin Scherrey
> wrote:
> > Doesn't that 20 years of results pretty clearly demonstrate that this
> community does not gain an advantage for adopting a CoC?
>
> Not at
On Wed, Jun 6, 2018 at 12:36 AM, Joshua D. Drake
wrote:
> On 06/05/2018 10:26 AM, Chris Travers wrote:
>
> Let's role play. I'll be a homophobic person.
>>
>> You've just submitted a proposal suggesting that we change
>> master-master replication to be multi-partner replication. I've
On Wed, Jun 6, 2018 at 12:01 AM, James Keener wrote:
> I'm sorry for the double post.
>
> > If you read the reporting guidelines, it is requested that someone
> filing a
> report provides as much evidence as possible, and that is a really
> important provision, both for the person reporting and f
On Tue, Jun 5, 2018 at 11:36 PM, Joshua D. Drake
wrote:
> On 06/05/2018 09:32 AM, Tom Lane wrote:
>
>> James Keener writes:
>>
>>> I don't participate too much here, but I've never see a group implement
>>> a code of conduct go well.
>>>
>>
>> Yeah, personally I'm a bit worried about this too.
On Tue, Jun 5, 2018 at 10:48 PM, Joshua D. Drake
wrote:
> On 06/05/2018 08:41 AM, Lutz Horn wrote:
>
>> Am 05.06.2018 17:26 schrieb Joshua D. Drake:
>>
>>> As one of the people that interacts with external members of the
>>> community more than most, I can tell you that a CoC is something the
>>>
On Tue, Jun 5, 2018 at 10:37 PM, Peter Geoghegan wrote:
> It is of course possible that a member of the committee could act in
> bad faith for any number of reasons. You can say the same thing about
> any position of leadership or authority within the community, though.
> That hasn't really been
On Mon, Jun 4, 2018 at 4:47 AM, Tom Lane wrote:
> Benjamin Scherrey writes:
> > Is there some archive of the discussion that brought on this effort and
> the
> > considerations of the committee itself? I wish I had seen the earlier
> > announcements in 2016 as
Is there some archive of the discussion that brought on this effort and the
considerations of the committee itself? I wish I had seen the earlier
announcements in 2016 as I would have definitely participated.
Another more specific factual question - have there been incidents within
the active Post
You know this is something super easy to do if you do it within Docker.
Advise you to go ahead and map the data directories to the host file system
rather than use a storage container until you get a lot more experience
with Docker. Otherwise it's crazy easy and, in fact, there already exist
Docker
I've always found it most useful to consider the difference between "what
the system is" vs. "what the system does". The core data entities and their
stable relationships comprise most of what the system is. These are the
things that should be enforced at the lowest level possible (in a db
schema)
First - NEVER USE NFS TO STORE DATA YOU DON'T WANT TO LOSE. That said, what
you want to host on depends a lot on whether your system is typically CPU
bound or I/O bound. A VM for the computational side is generally quite
fine. If you're seriously CPU bound then you're likely to want to cluster
the
One option you should seriously consider is using Docker to containerize
your postgres installation. The installation thinks it has root access but
you don't need any rights beyond the standard user role that way you can
use the standard builds without changes. This assumes you're running under
Lin
19 matches
Mail list logo
