On Thu, Oct 13, 2022 at 12:13 AM gzh wrote:
>
> My PostgreSQL is deployed on Amazon RDS, so the password of PostgreSQL is
> random and has various reserved characters.
>
> I don't know if the reserved characters below are complete, and there are
> some characters (e.g. * , $) I tried without
Dear Jeff
I appreciate your reply.
My PostgreSQL is deployed on Amazon RDS, so the password of PostgreSQL is
random and has various reserved characters.
I don't know if the reserved characters below are complete, and there are some
characters (e.g. * , $) I tried without problems.
Could
From: gzh Sent: Wednesday, 12 October 2022 9:30 PM
> Who can tell me which solution is better below：
> Solution 1: Change the configuration parameters
>set enable_seqscan = off
> Solution 2: Add DISTINCT clause to SQL
>explain analyze select DISTINCT 2 from analyze_word_reports where
On Wed, Oct 12, 2022 at 6:47 AM Tom Lane wrote:
> However, that doesn't explain the downthread report that a
> VACUUM on the primary fixed it. What I suspect is that that
> caused some in-fact-dead index entries to get cleaned out.
Seems likely.
> But ... if the primary is allowed to vacuum
On Wed, Oct 12, 2022 at 7:16 AM gzh wrote:
>
> I found that the password can't contain the % character, and the other
> special characters (* , $) are no problem.
You need to percent-encode the password if you wish to use the %
symbol in the password. There are other reserved characters that
Peter Geoghegan writes:
> That's true, but it doesn't matter whether or not there are LP_DEAD
> bits set on the standby, since in any case they cannot be trusted when
> in Hot Standby mode. IndexScanDescData.ignore_killed_tuples will be
> set to false on the standby.
Hmm. I think that might
On Wed, 2022-10-12 at 10:51 +0200, Guillaume Lelarge wrote:
> Just finished my phone call. So, they definitely have their performance back.
> All they did was a VACUUM on two tables.
>
> If I understand correctly, during "normal" operations, some information is
> stored on the primary
> and
I found that the password can't contain the % character, and the other special
characters (* , $) are no problem.
At 2022-10-12 16:28:51, "gzh" wrote:
PostgreSQL version: 13.5
Operating system: windows 10
Description:
I wrote a VBA application to connect to
Hi everyone,
Who can tell me which solution is better below：
Solution 1: Change the configuration parameters
set enable_seqscan = off
Solution 2: Add DISTINCT clause to SQL
explain analyze select DISTINCT 2 from analyze_word_reports where (cseid =
94) limit 1;
If I
Le mer. 12 oct. 2022 à 08:56, Guillaume Lelarge a
écrit :
> Le mar. 11 oct. 2022 à 19:42, Guillaume Lelarge
> a écrit :
>
>> Le mar. 11 oct. 2022 à 18:27, Alvaro Herrera a
>> écrit :
>>
>>> On 2022-Oct-11, Tom Lane wrote:
>>>
>>> > Are there any tables in this query where extremal values of
PostgreSQL version: 13.5
Operating system: windows 10
Description:
I wrote a VBA application to connect to PostgreSQL database by psqlodbc.
The application works fine when there are no special characters in the password.
When the password contains special characters (e.g. * ,
Le mar. 11 oct. 2022 à 19:42, Guillaume Lelarge a
écrit :
> Le mar. 11 oct. 2022 à 18:27, Alvaro Herrera a
> écrit :
>
>> On 2022-Oct-11, Tom Lane wrote:
>>
>> > Are there any tables in this query where extremal values of the join
>> > key are likely to be in recently-added or recently-dead
Le mer. 12 oct. 2022 à 06:08, Ron a écrit :
> On 10/11/22 22:35, Julien Rouhaud wrote:
> > On Tue, Oct 11, 2022 at 07:42:55PM +0200, Guillaume Lelarge wrote:
> >> Le mar. 11 oct. 2022 à 18:27, Alvaro Herrera
> a
> >> écrit :
> >>
> >>> On 2022-Oct-11, Tom Lane wrote:
> >>>
> Are there any
On Tue, Oct 11, 2022 at 10:04 PM Tom Lane wrote:
> Do we propagate visibility-map bits to standbys?
Yes.
--
Peter Geoghegan
On Tue, Oct 11, 2022 at 9:27 AM Alvaro Herrera wrote:
> I remember having an hypothesis, upon getting a report of this exact
> problem on a customer system once, that it could be due to killtuple not
> propagating to standbys except by FPIs. I do not remember if we proved
> that true or not. I
15 matches
Mail list logo
