at record was on &
off - I couldn't pin-point it in DB as it seemed to be failing on
multiple places ... until using that trick from Laurenz. Felt like a
PostgreSQL memory corruption, but system remained stable without any
complaints.
Thanks & Cheers,
Jan
--
Jan Bilek - CTO at EFTlab Pty Ltd.
On 2/27/23 22:13, Laurenz Albe wrote:
On Mon, 2023-02-27 at 06:28 +, Jan Bilek wrote:
Our customer was able to sneak in an Unicode data into a column of a JSON Type
and now that record fails on select.
Would you be able to suggest any way out of this? E.g. finding infringing row,
updating
Jan
--
Jan Bilek - CTO at EFTlab Pty Ltd.
On 11/8/22 17:03, Laurenz Albe wrote:
> On Tue, 2022-11-08 at 04:14 +0000, Jan Bilek wrote:
>
>> I know it is not exactly what you suggested (and agreeing a lot with our
>> app user shouldn't be running as superuser), but as all other inputs
>> from our application co
On 11/8/22 11:50, Christophe Pettus wrote:
>
>> On Nov 7, 2022, at 17:43, Jan Bilek wrote:
>>
>> Well, superuser (our App) is already logged in and as it is designed
>> very much as an "appliance" it simply does that job - manages its
>> database.
On 11/8/22 11:29, Christophe Pettus wrote:
>
>> On Nov 7, 2022, at 17:24, Jan Bilek wrote:
>> Would there be any way to go around this?
> The typical configuration is to not permit the PostgreSQL superuser to log in
> remotely. The database can be managed by a differen
hat white-listing /
blacklisting comes with its own problems where we are DB agnostic...
I am sorry for a long email, but any ideas/pointers will be greatly appreciated.
Thank you & Kind Regards,
Jan
--
Jan Bilek - CTO at EFTlab Pty Ltd.
Thank you all - Karsten, Benjamin, Pavel, PostgreSql team,
I've discussed all your inputs with our developers and they came with a
solution for this problem, which was already agreed (on a high level) by our
auditor.
I am adding it here so it can inspire the others, when potentially getting in
Hi team,
anyone? Please let me know if this is not a correct group to ask, I'll move it
somewhere else.
Thank you in advance & Kind Regards,
Jan
On 2019-06-04 08:56:47+10:00 Jan Bilek wrote:
Hi,
We've build a Payments Authorisation system (Box solution) on Postgresql
datab
Hi,
We've build a Payments Authorisation system (Box solution) on Postgresql
database and now we are hitting following issue with our PA:DSS audit -
requirement PA-DSS 1.1.4:
<>
1.1.4 Securely delete any track data (from the magnetic stripe or equivalent
data contained on a chip), card verific
being able to link those debugging symbols to your core dump, we
should immediately see where it is and you'll do a great help to the community.
I'm sure that then Pavel will be able to issue a fix in a matter of minutes ;)
Kind Regards,
Jan
--
Jan Bilek
CTO, EFTLab
M: +61 (0) 498 103
Hi Blair, Pavel,
we are using procedure described in https://access.redhat.com/solutions/4896
to automate crash detail collection for our production systems on RHEL 7.
Perhaps something like this can help on your side.
Kind Regards,
Jan
On 2018-03-09 04:35:05+10:00 Pavel Stehule wrote:
2018
Hi all,
Our client noticed a problem which occurred so far twice, but might be having
quite significant impact on our application processing in production:
ResStatus: PGRES_FATAL_ERROR transaction. ErrorMessage: ERROR: cached plan must
not change result type.
Reading through the documentation
13 matches
Mail list logo
