Hi Laurenz,
Thanks for answering!
I find it very strange, because the publication is needed to make a
subscription, which makes the slot.
Thanks for looking into it and helping me understand.
Cheers!
Willy-Bas Loos
On Mon, Apr 7, 2025 at 3:31 PM Laurenz Albe
wrote:
> On Mon, 2025-04-07 at
heers,
Willy-Bas
On Sun, Apr 6, 2025 at 3:36 PM Justin wrote:
> On Fri, Apr 4, 2025 at 4:58 AM Willy-Bas Loos wrote:
>
>> Hi!
>>
>> I'm looking for a way to find out if there are still replication slots
>> active for a publication before dropping the publicatio
postgres 13 BTW
On Fri, Apr 4, 2025 at 10:58 AM Willy-Bas Loos wrote:
> Hi!
>
> I'm looking for a way to find out if there are still replication slots
> active for a publication before dropping the publication in an automated
> way. The idea is that the publication is thou
way to compose this query.
Can anyone tell me a way to find replication slots that belong to a
publication?
--
Willy-Bas Loos
Yes exactly, Geoff Winkless pointed that out too.
I thought I'd found a cause for the breaking connections, but I hadn't.
Thanks a lot for your help!
On Thu, Dec 15, 2022 at 3:48 PM Tom Lane wrote:
> Willy-Bas Loos writes:
> > It gives me a confirmation, but then when I
ndicated that they can work around the issue by creating a
table as a result, instead of simply selecting the data to be displayed in
the client.
So we decided to cease our efforts to fix the issue.
Thanks a lot for your help!
--
Willy-Bas Loos
Nice query, i keep learning new stuff here.
Anyway, that shows the correct line (80) in the config file, but the wrong
value.
Namely 0, where the config file has 120
On Thu, Dec 15, 2022 at 12:37 PM Laurenz Albe
wrote:
> On Thu, 2022-12-15 at 08:31 +0100, Willy-Bas Loos wrote:
> > On
The version is PostgreSQL 13.8 (Debian 13.8-0+deb11u1) on
x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110,
64-bit
es_idle=120;
doesn't work.
It gives me a confirmation, but then when I SHOW the value, it gives me 0.
wbloos=# set tcp_keepalives_idle=120;
SET
wbloos=# show tcp_keepalives_idle;
tcp_keepalives_idle
-----
0
(1 row)
--
Willy-Bas Loos
Thanks for your answer. I was afraid someone would say that...
I was hoping that the keepalives would be more of a matter of cooperation
between postgres and the OS.
On Wed, Dec 14, 2022 at 10:52 AM Laurenz Albe
wrote:
> On Wed, 2022-12-14 at 08:55 +0100, Willy-Bas Loos wrote:
> > S
only sent when the session is idle?
Thanks
--
Willy-Bas Loos
OK thanks for the help, have a nice weekend!
On Fri, Apr 22, 2022 at 3:39 PM Laurenz Albe
wrote:
> On Fri, 2022-04-22 at 15:26 +0200, Willy-Bas Loos wrote:
> > On Fri, Apr 22, 2022 at 3:20 PM Laurenz Albe
> wrote:
> > >
> > > The trigger function is bad and dange
problems.
>
Thanks a lot!
Do you mean that all trigger functions are bad and dangerous, or just mine?
Do you have any suggestions for an alternative?
Cheers,
--
Willy-Bas Loos
gnment
2022-04-22 13:14:11.285 CEST [1562110] LOG: background worker "logical
replication worker" (PID 1932237) exited with exit code 1
The trigger works well when I fire it in a normal update query.
How can this happen and how can I resolve this?
--
Willy-Bas Loos
for the snapshot.
I had to prevent long transactions for long enough so that the initial
snapshot could get a lock on the subscriber. However, I don't know the
length of the timeout that defines how long a transaction can be without
disturbing the snapshot.
Please correct me where I'm wrong.
Hi, I was going to follow up on this one, sorry for the long silence.
The replication is working fine now, and I have no idea what the problem
was. Not cool.
If I find out, I will let you know.
On Mon, May 31, 2021 at 6:06 PM Tomas Pospisek wrote:
> Hi Willy-Bas Loos,
>
> On 31.05
On Mon, May 31, 2021 at 4:24 PM Vijaykumar Jain <
vijaykumarjain.git...@gmail.com> wrote:
> So I got it all wrong it seems :)
>
Thank you for taking the time to help me!
You upgraded to pg13 fine? , but while on pg13 you have issues with logical
> replication ?
>
Yes, the upgrade went fine. So he
ySlot during multi insert by bdrouvotAWS · Pull
> Request #295 · 2ndQuadrant/pglogical (github.com)
> <https://github.com/2ndQuadrant/pglogical/pull/295>
> there are many issues posted here that may be relevant to your setup.
>
>
>
>
>
> On Sat, 29 May 2021 at 19:22
; index on the destination concurrently.
> it completed in 4-5 hours without stopping the source.
> migration completed in a few mins :)
>
> not sure if this would help, but just FYI.
>
>
> On Sat, 29 May 2021 at 01:36, Willy-Bas Loos wrote:
>
>> Hi , I'm upgrading
that receiver waits for
max_logical_replication_workers = 10 # taken from max_worker_processes
max_sync_workers_per_subscription = 5 # taken from
max_logical_replication_workers
I've tried increasing wal_sender_timeout and wal_receiver_timeout to 10
minutes each, but this had no positive effect.
Some advice would be helpful
--
Willy-Bas Loos
Lane wrote:
> Willy-Bas Loos writes:
> > Will there be a lot of downtime to delete those 90GB of temp files?
> > Will postgres just delete those files without processing them or should I
> > brace for some downtime?
>
> It's just a directory scan and an unlin
Ok, thanks everyone!
Will there be a lot of downtime to delete those 90GB of temp files?
Will postgres just delete those files without processing them or should I
brace for some downtime?
Op ma 27 jan. 2020 17:15 schreef Tom Lane :
> Willy-Bas Loos writes:
> > And also: How c
y files in the database.
Could the amount of temp files be caused by the unfinished query? I'm not
sure how strong Signal 6 is exactly.
And also: How can i make postgres clean up the files?
Can it be done without restarting the cluster?
Will restarting it help?
--
Willy-Bas Loos
mple i made a mistake too, but that was beside the point
really.
Cheers,
Willy-Bas
On Thu, Aug 29, 2019 at 3:35 PM Tom Lane wrote:
> Willy-Bas Loos writes:
> > I currently have a fairly complex use case to solve and one thing i tried
> > was a deferred constraint trigger. I'
ve exactly 1 corresponding records in b
of type 1. But after this delete the a-record with id 1 would have 0
b-records of type 1, so the operation has been cancelled.
delete from b;
--DELETE 3
--Query returned successfully in 91 msec.
--
Willy-Bas Loos
t session (for anyone else reading this, no need to set it in the
settings file, the above is an sql command).
And then it is possible to view the full list in the log (e.g. after
rolling back the transaction with the drop query).
Cheers,
--
Willy-Bas Loos
ult setting is to not log the list.
So long story short: i think it would be wise to set the log level of "drop
cascade" lists to "warning".
Cheers,
--
Willy-Bas Loos
27 matches
Mail list logo
