Re: Non-text mode for pg_dumpall

From: Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Mahendra Singh Thalor <mahi6run(at)gmail(dot)com>
Cc: jian he <jian(dot)universality(at)gmail(dot)com>, Srinath Reddy <srinath2133(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Non-text mode for pg_dumpall
Date: 2025-02-19 21:09:16
Message-ID: 202502192109.5ifhfegolh6w@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello,

I think the business with an evergrowing on_exit list needs a different
solution than a gigantic array of entries. Maybe it would make sense to
restructure that code so that there's a single on_exit item, but there
exists a list of per-database entries to clean up which are all done in
one call of the function. Then you don't need to change the hardcoded
MAX_ON_EXIT_NICELY array size there.

I think it would be better to have a preparatory 0001 patch that just
moves the code to the new files, without touching anything else, and
then the new feature is introduced as a separate 0002 commit.

You still have a bunch of XXX items here and there which look to me like
they need to be handled before this patch can be considered final, plus
the TODOs in the commit message. Please pgindent.

Thanks

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"Porque francamente, si para saber manejarse a uno mismo hubiera que
rendir examen... ¿Quién es el machito que tendría carnet?" (Mafalda)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Melanie Plageman 2025-02-19 21:14:30 Re: BitmapHeapScan streaming read user and prelim refactoring
Previous Message Tomas Vondra 2025-02-19 20:21:59 Re: Adjusting hash join memory limit to handle batch explosion