On 2023-10-30 14:02, yangsr3411 wrote:
Has anyone encountered similar problem or may know a solution?
Just to rule out hardware problems, does the server hardware have
some way of showing things like ECC memory errors and similar?
Most official server hardware (HPE, Dell, etc) have utilities
Forwarded Message
| From | yangsr3411 |
| Date | 10/30/2023 12:02 |
| To | pgsql-general |
| Cc | |
| Subject | Server process exited with exit code 4 |
I encountered a problem while using postgre(version 15.2) on windows 10. the
following error messages are often printed in the logs, ab
I encountered a problem while using postgre(version 15.2) on windows 10. the
following error messages are often printed in the logs, about once a day.
---
LOG: server process (PID 38540) exited with exit code 4.
DETAIL: Failed process was running: COMMIT
LOG: termin
Hi all:
Last week, I tried PITR recovery. The 'recovery_target_action' guc is
shutdown. Then I got a failure, and the utility told me to check the log.
Finally I found the result was due to guc. I think pg_ctl should print some
information which told users recovery had been done.
On Sun, Oct 29, 2023 at 11:49:11AM +0100, Peter J. Holzer wrote:
> On 2023-10-29 10:11:07 +0100, Paul Förster wrote:
>> On Oct 29, 2023, at 02:43, Peter J. Holzer wrote:
>>> I don't think so. AFAIK Replication keeps the data files in sync on a
>>> bit-for-bit level and turning on checksums changes
On Sun, Oct 29, 2023, 13:59 Ravi Malghan wrote:
> I have a master sql file used to create all the database objects for an
> application. Is there an application/script to compare what's in the actual
> database and my sql file and display the differences?
>
Not that I know of. You can find stuf
I have a master sql file used to create all the database objects for an
application. Is there an application/script to compare what's in the actual
database and my sql file and display the differences?
On 10/29/23 12:57, Paul Förster wrote:
Hi Ron,
On Oct 29, 2023, at 16:37, Ron wrote:
As for safety, what do you mean by "safe"?
Safe in the sense that, if I enable checksums on a replica, switch over and the
enable checksums on the other side, if this is ok, or whether future mutations
on
Hi Ron,
> On Oct 29, 2023, at 16:38, Peter J. Holzer wrote:
> And this is where it would break down. The modifications can't be
> applied to the replica any more because the replica now contains
> checksums and the modifications don't. In the best case the replica
> would catch the discrepancy a
Hi Ron,
> On Oct 29, 2023, at 16:37, Ron wrote:
>
> As for safety, what do you mean by "safe"?
Safe in the sense that, if I enable checksums on a replica, switch over and the
enable checksums on the other side, if this is ok, or whether future mutations
on the primary will corrupt the replica
On 10/29/23 09:45, p...@pfortin.com wrote:
On Sun, 29 Oct 2023 16:16:05 +0100 Peter J. Holzer wrote:
On 2023-10-29 09:21:46 -0400, p...@pfortin.com wrote:
These are all static tables. Does PG maintain a table row count so as to
avoid having to count each time?
No. To count the rows in a tabl
On 10/29/23 11:45, p...@pfortin.com wrote:
On Sun, 29 Oct 2023 16:16:05 +0100 Peter J. Holzer wrote:
On 2023-10-29 09:21:46 -0400, p...@pfortin.com wrote:
These are all static tables. Does PG maintain a table row count so as to
avoid having to count each time?
No. To count the rows in a table
On Sun, 29 Oct 2023 16:16:05 +0100 Peter J. Holzer wrote:
>On 2023-10-29 09:21:46 -0400, p...@pfortin.com wrote:
>> These are all static tables. Does PG maintain a table row count so as to
>> avoid having to count each time?
>
>No. To count the rows in a table, Postgres has to actually read the
On 2023-10-29 16:15:37 +0100, Paul Förster wrote:
> On Oct 29, 2023, at 11:49, Peter J. Holzer wrote:
> > It *might* work if there are zero writes on the primary during the
> > downtime of the replica (because those writes couldn't be replicated),
> > but that seems hard to ensure. Even if you cou
On 10/29/23 04:11, Paul Förster wrote:
Hi Peter
On Oct 29, 2023, at 02:43, Peter J. Holzer wrote:
I don't think so. AFAIK Replication keeps the data files in sync on a
bit-for-bit level and turning on checksums changes the data layout.
Running a cluster where one node has checksums and the oth
On Sun, 29 Oct 2023 16:00:46 +0100 Peter J. Holzer wrote:
>On 2023-10-27 19:46:09 -0400, p...@pfortin.com wrote:
>> On Fri, 27 Oct 2023 19:07:11 +0200 Peter J. Holzer wrote:
>> >Have you looked at the query plans as I recommended? (You might also
>> >want to enable track_io_timing to get extra i
On 2023-10-29 09:21:46 -0400, p...@pfortin.com wrote:
> These are all static tables. Does PG maintain a table row count so as to
> avoid having to count each time?
No. To count the rows in a table, Postgres has to actually read the
whole table (or an index, if a suitable index (e.g. a primary key)
Hi Peter,
> On Oct 29, 2023, at 11:49, Peter J. Holzer wrote:
>
> It *might* work if there are zero writes on the primary during the
> downtime of the replica (because those writes couldn't be replicated),
> but that seems hard to ensure. Even if you could get away with making
> the primary read
On 2023-10-27 19:46:09 -0400, p...@pfortin.com wrote:
> On Fri, 27 Oct 2023 19:07:11 +0200 Peter J. Holzer wrote:
> >Have you looked at the query plans as I recommended? (You might also
> >want to enable track_io_timing to get extra information, but comparing
> >just the query plans of fast and slo
On Sat, 28 Oct 2023 18:34:50 -0400 Jim Mlodgenski wrote:
Looking like a GOLD star for Jim...
>On Fri, Oct 27, 2023 at 7:46 PM wrote:
>
>> Memory: 125.5 GiB of RAM
>>
>It looks like you have a large amount of memory allocated to the server
>
>But your plans are doing reads instead of pulling th
On 2023-10-29 10:11:07 +0100, Paul Förster wrote:
> On Oct 29, 2023, at 02:43, Peter J. Holzer wrote:
> > I don't think so. AFAIK Replication keeps the data files in sync on a
> > bit-for-bit level and turning on checksums changes the data layout.
> > Running a cluster where one node has checksums
Hi Peter
> On Oct 29, 2023, at 02:43, Peter J. Holzer wrote:
> I don't think so. AFAIK Replication keeps the data files in sync on a
> bit-for-bit level and turning on checksums changes the data layout.
> Running a cluster where one node has checksums and the other doesn't
> would result in a com
22 matches
Mail list logo
