ir/%f.gz && gzip -c %p /mnt/server/archivedir/%f.gz'
> Are you setting standby.signal or recovery.signal or both
Sorry, I keep confusing them. I checked my deployment code, it's
recovery.signal and only that.
Regards,
Koen De Groote
On Fri, Jan 31, 2025 at 10:26 PM Adrian
as I stated: WAL files get archived and these archived files are
then uploaded to the cloud.
See documentation:
https://www.postgresql.org/docs/16/runtime-config-wal.html#GUC-ARCHIVE-COMMAND
Regards,
Koen De Groote
On Fri, Jan 31, 2025 at 5:50 PM Adrian Klaver
wrote:
> On 1/31/25 01:47, Ko
Any advice on a different mailing list that something like this would be
more suited to?
Regards,
Koen De Groote
On Fri, Jan 31, 2025 at 8:38 PM Koen De Groote wrote:
> No, it's meant to be an off-site restore, as to do a daily check if the
> restore actually works.
>
> R
No, it's meant to be an off-site restore, as to do a daily check if the
restore actually works.
Regards,
Koen De Groote
On Fri, Jan 31, 2025 at 2:30 PM Laurenz Albe
wrote:
> On Fri, 2025-01-31 at 10:47 +0100, Koen De Groote wrote:
> > I'm running postgres 16.6
> >
hese WAL
recoveries, switches the timeline, and becomes available.
What could be going wrong? My main issue is that I don't know where to
start looking, since nothing in the logs seems abnormal.
Regards,
Koen De Groote
gt; The effective _cache_size doesn't cause any memory to.be allocated. It's
> just a hint to optomizer ....
>
> On Wed, 20 Nov 2024, 11:16 Koen De Groote, wrote:
>
>> Assuming a machine with:
>>
>> * 16 CPU cores
>> * 64GB RAM
>>
>> Set
bring the container process itself into danger.
Is it as straightforward as putting my limit on, say 20GB, and then giving
more /dev/shm to the container? Or is there more to consider?
Regards,
Koen De Groote
tting max_parallel_maintenance_workers to 0 is the fix here, is
there perhaps something else I should know about, if I want to have control
over this?
Regards,
Koen De Groote
On Wed, Nov 20, 2024 at 12:38 AM Thomas Munro
wrote:
> On Wed, Nov 20, 2024 at 11:22 AM Koen De Groote wrote:
> > Why would that be? It&#x
GB in
size. Is there something wrong with postgres 16, or did some settings
significantly change, that I need to know about? I went over all the
changelogs, nothing stood out as relevant to this, but that might be a lack
of experience on my end.
Regards,
Koen De Groote
some ways to verify things, I suggest checking them out.
And of course, if your DBA is back, have them look at it too.
Regards,
Koen De Groote
On Fri, Nov 1, 2024 at 2:10 PM Greg Sabino Mullane
wrote:
> On Fri, Nov 1, 2024 at 2:40 AM Muhammad Usman Khan
> wrote:
>
>> For immediate
I perform doesn't use the pg_wal.tar.gz file. It gets the archived
WAL At least I think it doesn't need it, hence the need for testing.
Regards,
Koen De Groote
On Tue, Oct 22, 2024 at 12:34 AM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Sunday, October 20
ning about their concepts separately.
It's just too much information to read and then "just know" in your head
that these must be the relations. Especially if you have dozens of other
things to do.
That's my 2 cents.
Regards,
Koen De Groote
On Sun, Oct 20, 2024 at 11:12 PM Adrian
WAL files works, that being: that it is only considered "done" when
the archive_command is done, that would be great.
Regards,
Koen De Groote
On Sun, Sep 29, 2024 at 6:08 PM Adrian Klaver
wrote:
> On 9/29/24 08:57, Koen De Groote wrote:
> > > What is the complete command y
patch, refresh
subscription, do the patch, recreate the tables on the subscriber and do
the sync for only those tables.
I will look in to your suggestion.
Regards,
Koen De Groote
On Thu, Oct 17, 2024 at 11:17 AM Michał Kłeczek wrote:
>
>
> > On 17 Oct 2024, at 11:07, Koen
SUBSCRIPTION your_subscription_name DISABLE;
>
> Manually apply the same schema modifications to the subscriber database to
> ensure alignment.
>
> Once the schema changes are applied to both databases, re-enable the
> subscription:
> ALTER SUBSCRIPTION your_subscription_name ENAB
ublic.dummy_table" is missing
replicated columns: "contact_email", "status", "phone_number", "username""
The only solution I've found is to drop the table from the publication, and
then drop the entire subscription and set it back up again, with the
correct schema.
Am I making a mistake? Or does putting all these commands in a single
transaction ruin my chances?
Clarification much appreciated.
Regards,
Koen De Groote
g14 connecting to pg17?
Are the considerations in that case simply with new data types not being
recognized? Or are there cases where the setup can be done, but queries
won't behave as expected?
Regards,
Koen De Groote
Ah, thanks for that
On Fri, Oct 11, 2024 at 5:59 PM Adrian Klaver
wrote:
> On 10/11/24 04:08, Koen De Groote wrote:
> > In the release notes for postgres 17 I'm reading:
> >
> > > The PostgreSQL foreign data wrapper (postgres_fdw), used to execute
> > que
doesn't seem to be any indication
of particular queries not being pushed to the foreign server, so this
wording that "can now push EXISTS and IN subqueries to the remote server"
is confusing.
What am I missing?
Regards,
Koen De Groote
ed?
This is straight from the logs, it's the only output besides the % progress
counter.
Will have a look at --verbose.
Regards,
Koen De Groote
On Sun, Sep 29, 2024 at 5:01 PM Adrian Klaver
wrote:
> On 9/29/24 07:48, Koen De Groote wrote:
> > Having run a basebackup, I'm get
into fixing this or doing whatever is required so that it
doesn't happen again, but this just isn't enough info. Where do I start
looking?
Regards,
Koen De Groote
I've considered it, but it sounds like a lot of work and failure prone.
Even projects like Debezium seem like it's a ton to set up.
Thanks for the suggestions.
Regards,
Koen
On Wed, Sep 11, 2024 at 3:20 PM Greg Sabino Mullane
wrote:
> Dumping changes periodically, sending them directly or uplo
I want to have a PG instance receive logical replication from a publisher.
However, the subscriber should not have network access to the publisher, in
any way. This is for security reasons. No VPN or any setup that allows the
subscriber to send traffic to the publisher host.
The publisher, howeve
ased on the lifespan of ephemeral workers
that each time they get created start at 0 and so now the table claims
"last_send_msg" is NULL because of it.
Am I getting that wrong? Is my understanding mistaken?
Regards,
Koen De Groote
On Fri, Aug 23, 2024 at 5:02 PM Adrian Klaver
wr
time of last message
received from origin WAL sender; NULL for parallel apply workers"
But I have no context for what parallel apply workers are or why they are
NULL sometimes and other times not.
Can anyone explain?
Regards,
Koen De Groote
there
being a subscriber, which feels counter-intuitive to me.
Thanks for stepping me through it.
On Tue, Jul 30, 2024 at 4:34 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Tue, Jul 30, 2024 at 7:16 AM Koen De Groote wrote:
>
>> And if my understanding is
table,
will be refused.
Is that correct?
Regards,
Koen
On Tue, Jul 30, 2024 at 4:04 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Tuesday, July 30, 2024, Koen De Groote wrote:
>>
>> If the subscriber gets a bit of logic to say "Something went wrong, s
Just to add a thought:
If the subscriber gets a bit of logic to say "Something went wrong, so I'm
automatically stopping what I'm doing", it sounds logical to give the
publisher the same ability.
On Tue, Jul 30, 2024 at 3:47 PM Koen De Groote wrote:
> Reading
Reading this document:
https://www.postgresql.org/docs/16/logical-replication-conflicts.html
There is talk of the "disable_on_error" option when creating a subscription.
The conflicts this applies to, I am assuming are only conflicts caused on
the side of the subscription?
As an attempt to apply
for good reason, maybe they are fully
functionality immediately after replication?
So the main question: Once a table is fully replicated, do I need to
vacuum(analyze) that table, or are the indexes on that table already
functional?
Regards,
Koen De Groote
did a logical replication upgrade,
explaining why they did it this way:
https://knock.app/blog/zero-downtime-postgres-upgrades
On Wed, Jun 12, 2024 at 7:01 PM Justin wrote:
>
>
> On Tue, Jun 11, 2024 at 5:43 PM Koen De Groote wrote:
>
>> > If there are any errors during the replay of
refreshing the subscriber each time.
I'm not planning on using "REPLICA IDENTITY FULL" anywhere.
On Sat, Jun 8, 2024 at 10:33 PM Justin wrote:
>
> On Sat, Jun 8, 2024 at 1:41 PM Koen De Groote wrote:
>
>> What I'm trying to do is upgrade a PG11 database to PG16, us
there.
On Sat, Jun 8, 2024 at 7:46 PM Adrian Klaver
wrote:
> On 6/8/24 10:40, Koen De Groote wrote:
> > What I'm trying to do is upgrade a PG11 database to PG16, using logical
> > replication.
>
> Have you looked at pg_upgrade?:
>
> https://www.postgresql.org/docs/cur
AL buildup, are my main concern.
Accidentally sent a mail to only your email, sorry for that.
Regards,
Koen De Groote
On Fri, Jun 7, 2024 at 5:15 PM Adrian Klaver
wrote:
> On 6/6/24 15:19, Koen De Groote wrote:
> > I'll give them a read, though it might take a few weekends
> >
ication
already, and I feel like I didn't get my answer there.
Thanks for the help
Regards,
Koen De Groote
On Thu, Jun 6, 2024 at 12:19 AM Adrian Klaver
wrote:
> On 6/5/24 14:54, Koen De Groote wrote:
> > https://www.postgresql.org/docs/current/wal-configuration.h
etrieves them.
>
And if it cannot sync them, due to connectivity loss for instance, the WAL
records will not be removed, then?
Regards,
Koen De Groote
On Wed, Jun 5, 2024 at 1:05 AM Adrian Klaver
wrote:
> On 6/4/24 15:55, Koen De Groote wrote:
> > I recently read the entire docum
which could cause a recovery
conflict
<https://www.postgresql.org/docs/current/hot-standby.html#HOT-STANDBY-CONFLICT>
even when the standby is disconnected. "
Am I to understand that a subscription is considered that same as a
standby, in this context?
On Wed, Jun 5, 2024 at 12:55 A
n if the WAL isn't written to disk by an
"archive_command"?
Regards,
Koen De Groote
ry or restoring a new
basebackup.
Taking a new basebackup, with the new primary, and restoring that, works.
Standby gets in sync and everything is as expected.
Kind regards,
Koen De Groote
On Wed, Aug 24, 2022 at 1:09 AM Koen De Groote wrote:
> Hello all,
>
> I have a system that was origin
it pick up the necessary
wal_archives with the restore_command?
Or is it more complicated than that? Something like a timeline jump or
something else that makes it impossible to simply set the old primary to
standby and start it again?
Kind regards,
Koen De Groote
Thank you for your thorough explanation.
On Thu, May 19, 2022 at 5:47 PM Laurenz Albe
wrote:
> On Thu, 2022-05-19 at 15:43 +0200, Koen De Groote wrote:
> > On Thu, May 19, 2022 at 9:10 AM Laurenz Albe
> wrote:
> > > On Wed, 2022-05-18 at 22:51 +0200, Koen De Groot
switches the timeline with for instance a basebackup)?
Apologies, I already sent this message once, but only to Laurenz. Sending
again to have it in the archives.
Regards,
Koen
On Thu, May 19, 2022 at 9:10 AM Laurenz Albe
wrote:
> On Wed, 2022-05-18 at 22:51 +0200, Koen De Groote wrote:
> >
The documentation here:
https://www.postgresql.org/docs/11/continuous-archiving.html
States:
> It is advisable to test your proposed archive command to ensure that it
indeed does not overwrite an existing file, *and that it returns nonzero
status in this case*.
Why exactly is this?
Assuming a s
I've got a setup where archive_command will gzip the wal archive to a
directory that is itself an NFS mount.
When connection is gone or blocked, archive_command fails after the timeout
specified by the NFS mount, as expected. (for a soft mount. hard mount
hangs, as expected)
However, on restoring
Thanks for the replies, everyone.
Gavin - I can't upgrade to a more recent version, at least not for the
foreseeable future. From what I'm reading, it's the best path forward, but
there's considerations to be made that I can't overrule.
Ninad - As I suspected about VACUUM and VACUUM FULL. Thanks
by vacuum?
Or only in case of conditional indexes?
So I'm wondering if the behavior is as I described.
Regards,
Koen De Groote
And initial setup is wrong. There should be no 'and a002=false' in the
indexes.
On Wed, Sep 8, 2021 at 11:15 PM Koen De Groote wrote:
> Forgot to mention, this is on Postgres 11.2
>
> On Wed, Sep 8, 2021 at 11:04 PM Koen De Groote wrote:
>
>> Greetings all.
>&
Forgot to mention, this is on Postgres 11.2
On Wed, Sep 8, 2021 at 11:04 PM Koen De Groote wrote:
> Greetings all.
>
> Example table:
>
> CREATE TABLE my_table (
> id serial PRIMARY KEY,
> a001 BOOLEAN default 't',
> a002 BOOLEAN default
picking an index to consider.
And if it will consider others if the analysis of the first says a seqscan
would be better than the index it first considered?
Regards,
Koen De Groote
If an upgrade process has a part where old functionality doesn't work
anymore, or anything at all breaks, then it's not "you can just upgrade no
problems".
On Sat, Apr 3, 2021 at 8:50 PM Adrian Klaver
wrote:
> On 4/3/21 10:37 AM, Koen De Groote wrote:
> > Yes tha
Yes that's it. Probably something to alert people to. If they have this set
up, they can't "just to straight to 13".
On Fri, Apr 2, 2021 at 1:32 AM Alvaro Herrera
wrote:
> On 2021-Apr-02, Koen De Groote wrote:
>
> > I seem to recall that going from 11 to 12, a
I seem to recall that going from 11 to 12, a certain configuration file was
removed and the keys are now expected to be set in the regular
configuration file? The logic being there should only ever be 1
configuration file.
I can't find it, but at the same time I don't recall what it's called. I
be
y gets updated more than
2000 times, and the majority of this is right after creation?
Is this a concern?
Regards,
Koen De Groote
table;
And the index is as suggested.
It seems the amount of rows we end up with has improved.
Thank you for your help. I wasn't aware functions could interact with
indexes in such a manner.
Regards,
Koen De Groote
On Mon, Jun 15, 2020 at 8:27 PM Michael Lewis wrote:
> On Tue, Jun 9, 20
he suggestion properly? Either
way, I still have questions about the earlier function I created, namely
how reliable that performance is. If not the same thing will happen as with
the re-created index.
Regards,
Koen
On Mon, Jun 8, 2020 at 11:15 PM Michael Lewis wrote:
> On Mon, Jun 8, 2020
, also the suggestion that this is not possible.
So, at this point, what should I still look at, I wonder? EXPLAIN says it
did a function call, but what happened under the hood there?
And before I forget: thank you most kindly for the advice so far, to all
involved.
Regards,
Koen
On Sun, Jun 7,
I'll attempt this next week.
On Fri, Jun 5, 2020, 21:11 Michael Lewis wrote:
> Those row estimates are pretty far off.
>
> Standard indexes and partial indexes don't get custom statistics created
> on them, but functional indexes do. I wonder if a small function
> needs_backup( shouldbebackedup,
--
s1 | 29 35 |
On Fri, Jun 5, 2020 at 4:15 PM Adrian Klaver
wrote:
> On 6/5/20 7:05 AM, Koen De Groote wrote:
> > I've collected all relevant info(I think so at least) and put it here:
> >
> > The table in question is used to keep filepath data, of files on a
> &
I've collected all relevant info(I think so at least) and put it here:
The table in question is used to keep filepath data, of files on a
harddrive.
The query in question is used to retrieve items which should be backed up,
but have not yet been.
The relevant columns of the table:
tes. Do I perhaps need
to do something additional in terms of cleanup/maintenance?
I've tried altering statistics, to very large values even, but no changes
there either.
Any help or suggestion would be appreciated.
Kind regards,
Koen De Groote
60 matches
Mail list logo
