در کنفرانس PGConf.EU، تیمی از GitLab با مشکلی معکوس نسبت به گذشته مواجه شدند. آنها قصد داشتند یک جدول ۴ ترابایتی را در PostgreSQL حذف کنند که در سرور اصلی و ده replica قرار داشت. این جدول آرشیوی بود و هیچ داده‌ای به آن نوشته نمی‌شد و نباید خوانده می‌شد. راه‌حل معمول برای چنین وضعیتی استفاده از دستور DROP TABLE است، اما در اینجا باید با کمترین تأثیر ممکن انجام می‌شد.
یکی از چالش‌ها این بود که آیا هنوز کسی از این جدول استفاده می‌کند یا خیر. همچنین، میزان داده‌ای که kernel در cache نگه داشته و نحوه قرارگیری فایل‌ها بر روی دیسک نیز اهمیت داشت. برای ارزیابی این موضوع، آزمایش‌هایی روی دو ماشین Hetzner و یک ماشین GCE انجام شد. در این آزمایش‌ها، PostgreSQL 18.6 با data checksums فعال و autovacuum غیرفعال استفاده شد.
در این فرآیند، استفاده از WAL (Write-Ahead Log) و Load Balancer که خواندن‌ها را بر اساس تاخیر replica مدیریت می‌کند، نقش مهمی داشت. یکی از مشکلاتی که ممکن است رخ دهد این است که "هیچ‌کس نباید از آن بخواند" فقط تا حدی درست باشد. در چنین شرایطی، استفاده از AccessExclusiveLock برای DROP TABLE ضروری است که ممکن است با درخواست‌های دیگر تداخل داشته باشد.
برای کاهش این تداخل، GitLab از یک framework مهاجرتی استفاده می‌کند که DDLها را در یک حلقه retry با lock timeout کوتاه قرار می‌دهد. همچنین، در صورت وجود کلیدهای خارجی، هر کلید خارجی باید در یک مهاجرت جداگانه حذف شود تا ترافیک همزمان را متوقف نکند.
