> I truly believe that this problem – HA – is PostgreSQL's, not 3rd
> party's. And it's a shame that Postgres itself doesn't solve this. So
> we're discussing it here.
Let's see what other subscribers on this forum say.
>> > What if pg1 is currently primary, pg0 is standby, both are healthy, but
On Fri, 07 Apr 2023 13:16:59 +0900 (JST)
Tatsuo Ishii wrote:
> >> > But, I heard PgPool is still affected by Split brain syndrome.
> >>
> >> Can you elaborate more? If more than 3 pgpool watchdog nodes (the
> >> number of nodes must be odd) are configured, a split brain can be
> >> avoided.
> And I believe that's part of what Cen was complaining about:
>
> «
> It is basically a daemon glued together with scripts for which you are
> entirely responsible for. Any small mistake in failover scripts and
> cluster enters a broken state.
> »
>
> If you want to build something clea
On Fri, 07 Apr 2023 18:04:05 +0900 (JST)
Tatsuo Ishii wrote:
> > And I believe that's part of what Cen was complaining about:
> >
> > «
> > It is basically a daemon glued together with scripts for which you are
> > entirely responsible for. Any small mistake in failover scripts and
> > c
On Thu, 2023-04-06 at 16:41 +, Evgeny Morozov wrote:
> Our PostgreSQL 15.2 instance running on Ubuntu 18.04 has crashed with this
> error:
>
> 2023-04-05 09:24:03.448 UTC [15227] ERROR: index "pg_class_oid_index"
> contains unexpected zero page at block 0
> [...]
>
> We had the same thin
On 4/7/23 05:46, Jehan-Guillaume de Rorthais wrote:
On Fri, 07 Apr 2023 18:04:05 +0900 (JST)
Tatsuo Ishii wrote:
And I believe that's part of what Cen was complaining about:
«
It is basically a daemon glued together with scripts for which you are
entirely responsible for. Any small mist
On Fri, Apr 07, 2023 at 01:04:34PM +0200, Laurenz Albe wrote:
> On Thu, 2023-04-06 at 16:41 +, Evgeny Morozov wrote:
>> Could this be a PG bug?
>
> It could be, but data corruption caused by bad hardware is much more likely.
There is no way to be completely sure here, except if we would be ab
> Scenario:
> S0 - Running Postgresql as primary, and also PgPool.
> S1 - Running Postgresql as secondary, and also PgPool.
> S2 - Running only PgPool. Has the VIP.
>
> There's no /need/ for Postgresql or PgPool on server 0 to shut down if
> it loses contact with S1 and S2, since they'll also not
>> If node 1 hangs and once it is recognized as "down" by other nodes, it will
>> not be used without manual intervention. Thus the disaster described above
>> will not happen in pgpool.
>
> Ok, so I suppose **all** connections, scripts, softwares, backups,
> maintenances
> and admins must go thr
On 2023-04-07 13:04:34 +0200, Laurenz Albe wrote:
> On Thu, 2023-04-06 at 16:41 +, Evgeny Morozov wrote:
> > What can I do to figure out why this is happening and prevent it from
> > happening again?
>
> No idea about the former, but bad hardware is a good enough explanation.
>
> As to keepi
On Fri, 07 Apr 2023 21:16:04 +0900 (JST)
Tatsuo Ishii wrote:
> >> If node 1 hangs and once it is recognized as "down" by other nodes, it will
> >> not be used without manual intervention. Thus the disaster described above
> >> will not happen in pgpool.
> >
> > Ok, so I suppose **all** connect
On 4/6/23 18:27, Louis Tian wrote:
Hi Adrian,
Thank you. I think this is a better approach than trigger-based
solution, at least for my taste.
That being said, it does require some logic to push to the client side
(figuring out which required column value is missing and set it value to
the ex
On 4/6/23 18:27, Louis Tian wrote:
Hi Adrian,
Thank you. I think this is a better approach than trigger-based
solution, at least for my taste.
That being said, it does require some logic to push to the client side
(figuring out which required column value is missing and set it value to
the ex
I am string to stop my PostgreSQL (on debian 11) server using the following
command
root@d11:/# sudo -u postgres /usr/bin/pg_ctlcluster 15 main stop -- -m fast
-D /var/lib/postgresql/13/main
Notice: extra pg_ctl/postgres options given, bypassing systemctl for stop
operation
pg_ctl: PID file "
I wonder if the best way to proceed would be to go on to individual nodes
in the cluster and use OS level commands (such as ps) to track individual
processes and stop them individually.
On Fri, Apr 7, 2023 at 6:27 PM Telium Technical Support
wrote:
> I am string to stop my PostgreSQL (on debian
On 4/7/23 15:27, Telium Technical Support wrote:
I am string to stop my PostgreSQL (on debian 11) server using the
following command
root@d11:/# sudo -u postgres /usr/bin/pg_ctlcluster 15 main stop -- -m
fast -D /var/lib/postgresql/13/main
Notice: extra pg_ctl/postgres options given, bypassi
These commands are actually run from a C++ program (which does a lot of other
things)…so not easy to change. I’m assuming something is misconfigured on the
host that’s causing this unusual behavior….and that’s what I need to understand
From: Boris Epstein [mailto:borepst...@gmail.com]
Sent:
On Fri, 7 Apr 2023, Telium Technical Support wrote:
>Notice: extra pg_ctl/postgres options given, bypassing systemctl for stop
>it might be 13. Coincidentally, there is a postmaster.pid file in a
>directory OTHER than the data directory:
>
>/var/lib/postgresql/15/main/postmaster.pid
>
>(and noti
On Fri, 7 Apr 2023, Telium Technical Support wrote:
>I’m assuming something is misconfigured on the host that’s causing this
>unusual behavior….and that’s what I need to understand
The mix between 13 and 15 here is what I’d consider a misconfiguration.
Also, please don’t top-post and full-quote.
I tried the command you suggested, and it shows that data directory status as
"DOWN". Yet when I ask pg_ctlcluster for it's status it says the server is
running.
What does this mean?
root@d11:/var/tmp/myapp# pg_lsclusters
Ver Cluster Port Status OwnerData directory Log file
1
>The mix between 13 and 15 here is what I’d consider a misconfiguration.
As I inherited this (and I'm somewhat new to pgsql), I'm trying to understand
this. From the docs I read online, the postmaster.pid file is supposed to
reside in the data directory. Which it does. So that's ok.
Does the
On 4/7/23 15:51, Telium Technical Support wrote:
I tried the command you suggested, and it shows that data directory status as
"DOWN". Yet when I ask pg_ctlcluster for it's status it says the server is
running.
What does this mean?
root@d11:/var/tmp/myapp# pg_lsclusters
Ver Cluster Port Stat
Thorsten Glaser writes:
> On Fri, 7 Apr 2023, Telium Technical Support wrote:
>
>>Notice: extra pg_ctl/postgres options given, bypassing systemctl for stop
>
>>it might be 13. Coincidentally, there is a postmaster.pid file in a
>>directory OTHER than the data directory:
>>
>>/var/lib/postgresql/
23 matches
Mail list logo
