> On Mar 29, 2019, at 6:58 AM, Michael Paquier wrote:
>
>> On Thu, Mar 28, 2019 at 09:53:16AM -0600, Rob Sargent wrote:
>> This is pg10 so it's pg_wal. ls -ltr
>>
>>
>> -rw---. 1 postgres postgres 16777216 Mar 16 16:33
>> 00010CEA00B1
>> -rw---. 1 postgres postgres 16777
On 2019-03-29 17:05:41 +0100, Moreno Andreo wrote:
> Il 28/03/2019 23:50, Peter J. Holzer ha scritto:
> > On 2019-03-28 15:29:50 +0100, Moreno Andreo wrote:
> > > here I'm trying to find a way so nobody can, without the use of the
> > > application, match a patient with their clinical records (i.e.
On 3/29/19 9:01 AM, Moreno Andreo wrote:
And I tried to find a solution, and since I did not like that much what
I found (and it seems that neither you do :-) ), I came here hoping that
someone would share his experience to shed some light on the topic.
From what you have posted the biggest i
Hoi,
We're running 9.4.20 (yes it's old) and having issues with the database
getting stuck occasionally, with COMMITs in one database being blocked on
COMMITs in a completely different database. I've been able to determine
that "object 0 of class 1262 of database 0" relates to the LISTEN/NOTIFY
ma
On 2019-03-29 17:01:07 +0100, Moreno Andreo wrote:
> Il 28/03/2019 23:29, Peter J. Holzer ha scritto:
> > On 2019-03-28 18:36:40 +0100, Moreno Andreo wrote:
> > > it's just "separation" (that was OK with the last privacy act, but not
> > > with GDPR
> > I doubt that this is correct. The GDPR doesn'
Il 28/03/2019 23:50, Peter J. Holzer ha scritto:
On 2019-03-28 15:29:50 +0100, Moreno Andreo wrote:
here I'm trying to find a way so nobody can, without the use of the
application, match a patient with their clinical records (i.e. someone
breaking into the server -- data breach)
I think it is v
Il 28/03/2019 23:29, Peter J. Holzer ha scritto:
On 2019-03-28 18:36:40 +0100, Moreno Andreo wrote:
Il 26/03/2019 18:08, Adrian Klaver ha scritto:
To me it would seem something like:
Table medications
id user_id med
1 sgkighs98 Medication
2 sghighs98 Ear check
Table us
On Fri, Mar 29, 2019 at 8:58 PM Achilleas Mantzios <
ach...@matrix.gatewaynet.com> wrote:
> On 29/3/19 5:15 μ.μ., Durgamahesh Manne wrote:
>
> Hi
> Respected pgsql team
>
> please let me know the pgaudit parameter to store pgaudit log files only
>
> i don't want to store pgaudit log files at pgsql
On 29/3/19 5:15 μ.μ., Durgamahesh Manne wrote:
Hi
Respected pgsql team
please let me know the pgaudit parameter to store pgaudit log files only
i don't want to store pgaudit log files at pgsql log_directory file location
let me guess, there is none?
Regards
durgamahesh manne
--
Achille
Hi
Respected pgsql team
please let me know the pgaudit parameter to store pgaudit log files only
i don't want to store pgaudit log files at pgsql log_directory file
location
Regards
durgamahesh manne
On Fri, 29 Mar 2019, Andrew Gierth wrote:
That query seems correct assuming you want the result in descending order
of next_contact. How did the actual result differ from your expectation?
Andrew,
User error: I had a couple of date typos (2018 rather than 2019) and was
thinking of generating
Hi Christopher,Adrian,Tom
Thanks for quick response finally i did the pltcl install extension
activity done thanks for your support.
Regards,
Prakash.R
On Fri, Mar 29, 2019 at 3:08 AM Christopher Browne
wrote:
>
>
> On Thu, 28 Mar 2019 at 17:11, Prakash Ramakrishnan <
> prakash.ramakrishnan...
On Thu, 28 Mar 2019, Ken Tanzer wrote:
Really? Is your next_contact field a date field and not a text field? What
order does it come out in?
(And I assume you saw David J's correction to the misinformation I offered.)
Ken,
Mea culpa. the next_contact column is a date, I did apply David's
cor
On Thu, 28 Mar 2019, David G. Johnston wrote:
It returns something at least. If you put the output you get into a
spreadsheet are you able to manually sort it the way you desire?
David,
Probably, but that's not practical for the application.
Thanks,
Rich
> On Mar 29, 2019, at 6:58 AM, Michael Paquier wrote:
>
>> On Thu, Mar 28, 2019 at 09:53:16AM -0600, Rob Sargent wrote:
>> This is pg10 so it's pg_wal. ls -ltr
>>
>>
>> -rw---. 1 postgres postgres 16777216 Mar 16 16:33
>> 00010CEA00B1
>> -rw---. 1 postgres postgres 16777
On Thu, Mar 28, 2019 at 09:53:16AM -0600, Rob Sargent wrote:
> This is pg10 so it's pg_wal. ls -ltr
>
>
> -rw---. 1 postgres postgres 16777216 Mar 16 16:33
> 00010CEA00B1
> -rw---. 1 postgres postgres 16777216 Mar 16 16:33
> 00010CEA00B2
>
> ... 217 more on thro
Hi Mr Kellerer
Thanks a lot for your reply and suggestion.
I will check it out.
Regards
Vadi
Bengaluru
India
On Fri, 29 Mar 2019 15:34:12 +0530 Thomas Kellerer wrote
>Vadi schrieb am 29.03.2019 um 10:44:
> I would like to know if there is any equivalent in PostgreSQL for the Ora
Vadi schrieb am 29.03.2019 um 10:44:
> I would like to know if there is any equivalent in PostgreSQL for the Oracle
> "member of" syntax.
>
> The usage is as shown below:
>
> I have used the Oracle sample HR schema for the below example:
>
> CREATE OR REPLACE TYPE params as table of varchar2 (1
What Andrea Moreno's client seems to think is required by
GDPR is clearly bogus -- it would render illegal any and all
DICOM images existing today, because they contain
programmatically easily processable personally identifying
data right inside the clinical data.
Karsten Hilbert
--
GPG 40BE 5B0E
Hi all
I would like to know if there is any equivalent in PostgreSQL for the Oracle
"member of" syntax.
The usage is as shown below:
I have used the Oracle sample HR schema for the below example:
CREATE OR REPLACE TYPE params as table of varchar2 (100);
/
CREATE OR REPLACE function
Hi all,
I have a question about xid wraparound.
The document below say that warning occurs when transactionId which I can use
is reduced to less than 11,000,000.
https://www.postgresql.org/docs/11/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND
==
If for some reason
21 matches
Mail list logo
