Hi,
We're migrating from 9.6 to 14, using pglogical. We have several logical
slots on the 9.6 instance implementing a change data capture pattern. For
the migration, we plan on recreating the slots on the 14 instance, without
taking a snapshot of the data. When the migration happens, we will simpl
On Sat, Feb 22, 2020 at 9:34 AM Tom Lane wrote:
>
> Um. At that point I'd agree with your concern about developing hardware
> problems. Both of these symptoms could be easily explained by dropped
> bits in PG's shared memory area. Do you happen to know if the server
> has ECC RAM?
>
> Yes, it
On Fri, Feb 21, 2020 at 2:53 PM Tom Lane wrote:
>
> Personally, I'd restart the postmaster, but not do more than that unless
> the error recurs.
>
Thanks for the response. I did restart the postmaster yesterday. Earlier
this morning, a query that normally completes fine started to error out
with
Hi All,
Running 9.6.15, this morning we got a 'shared buffer hash table corrupted'
error on a query. I reran the query a couple hours later, and it completed
without error. This is running in production on a Linode instance which
hasn't seen any config changes in months.
I didn't find much on-lin
On Thu, May 16, 2019 at 9:41 AM Benedict Holland <
benedict.m.holl...@gmail.com> wrote:
>
> I need a tool that can track schema changes in a postgesql database, write
> scripts to alter the tables, and store those changes in git. Are there
> tools that exist that can do this?
>
> We ended up rolli
Andreas, Sameer,
Thank you for replying. I did not understand the purpose of
hot_standby_feedback, and your explanations helped. I turned it on, and the
pausing stopped.
Thanks,
Mark
Thank you for responding to my email.
On Tue, Mar 5, 2019 at 9:20 PM Andreas Kretschmer
wrote:
>
> have you set ```max_standby_streaming_delay``? The default is 30
> seconds, which means that this will be the maximum time allowed for a
> replication lag caused by a conflicting query.
>
Yes, we'
Hi All,
On a 9.6 streaming replica, we do table scans for stats and other things.
During these scans, the replication is paused (the 'recovering' postgres
process has 'waiting' appended to it). We're not using transactions with
these scans. Is there anything we can do to prevent the pausing?
Than
On Wed, Feb 27, 2019 at 1:39 AM Achilleas Mantzios <
ach...@matrix.gatewaynet.com> wrote:
>
> Hello, as promised here is my blog :
>
> https://severalnines.com/blog/current-state-open-source-backup-management-postgresql
>
>
Nice blog post. If you're aiming for a comprehensive run down of tools, I
On Wed, Jan 9, 2019 at 12:58 PM github kran wrote:
>
> Mark - just curious to know on the logical replication. Do you think I can
> use it for my use case where i need to publish data to a subscriber when
> there is a change in the data updated for a row or any new inserts
> happening on the tabl
On Wed, Jan 9, 2019 at 10:10 AM github kran wrote:
> Mark - We are currently on 9.6 version of postgres and cant use this
> feature of logical replication.Answering to your question we are looking
> for any changes in the data related to a specific table ( changes like any
> update on a timestamp
On Wed, Jan 9, 2019 at 9:02 AM github kran wrote:
>
>> Hi Postgres Team,
>>
>> I have an application using RDS Aurora Postgresql 9.6 version having 4 TB
>> of DB size. In this DB we have a table PRODUCT_INFO with around 1 million
>> rows and table size of 1 GB.
>> We are looking for a implementa
On Fri, Dec 28, 2018 at 4:49 PM Tom Lane wrote:
>
> Yeah, SELECT FOR UPDATE should overwrite the broken xmax value and thereby
> fix it, I expect. However, I don't see anything in the release notes
> suggesting that we've fixed any related bugs since 9.6.10, so if this
> just appeared then we've
Hi,
Starting yesterday morning, auto vacuuming of one of our postgresql 9.6.10
(CentOS 7) table's started failing:
ERROR: found multixact 370350365 from before relminmxid 765860874
CONTEXT: automatic vacuum of table "userdb.public.subs"
This is about as plain and simple a table as there is. No
A Twitter thread from someone who talked with the reporter (also read
Werner's statement referenced in the first tweet):
https://twitter.com/andy_pavlo/status/1055154039606910976
Mark
Hi All,
Postgres 9.6.5. We run several logical replication processes off our main
postgres server. What we've noticed is that schema changes seem to block
until we halt the logical replication processes. For example, I just did a
'DROP INDEX CONCURRENTLY' command, and it just sat there until I sto
16 matches
Mail list logo
