Normal view
quick demo on org2blog
Fix β 1:
On searching this, https://stackoverflow.com/questions/26356268/call-to-undefined-function-imagecreatefromjpeg-and-gd-enabled
found that we have to install gd library of PHP.
we had installed this already in the server as
sudo apt install php-gd
Now, checked the php version.
php -v PHP 8.1.31 (cli) (built: Nov 21 2024 13:10:15) (NTS)
installed the gd version for it.
sudo apt install php8.1-gd
and restarted apache
sudo systemctl restart apache2
Thatβs all.
Now, unpublished the catalog. re-uploaded the cover images and published again.
Now, the thumbnails are generated.
But they are too small.
Learning Notes #61 β Undo a git pull
Today, i came across a blog on undo a git pull
. In this blog, i have reiterated the blog in other words.
Mistakes happen. You run a git pull
and suddenly find your repository in a mess. Maybe conflicts arose, or perhaps the changes merged from the remote branch arenβt what you expected.
Fortunately, Gitβs reflog comes to the rescue, allowing you to undo a git pull
and restore your repository to its previous state. Hereβs how you can do it.
Understanding Reflog
Reflog is a powerful feature in Git that logs every update made to the tips of your branches and references. Even actions like resets or rebases leave traces in the reflog. This makes it an invaluable tool for troubleshooting and recovering from mistakes.
Whenever you perform a git pull
, Git updates the branch pointer, and the reflog records this action. By examining the reflog, you can identify the exact state of your branch before the pull and revert to it if needed.
Step By Step Guide to UNDO a git pull
1. Check Your Current State Ensure youβre aware of the current state of your branch. If you have uncommitted changes, stash or commit them to avoid losing any work.
git stash # or git add . && git commit -m "Save changes before undoing pull"
2. Inspect the Reflog View the recent history of your branch using the reflog,
git reflog
This command will display a list of recent actions, showing commit hashes and descriptions. For example,
0a1b2c3 (HEAD -> main) HEAD@{0}: pull origin main: Fast-forward 4d5e6f7 HEAD@{1}: commit: Add new feature 8g9h0i1 HEAD@{2}: checkout: moving from feature-branch to main
3. Identify the Pre-Pull Commit Locate the commit hash of your branchβs state before the pull. In the above example, itβs 4d5e6f7
, which corresponds to the commit made before the git pull
.
4. Reset to the Previous Commit Use the git reset
command to move your branch back to its earlier state,
git reset <commit-hash>
By default, itβs mixed so changes wont be removed but will be in staging.
The next time a pull operation goes awry, donβt panicβlet the reflog guide you back to safety!
Postgres β Write-Ahead Logging (WAL) in PostgreSQL
Write-Ahead Logging (WAL) is a fundamental feature of PostgreSQL, ensuring data integrity and facilitating critical functionalities like crash recovery, replication, and backup.
This series of experimentation explores WAL in detail, its importance, how it works, and provides examples to demonstrate its usage.
What is Write-Ahead Logging (WAL)?
WAL is a logging mechanism where changes to the database are first written to a log file before being applied to the actual data files. This ensures that in case of a crash or unexpected failure, the database can recover and replay these logs to restore its state.
Your question is right !
Why do we need a WAL, when we do a periodic backup ?
Write-Ahead Logging (WAL) is critical even when periodic backups are in place because it complements backups to provide data consistency, durability, and flexibility in the following scenarios.
1. Crash Recovery
- Why Itβs Important: Periodic backups only capture the database state at specific intervals. If a crash occurs after the latest backup, all changes made since that backup would be lost.
- Role of WAL: WAL ensures that any committed transactions not yet written to data files (due to PostgreSQLβs lazy-writing behavior) are recoverable. During recovery, PostgreSQL replays the WAL logs to restore the database to its last consistent state, bridging the gap between the last checkpoint and the crash.
Example:
- Backup Taken: At 12:00 PM.
- Crash Occurs: At 1:30 PM.
- Without WAL: All changes after 12:00 PM are lost.
- With WAL: All changes up to 1:30 PM are recovered.

2. Point-in-Time Recovery (PITR)
- Why Itβs Important: Periodic backups restore the database to the exact time of the backup. However, this may not be sufficient if you need to recover to a specific point, such as just before a mistake (e.g., accidental data deletion).
- Role of WAL: WAL records every change, enabling you to replay transactions up to a specific time. This allows fine-grained recovery beyond what periodic backups can provide.
Example:
- Backup Taken: At 12:00 AM.
- Mistake Made: At 9:45 AM, an important table is accidentally dropped.
- Without WAL: Restore only to 12:00 AM, losing 9 hours and 45 minutes of data.
- With WAL: Restore to 9:44 AM, recovering all valid changes except the accidental drop.

3. Replication and High Availability
- Why Itβs Important: In a high-availability setup, replicas must stay synchronized with the primary database to handle failovers. Periodic backups cannot provide real-time synchronization.
- Role of WAL: WAL enables streaming replication by transmitting logs to replicas, ensuring near real-time synchronization.
Example:
- A primary database sends WAL logs to replicas as changes occur. If the primary fails, a replica can quickly take over without data loss.

4. Handling Incremental Changes
- Why Itβs Important: Periodic backups store complete snapshots of the database, which can be time-consuming and resource-intensive. They also do not capture intermediate changes.
- Role of WAL: WAL allows incremental updates by recording only the changes made since the last backup or checkpoint. This is crucial for efficient data recovery and backup optimization.
5. Ensuring Data Durability
- Why Itβs Important: Even during normal operations, a database crash (e.g., power failure) can occur. Without WAL, transactions committed by users but not yet flushed to disk are lost.
- Role of WAL: WAL ensures durability by logging all changes before acknowledging transaction commits. This guarantees that committed transactions are recoverable even if the system crashes before flushing the changes to data files.

6. Supporting Hot Backups
- Why Itβs Important: For large, active databases, taking a backup while the database is running can result in inconsistent snapshots.
- Role of WAL: WAL ensures consistency by recording changes that occur during the backup process. When replayed, these logs synchronize the backup, ensuring it is valid and consistent.
7. Debugging and Auditing
- Why Itβs Important: Periodic backups are static snapshots and donβt provide a record of what happened in the database between backups.
- Role of WAL: WAL contains a sequential record of all database modifications, which can help in debugging issues or auditing transactions.
Feature | Periodic Backups | Write-Ahead Logging |
---|---|---|
Crash Recovery | Limited to the last backup | Ensures full recovery to the crash point |
Point-in-Time Recovery | Restores only to the backup time | Allows recovery to any specific point |
Replication | Not supported | Enables real-time replication |
Efficiency | Full snapshot | Incremental changes |
Durability | Relies on backup frequency | Guarantees transaction durability |
In upcoming sessions, we will all experiment each one of the failure scenarios for understanding.
Kate β unsung excellent editor by KDE
Nowadays, eventhough I am becoming an avid fan of Emacs editor, sometime I use other editors.
Kate is one of the nice editor, I am using for many years, as KDE is my desktop.
Kate is a simple GUI based text editor, which has very good features. explore its features here β https://kate-editor.org/about-kate/
Few days back, I was explore few huge airflow log files, to find some specific errors. KDE opened the log file automatically in Kate editor.
For my surprise, it opened the huge files with highlighting the error lines.
As I am using CLI editors on local and remote machines most of the times, I have to go through all the lines always. Eyes are trained to skim quickly and find the errors patterns easily. But at this time, the Kate editor, gave color different for all the error messages. The right side small preview window helped to goto next error sections easily.
These may be the default features of other IDEs or modern editors. But, these are new tiny happy inventions for me.
Thanks KDE team and Kate developers for making our life easier and bringing happiness to all.
What are the other open source editors have these features? What is the editor you are using? Share your thoughts in your blog and reply here with the URL.