On Thu, 16 Oct 2025 at 16:24, Mahendra Singh Thalor <[email protected]> wrote: > > On Wed, 15 Oct 2025 at 23:05, Mahendra Singh Thalor <[email protected]> > wrote: > > > > On Sun, 24 Aug 2025 at 22:12, Andrew Dunstan <[email protected]> wrote: > > > > > > > > > On 2025-08-23 Sa 9:08 PM, Noah Misch wrote: > > > > > > On Wed, Jul 30, 2025 at 02:51:59PM -0400, Andrew Dunstan wrote: > > > > > > OK, now that's reverted we should discuss how to proceed. I had two > > > thoughts > > > - we could use invent a JSON format for the globals, or we could just use > > > the existing archive format. I think the archive format is pretty > > > flexible, > > > and should be able to accommodate this. The downside is it's not humanly > > > readable. The upside is that we don't need to do anything special either > > > to > > > write it or parse it. > > > > > > I would first try to use the existing archiver API, because that makes it > > > harder to miss bugs. Any tension between that API and pg_dumpall is > > > likely to > > > have corresponding tension on the pg_restore side. Resolving that tension > > > will reveal much of the project's scope that remained hidden during the > > > v18 > > > attempt. Perhaps more important than that, using the archiver API means > > > future pg_dump and pg_restore options are more likely to cooperate > > > properly > > > with $SUBJECT. In other words, I want it to be hard to add > > > pg_dump/pg_restore > > > features that malfunction only for $SUBJECT archives. The strength of the > > > archiver architecture shows in how rarely new features need > > > format-specific > > > logic and how rarely format-specific bugs get reported. We've had little > > > or > > > no trouble with e.g. bugs that appear in -Fd but not in -Fc. > > > > > > > > > Yeah, that's what we're going to try. > > > > > > > > > cheers > > > > > > > > > andrew > > > > > > -- > > > Andrew Dunstan > > > EDB: https://www.enterprisedb.com > > > > Thanks Andrew, Noah and all others for feedback. > > > > Based on the above suggestions and discussions, I removed sql commands > > from the global.dat file. For global commands, now we are making > > toc.dat/toc.dmp/toc.tar file based on format specified and based on > > format specified, we are making archive entries for these global > > commands. By this approach, we removed the hard-coded parsing part of > > the global.dat file and we are able to skip DROP DATABASE with the > > globals-only option. > > > > Here, I am attaching a patch for review, testing and feedback. This is > > a WIP patch. I will do some more code cleanup and will add some more > > comments also. Please review this and let me know design level > > feedback. Thanks Tushar Ahuja for some internal testing and feedback. > > > > Hi, > Here, I am attaching an updated patch. In offline discussion, Andrew > reported some test-case failures(Thanks Andrew). I fixed those. > Please let me know feedback for the patch. >
Hi, Here I am attaching a re-based patch as v02 was failing on head. Thanks Tushar for the testing. Please review this and let me know feedback. -- Thanks and Regards Mahendra Singh Thalor EnterpriseDB: http://www.enterprisedb.com
v03-28102025-Non-text-modes-for-pg_dumpall-correspondingly-change.patch
Description: Binary data
