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 pro
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 yo
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 awa
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 you
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 brea
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 sent
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 Pos
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 the
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. * , $
11 matches
Mail list logo
