On 29 Mar 2024, at 4:25, Thomas Munro wrote:
>
> I don't have any specific ideas and I have no idea what "ignore
> ownership" means ... what kind of filesystem is running on it? For
> the simple SSD, is it directly connected, running a normal Apple APFS
> filesystem, or something more complicated?
On 22 Mar 2024, at 17:00, Alban Hertroys wrote:
On Fri, 22 Mar 2024 at 15:01, Nick Renders
wrote:
We now have a second machine with this issue: it is an Intel Mac mini
running macOS Sonoma (14.4) and PostgreSQL 16.2.
This one only has a single Data directory, so there are no multiple
On 13 Mar 2024, at 12:35, Stephen Frost wrote:
> Greetings,
>
> * Nick Renders (postg...@arcict.com) wrote:
>>> ...run them under different users on the system.
>>
>> Are you referring to the "postgres" user / role? Does that also mean setting
>> u
On 11 Mar 2024, at 16:04, Adrian Klaver wrote:
> On 3/11/24 03:11, Nick Renders wrote:
>> Thank you for your reply Laurenz.
>> I don't think it is related to any third party security software. We have
>> several other machines with a similar setup, but this is the onl
ur restore script and the issue did
not occur.
I have just performed another restore on cluster A and now cluster B is
throwing errors in the log again.
Any idea why this is happening? It does not occur with every restore, but it
seems to be related anyway.
Thanks,
Nick Renders
On 26 Feb 202
s of those 2 files are all in order.
When this happens, the server is no longer accessible, and we need to restart
the service (pg_ctl restart).
Once restarted, Popstgres runs fine again for a couple of days.
We are running PostgreSQL 16.2 on macOS 14.3.1.
Any idea what might be causing this issue, or how to resolve it?
Best regards,
Nick Renders
ched.
Any tips?
Thanks,
Nick Renders
Thank you for all the feedback and suggestions.
It seems that the "-h localhost" parameter is triggering the issue. If I
leave it out, pg_restore works without problems with multiple jobs. I
have also tried specifying the IP number instead of "localhost", but
that results in the same error.
d familiar to anyone? Is it an issue with the new Postgres
14 release, or is there something else that might be causing this?
Best regards,
Nick Renders
set it to "trust", the command goes through just
fine.
So I have been able to do the upgrade, but I am still wondering why I
got the error in the first place. Any idea why the .pgpass file isn't
working with the pg_upgrade command?
Best regards,
Nick Renders
es 9 on macOS 10.12)
and the same issue seems to occur there.
Has anyone noticed something similar with macOS? Or is it just our
setup?
Best regards,
Nick Renders
Hi Tom,
1. we used the EDB installer.
2. turning JIT off did make the problem go away. So I guess this was
causing the Postgres process to crash all along.
Thanks for the help,
Nick
On 24 Feb 2020, at 16:24, Tom Lane wrote:
"Nick Renders" writes:
We have set up a new test e
uence FROM f_gsxws_schedule WHERE UPPER(gwsc_dossier) =
'TEST'
both kill the postgres service.
I will try to free some time next week to install the Apple developer
tools and further analyse the problem.
Best regards,
Nick
On 11 Feb 2020, at 12:32, Nick Renders wrote:
Hi Thomas
Hi Jeremy,
This happend on PostgreSQL v9.6 which crashed 2 weeks ago.
Since then we have upgraded and restored our server, but my example is
from the older, corrupt database.
Nick
On 15 Feb 2020, at 5:30, Jeremy Schneider wrote:
On Feb 14, 2020, at 04:39, Nick Renders wrote:
I get the
IF iCounter % 10 = 0 THEN
RAISE NOTICE '% % records checked', iCounter,
pTableName;
END IF;
iCounter := iCounter+1;
END LOOP;
END;
$f$;
Cheers,
Nick
On 14 Feb 2020, at 16:14, Tom Lane wrote:
&quo
ipt? Or is
there perhaps a better way to check for corrupt records in a database?
Best regards,
Nick Renders
Hi Thomas,
We are setting up a new test environment with 12.1.
Once it is running, I'll try out those commands and get back with the
results.
Thanks,
Nick Renders
On 11 Feb 2020, at 2:51, Thomas Munro wrote:
On Mon, Feb 10, 2020 at 4:35 AM Marc wrote:
We will keep the 12.1 in pla
noticed anything like this before? Any idea how to fix this?
Best regards,
Nick Renders
m here? Is tracking down these corrupt
records and deleting them the best / only solution?
Is there a way to determine of there are issues with new data (after the
crash)?
Any help and advice is very much appreciated.
Thanks,
Nick Renders
On 5 Feb 2020, at 12:51, Alvaro Herrera wrote:
On 2
might have been the reboot, but maybe the reboot was a result
of a Postgres issue.
Is there anything specific I should check in our postgres installation /
database to make sure it is running ok now? Anyway to see what the
consequences were of purging that one pg_clog file?
Best regards,
Nick Renders
20 matches
Mail list logo
