# Londiste Trick

DevFeed: [Londiste Trick](<https://devfeed.tech/articles/londiste-trick-34335.md>)

Original publisher: [Read original article](<https://tapoueh.org/blog/2009/01/londiste-trick/>)

Author: Dimitri Fontaine PostgreSQL Major Contributor; Author

Published: 2009-01-20T23:00:00Z

Content type: tutorial

Language: en

Sources: [Dimitri Fontaine](<https://devfeed.tech/sources/dimitri-fontaine.md>)

Topics: [Replication](<https://devfeed.tech/topics/replication.md>), [Query (disambiguation)](<https://devfeed.tech/topics/query.md>), [configuration](<https://devfeed.tech/topics/configuration.md>)

Tags: [batch](<https://devfeed.tech/tags/batch.md>), [configuration](<https://devfeed.tech/tags/configuration.md>), [load](<https://devfeed.tech/tags/load.md>), [memory](<https://devfeed.tech/tags/memory.md>), [query](<https://devfeed.tech/tags/query.md>), [replication](<https://devfeed.tech/tags/replication.md>)

## AI overview

This article explains how a stalled Londiste ticker can cause a replication daemon to load millions of accumulated events into memory at once after a restart. It recommends configuring lazy event fetching in the daemon's .ini file so events are loaded in smaller batches.

## Source excerpt

So, you're using londiste and the ticker has not been running all night long, due to some restart glitch in your procedures, and the on call admin didn't notice the restart failure. If you blindly restart the replication daemon, it will load in memory all those events produced during the night, at once, because you now have only one tick where to put them all. The following query allows you to count how many events that represents, with the magic tick numbers coming from pgq.subscription in columns sub_last_tick and sub_next_tick.