> BUT, even if there is a solution that parses queries to make a decision it
> I would not recommend anyone to use it unless all consequences are
> understood.
> Specifically, not every read-only query could be salefy sent to a replica,
> because they could be lagging behind the primary.
> Only app
But, I heard PgPool is still affected by Split brain syndrome.
Regards,
Inzamam Shafiq
Sr. DBA
From: Tatsuo Ishii
Sent: Wednesday, April 5, 2023 12:38 PM
To: cyberd...@gmail.com
Cc: inzamam.sha...@hotmail.com ;
pgsql-general@lists.postgresql.org
Subject: Re: P
> 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.
Best reagards,
--
Tatsuo Ishii
SRA OSS LLC
English: http://www.sraoss.co.jp/index_en/
Japan
Currently in the PgOutput messages for Insert statements, there is no way
to differentiate if the column was explicitly set to null in the insert
statement, or whether that column was omitted in the insert statement and
thus set to null (or default value)
For example, consider the below table:
I was looking at perl CPAN Module (DateTime::Format::Pg) and saw that it did
something that seemed odd to me with time zones, based on the comment:
# For very early and late dates, PostgreSQL always returns times in
# UTC and does not tell us that it did so.
Early is before 1901-12-14 a
> On 05/04/2023 11:18 CEST Steve Rogerson
> wrote:
>
> I was looking at perl CPAN Module (DateTime::Format::Pg) and saw that it did
> something that seemed odd to me with time zones, based on the comment:
>
> # For very early and late dates, PostgreSQL always returns times in
> # UTC a
Erik Wienhold writes:
>> On 05/04/2023 11:18 CEST Steve Rogerson
>> wrote:
>> # For very early and late dates, PostgreSQL always returns times in
>> # UTC and does not tell us that it did so.
>> Early is before 1901-12-14 and late after 2038-01-18
>> ...
>> These seemed correct to me. I'
Pranav Hegde writes:
> Currently in the PgOutput messages for Insert statements, there is no way
> to differentiate if the column was explicitly set to null in the insert
> statement, or whether that column was omitted in the insert statement and
> thus set to null (or default value)
Nope. Repli
On 05/04/2023 11:23, Erik Wienhold wrote:
Judging by the commit message and changed test cases, probably:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=921d749bd4c34c3349f1c254d5faa2f1cec03911
That's the one. I can't see which pg version(s) this turned up in.
2023年4月6日(木) 0:02 Steve Rogerson :
>
> On 05/04/2023 11:23, Erik Wienhold wrote:
> > Judging by the commit message and changed test cases, probably:
> >
> > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=921d749bd4c34c3349f1c254d5faa2f1cec03911
> >
> That's the one. I can't see whic
Steve Rogerson writes:
> That's the one. I can't see which pg version(s) this turned up in.
The pg_time_t change was in 8.0, the later one to support 64-bit tzdata
was in 8.4.
regards, tom lane
11 matches
Mail list logo
