Hi Thomas,
On 4/11/18 3:14 AM, Thomas Poty wrote:
Sorry for answering only now but I just saw you answer only now.
> To be clear, I'm the original author and primary maintainer of
pgBackRest.
I am very happy to see guys like you to take time to answer me. Thank you
You are welcome. Users
On 04/12/2018 05:59 PM, hmidi slim wrote:
Hi,
I have these tables:
price_per_occupation: id (integer), product_price_period_id(integer),
occupation_type(integer), price (numeric)
product_price_period; id(integer), product_id(integer),
is_monday(boolean), is_tuesday(boolean), is_wednesday(bool
On 13 April 2018 at 18:48, Jonathan Morgan
wrote:
> For a system with information stored in a PostgreSQL 9.5 database, in which
> data stored in a table that is deleted must be securely deleted (like shred
> does to files), and where the system is persistent even though any
> particular table like
After you drop a table, aren't the associated files dropped?
On 04/13/2018 02:29 PM, Ozz Nixon wrote:
There are free utilities that do government leave wipes. The process would be,
drop the table, shrink the old table space then (if linux based), dd fill the
drive, and use wipe, 5x or 8x delet
There are free utilities that do government leave wipes. The process would be,
drop the table, shrink the old table space then (if linux based), dd fill the
drive, and use wipe, 5x or 8x deletion to make sure the drive does not have
readable imprints on the platers.
Now what Jonathan mentions -
> On Apr 13, 2018, at 10:48 AM, Jonathan Morgan
> wrote:
>
> For a system with information stored in a PostgreSQL 9.5 database, in which
> data stored in a table that is deleted must be securely deleted (like shred
> does to files), and where the system is persistent even though any particula
On 04/13/2018 12:48 PM, Jonathan Morgan wrote:
For a system with information stored in a PostgreSQL 9.5 database, in
which data stored in a table that is deleted must be securely deleted
(like shred does to files), and where the system is persistent even though
any particular table likely won
PGPASSWORD env var works fine.
Thanks !
On Fri, Apr 13, 2018 at 2:46 PM, James Keener wrote:
> Is setting it as an environment variable an option?
> https://www.postgresql.org/docs/9.1/static/libpq-envars.html
>
> Alternatively, a service file? https://www.postgresql.org/
> docs/9.0/static/libp
On 04/13/2018 12:46 PM, James Keener wrote:
Is setting it as an environment variable an option?
https://www.postgresql.org/docs/9.1/static/libpq-envars.html
Alternatively, a service file?
https://www.postgresql.org/docs/9.0/static/libpq-pgservice.html
Jim
On April 13, 2018 2:43:01 PM EDT, D
Is setting it as an environment variable an option?
https://www.postgresql.org/docs/9.1/static/libpq-envars.html
Alternatively, a service file?
https://www.postgresql.org/docs/9.0/static/libpq-pgservice.html
Jim
On April 13, 2018 2:43:01 PM EDT, David Gauthier
wrote:
>Hi:
>
>PG v9.5.2 on RHE
Hi:
PG v9.5.2 on RHEL
I like to use an alias to connect to my favorite DBs but don't like to
enter passwords. I used to just disable passwords (working behind a
firewall), but this one is different. I see nothing in the interactive
connect string where I can enter the password...
psql -h theho
On Fri, Apr 13, 2018 at 2:32 PM, Jerry Sievers
wrote:
> So I'm (was) puzzled here when a big warehouse system just upgraded to
> 9.6 which I knew does only a few 100k *real* transactions/day was
> wrapping txid_current() so fast, in turn causing some big, nasty tablesl
> to age and then require p
So I'm (was) puzzled here when a big warehouse system just upgraded to
9.6 which I knew does only a few 100k *real* transactions/day was
wrapping txid_current() so fast, in turn causing some big, nasty tablesl
to age and then require painful long-running vacuums...
Got the brilliant idea to full s
On 13 April 2018 at 16:04, Paul Jungwirth wrote:
> On 04/13/2018 02:09 AM, Bob Jones wrote:
>>
>> The adaptions I am trying to make are as follows:
>> - Higher priority moves the item higher up the menu (i.e. adapting
>> from the original "votes" concept).
>> - Default alphabetical ordering of tit
For a system with information stored in a PostgreSQL 9.5 database, in which
data stored in a table that is deleted must be securely deleted (like shred
does to files), and where the system is persistent even though any
particular table likely won't be (so can't just shred the disks at
"completion")
On 04/13/2018 02:09 AM, Bob Jones wrote:
The adaptions I am trying to make are as follows:
- Higher priority moves the item higher up the menu (i.e. adapting
from the original "votes" concept).
- Default alphabetical ordering of titles
- Use of alphanumeric IDs instead of numeric
Hi, I wrote th
Thank you!
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-general-f1843780.html
Hello,
Whilst researching current thinking on hierarchical queries in
Postgres, I stumbled accross this excellent blog post:
https://illuminatedcomputing.com/posts/2014/09/postgres-cte-for-threaded-comments/
But try as I might, my SQL-foo is not up to scratch to adapt it to my
needs, I keep on l
18 matches
Mail list logo
