On 2021-06-16 17:36, Dean Gibson (DB Administrator) wrote:
Is this reasonable thinking?
I'd think that one would want a *wal_keep_size* to cover the pending
updates while the standby server might be unavailable, however long
one might anticipate that would be.
In my case, I get a com
On 2021-06-16 18:02, Julien Rouhaud wrote:
On Wed, Jun 16, 2021 at 05:36:24PM -0700, Dean Gibson (DB Administrator) wrote:
Is this reasonable thinking?
I'd think that one would want a *wal_keep_size* to cover the pending updates
while the standby server might be unavailable, however lon
Is this reasonable thinking?
I'd think that one would want a *wal_keep_size* to cover the pending
updates while the standby server might be unavailable, however long one
might anticipate that would be.
In my case, I get a complete replacement (in the form of "|"- delimited
ASCII files) of on
I'm no expert, but it looks like you are reading v9.6 documentation for
a v13 installation.
On 2021-06-16 09:25, Haseeb Khan wrote:
...
hot_standby = on
...
*recovery.conf file*
standby_mode = 'on'
On 2021-06-10 10:43, Dean Gibson (DB Administrator) wrote:
On 2021-06-10 09:54, Ranier Vilela wrote:
Em qui., 10 de jun. de 2021 às 13:08, Dean Gibson (DB Administrator)
mailto:postgre...@mailpen.com>> escreveu:
... Do I need quotes on the command line?
See at:
On 2021-06-10 11:23, Andrew Dunstan wrote:
On 6/10/21 2:00 PM, Tom Lane wrote:
"Dean Gibson (DB Administrator)" writes:
... Do I need quotes on the command line?
On 2021-06-10 09:54, Ranier Vilela wrote:
Your cmd lacks =
=>pg_dumpall -U Admin --exclude-database=MailPen >zzz.
On 2021-06-10 09:54, Ranier Vilela wrote:
Em qui., 10 de jun. de 2021 às 13:08, Dean Gibson (DB Administrator)
mailto:postgre...@mailpen.com>> escreveu:
I guess I don't understand what that option does:
=>pg_dumpall -U Admin --exclude-database MailPen >zzz.sql
On 2021-06-10 03:29, Andrew Dunstan wrote:
On 6/9/21 9:50 PM, Dean Gibson (DB Administrator) wrote:
First, pg_dumpall (v13.3) errors out, because on RDS, you cannot be a superuser, &
it tries to dump protected stuff. If there is a way around that, I'd like to know it,
even though it
Having now successfully migrated from PostgreSQL v9.6 to v13.2 in Amazon
RDS, I wondered, why I am paying AWS for an RDS-based version, when I
was forced by their POLICY to go through the effort I did? I'm not one
of the crowd who thinks, "It works OK, so I don't update anything". I'm
usually
On 2021-06-07 04:52, Andrew Dunstan wrote:
On 6/6/21 7:49 PM, Dean Gibson (DB Administrator) wrote:
On 2021-05-29 13:35, Andrew Dunstan wrote:
On 5/29/21 3:59 PM, Dean Gibson (DB Administrator) wrote:
... If I remove "CAST( license_status AS CHAR ) = 'A'", ...
Wh
On 2021-05-29 13:35, Andrew Dunstan wrote:
On 5/29/21 3:59 PM, Dean Gibson (DB Administrator) wrote:
Meanwhile, I've been doing some checking. If I remove "CAST(
license_status AS CHAR ) = 'A'", the problem disappears. Changing the
JOIN to a RIGHT JOIN, & replacin
On 2021-05-31 21:16, Justin Pryzby wrote:
Here's the FROM clause that bit me:
FROM lic_en
JOIN govt_region USING (territory_id, country_id)
LEFT JOIN zip_code USING (territory_id, country_id, zip5)
LEFT JOIN "County" USING (territory_id, country_id, fips_county);
I'm gue
On 2021-05-30 21:44, Tom Lane wrote:
"Dean Gibson (DB Administrator)" writes:
I thought that having a "USING" clause, was semantically equivalent to
an "ON" clause with the equalities explicitly stated. So no, I didn't
try that.
USING is not that, or
On 2021-05-30 20:41, Christophe Pettus wrote:
On May 30, 2021, at 20:07, Dean Gibson (DB Administrator)
wrote:
The first two JOINs are not the problem, & are in fact retained in my solution. The problem is the third JOIN,
where "fips_county" from "County" is a
x Only Scan using "_IsoCountry_iso_alpha2_key"
on "_IsoCountry" (cost=0.14..0.38 rows=1 width=3) (actual
time=0.004..0.004 rows=1 loops=43)
Index Cond: (iso_alpha2 = "_GovtRegion".country_id)
Heap Fetches: 43
I tried 500, to no avail. Since each change involves a delay as RDS
readjusts, I'm going down a different path at the moment.
On 2021-05-29 03:40, Lionel Bouton wrote:
Le 29/05/2021 à 02:38, Dean Gibson (DB Administrator) a écrit :
The original VACUUM FULL ANALYZE ran in 10 hours. The
On 2021-05-28 22:24, Alexey M Boltenkov wrote:
On 05/29/21 07:08, Dean Gibson (DB Administrator) wrote: [deleted]
BTW what is the planner reason to not use index in v13.2? Is index in
corrupted state? Have you try to reindex index
"FccLookup"."_LicStatus_pkey" ?
1
On 2021-05-29 09:25, Adrian Klaver wrote:
On 5/28/21 5:38 PM, Dean Gibson (DB Administrator) wrote:
Can you repeat your EXPLAIN (ANALYZE, BUFFERS) of the query from your
first post and post them here:
https://explain.depesz.com/
Other information:
1) A diff of your configuration settings
On 2021-05-28 19:43, Christophe Pettus wrote:
...
The most common reason for this kind of inexplicable stuff after an RDS upgrade
is, as others have said, parameter changes, since you get a new default
parameter group after the upgrade.
That being said, this does look like something happened t
On 2021-05-28 13:23, Jan Wieck wrote:
On 5/28/21 2:48 PM, Dean Gibson (DB Administrator) wrote:
What sticks out for me are these two scans, which balloon from 50-60
heap fetches to 1.5M each.
-> Nested Loop (cost=0.29..0.68 rows=1
width=7) (actual time=0.003..0.
On 2021-05-28 12:18, Campbell, Lance wrote:
Also, did you check your RDS setting in AWS after upgrading? I run
four databases in AWS. I found that the work_mem was set way low
after an upgrade. I had to tweak many of my settings.
Lance
I've wondered a lot about work_mem. The default
On 2021-05-28 12:08, Andrew Dunstan wrote:
On 5/28/21 2:48 PM, Dean Gibson (DB Administrator) wrote:
[Reposted to the proper list]
...
Have you tried reproducing these results outside RDS, say on an EC2 instance
running vanilla PostgreSQL?
cheers, andrew
--
Andrew Dunstan
EDB: https
22 matches
Mail list logo
