Re: [HACKERS] pg_filedump doesn't compile with v10 sources

Hi, On Mon, Jun 26, 2017 at 12:25 PM, tushar wrote: > Hi, > > While trying to do - make of pg_filedump against v10 sources , getting an > errors > > [centos@centos-cpula pg_filedump]$ make > cc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions

[HACKERS] pg_filedump doesn't compile with v10 sources

Hi, While trying to do - make of pg_filedump against v10 sources , getting an errors [centos@centos-cpula pg_filedump]$ make cc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -DLINUX_OOM_ADJ=0 -Wall

[HACKERS] pg_filedump 9.5.0

Re: To Pavel Raiskup 2016-03-19 <20160319170614.gb8...@msg.df7cb.de> > thanks for the patches, I've pushed them to the git repo. > > http://git.postgresql.org/gitweb/?p=pg_filedump.git We don't have any place to put releases, so I'm posting the tar ball here... Christoph

Re: [HACKERS] pg_filedump patch for 9.5

Re: Pavel Raiskup 2016-02-26 <8883822.6jzmttx...@nb.usersys.redhat.com> > On Saturday 08 of August 2015 20:38:38 Satoshi Nagayasu wrote: > > I have created a patch for pg_filedump to work with 9.5. > > Here is a list of changes. > > > > * Fix to rename CRC32 macros to work with 9.5. > > * Fix

Re: [HACKERS] pg_filedump patch for 9.5

On Saturday 08 of August 2015 20:38:38 Satoshi Nagayasu wrote: > I have created a patch for pg_filedump to work with 9.5. > Here is a list of changes. > > * Fix to rename CRC32 macros to work with 9.5. > * Fix to add missing DBState: DB_SHUTDOWNED_IN_RECOVERY. > * Fix to add missing page flags

[HACKERS] pg_filedump patch for 9.5

Hi, I have created a patch for pg_filedump to work with 9.5. Here is a list of changes. * Fix to rename CRC32 macros to work with 9.5. * Fix to add missing DBState: DB_SHUTDOWNED_IN_RECOVERY. * Fix to add missing page flags for Btree and GIN. * Update copyright date. Please take a look. Any

Re: [HACKERS] pg_filedump for 9.4?

Re: Fabrízio de Royes Mello 2014-06-25 CAFcNs+oAb8h-0w2vLEWj6R-Gv=xizgdBya3K=SCd_9Tjyo=z...@mail.gmail.com On Wed, Jun 25, 2014 at 3:52 PM, Tom Lane t...@sss.pgh.pa.us wrote: Would like that, but I'm not sure what pgindent will do with the // comments. It's been on my to-do list to switch

Re: [HACKERS] pg_filedump for 9.4?

Em domingo, 31 de agosto de 2014, Christoph Berg c...@df7cb.de escreveu: Re: Fabrízio de Royes Mello 2014-06-25 CAFcNs+oAb8h-0w2vLEWj6R-Gv=xizgdBya3K=SCd_9Tjyo=z...@mail.gmail.com javascript:; On Wed, Jun 25, 2014 at 3:52 PM, Tom Lane t...@sss.pgh.pa.us javascript:; wrote: Would like

Re: [HACKERS] pg_filedump for 9.4?

Hi community, while I am currently investigating why a certain table with highly redundant and utterly verbose xml becomes worse storage wise when making the xml more compact. Since i am quite new to this, I believe its the lz compression in the text database. But thats irrelevant now, just

[HACKERS] pg_filedump for 9.4?

Hi, Will there be a pg_filedump for 9.4? I'd like to finish package tests before we release 9.4.0. Regards, -- Devrim GÜNDÜZ Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Twitter: @DevrimGunduz ,

Re: [HACKERS] pg_filedump for 9.4?

Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= dev...@gunduz.org writes: Will there be a pg_filedump for 9.4? I'd like to finish package tests before we release 9.4.0. Probably, but I have no time for it right now. FWIW, I believe the current 9.3 sources still work with HEAD/9.4.

Re: [HACKERS] pg_filedump for 9.4?

On Wed, Jun 25, 2014 at 12:31 PM, Tom Lane t...@sss.pgh.pa.us wrote: Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= dev...@gunduz.org writes: Will there be a pg_filedump for 9.4? I'd like to finish package tests before we release 9.4.0. Probably, but I have no time for it right now. FWIW, I believe

Re: [HACKERS] pg_filedump for 9.4?

=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= fabriziome...@gmail.com writes: On Wed, Jun 25, 2014 at 12:31 PM, Tom Lane t...@sss.pgh.pa.us wrote: Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= dev...@gunduz.org writes: Will there be a pg_filedump for 9.4? I'd like to finish package tests before we release

Re: [HACKERS] pg_filedump for 9.4?

On Wed, Jun 25, 2014 at 1:28 PM, Tom Lane t...@sss.pgh.pa.us wrote: =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= fabriziome...@gmail.com writes: On Wed, Jun 25, 2014 at 12:31 PM, Tom Lane t...@sss.pgh.pa.us wrote: Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= dev...@gunduz.org writes: Will there be a

Re: [HACKERS] pg_filedump for 9.4?

=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= fabriziome...@gmail.com writes: I'm thinking in run pgindent to better organize the source code... What do you think? Would like that, but I'm not sure what pgindent will do with the // comments. It's been on my to-do list to switch all the comments to

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

On Wed, 2013-07-17 at 13:43 -0400, Alvaro Herrera wrote: Tom Lane escribió: My feeling about this code is that the reason we print the infomask in hex is so you can see exactly which bits are set if you care, and that the rest of the line ought to be designed to interpret the bits in as

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

Tom Lane escribió: Alvaro Herrera alvhe...@2ndquadrant.com writes: Well, Tom opined in http://www.postgresql.org/message-id/23249.1370878...@sss.pgh.pa.us that the current patch is okay. I have a mild opinion that it should instead print only SHR_LOCK when both bits are set, and one of

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

Alvaro Herrera alvhe...@2ndquadrant.com writes: The one I was talking about is the second case, which prints KEYSHR_LOCK|EXCL_LOCK to mean that there's a FOR SHARE lock. I have no problem reading it this way, but I fear that someone unfamiliar with these bits might be confused. On the other

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

Tom Lane escribió: My feeling about this code is that the reason we print the infomask in hex is so you can see exactly which bits are set if you care, and that the rest of the line ought to be designed to interpret the bits in as reader-friendly a way as possible. So I don't buy the notion

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

On 07/08/2013 04:59 PM, Tom Lane wrote: Alvaro Herrera alvhe...@2ndquadrant.com writes: Well, Tom opined in http://www.postgresql.org/message-id/23249.1370878...@sss.pgh.pa.us that the current patch is okay. I have a mild opinion that it should instead print only SHR_LOCK when both bits are

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

Josh Berkus j...@agliodbs.com writes: On 07/08/2013 04:59 PM, Tom Lane wrote: FWIW, I think that's exactly what I did in the preliminary 9.3 patch that I committed to pg_filedump a few weeks ago. Could you take a look at what's there now and see if that's what you meant? So, is this getting

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

On Fri, 2013-07-05 at 22:43 -0700, Jeff Davis wrote: On Sat, 2013-07-06 at 10:30 +0900, Satoshi Nagayasu wrote: Hi, It looks fine, but I have one question here. When I run pg_filedump with -k against a database cluster which does not support checksums, pg_filedump produced checksum

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

On Mon, Jul 8, 2013 at 10:28 AM, Jeff Davis pg...@j-davis.com wrote: I see this patch is still waiting on author in the CF. Is there something else needed from me, or should we move this to ready for committer? Well, obviously someone still needs to think through the handling of the infoMask

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

Peter Geoghegan escribió: On Mon, Jul 8, 2013 at 10:28 AM, Jeff Davis pg...@j-davis.com wrote: I see this patch is still waiting on author in the CF. Is there something else needed from me, or should we move this to ready for committer? Well, obviously someone still needs to think

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

On Mon, Jul 8, 2013 at 11:52 AM, Alvaro Herrera alvhe...@2ndquadrant.com wrote: Well, Tom opined in http://www.postgresql.org/message-id/23249.1370878...@sss.pgh.pa.us that the current patch is okay. I have a mild opinion that it should instead print only SHR_LOCK when both bits are set, and

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

Alvaro Herrera alvhe...@2ndquadrant.com writes: Well, Tom opined in http://www.postgresql.org/message-id/23249.1370878...@sss.pgh.pa.us that the current patch is okay. I have a mild opinion that it should instead print only SHR_LOCK when both bits are set, and one of the others when only one

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

Hi, I have reviewed this patch as a CF reviewer. (2013/06/27 4:07), Jeff Davis wrote: On Mon, 2013-06-24 at 20:34 -0400, Josh Kupershmidt wrote: This patch is in the current CommitFest, does it still need to be reviewed? If so, I notice that the version in pgfoundry's CVS is rather different

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

On Sat, 2013-07-06 at 10:30 +0900, Satoshi Nagayasu wrote: Hi, It looks fine, but I have one question here. When I run pg_filedump with -k against a database cluster which does not support checksums, pg_filedump produced checksum error as following. Is this expected or acceptable? Thank

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

On Thu, 2013-06-27 at 15:59 +0200, Andres Freund wrote: Maybe the trick is to add a recovery.conf option to make postgres replay to the first restartpoint and then shutdown. At that point you can be sure there aren't any torn pages anymore (bugs aside). In fact that sounds like a rather useful

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

On 2013-06-26 21:18:49 -0700, Peter Geoghegan wrote: On Wed, Jun 26, 2013 at 8:27 PM, Tom Lane t...@sss.pgh.pa.us wrote: TBH, I've always been annoyed that pg_filedump is GPL and so there's no way for us to just ship it in contrib. (That stems from Red Hat corporate policy of a dozen years

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

On Wed, Jun 26, 2013 at 11:27 PM, Andres Freund and...@2ndquadrant.com wrote: Why not do this from a function/background worker in the backend where you can go via the buffer manager to avoid torn pages et al. If you use a buffer strategy the cache poisoning et al should be controlleable. I

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

On 2013-06-26 23:42:55 -0700, Peter Geoghegan wrote: On Wed, Jun 26, 2013 at 11:27 PM, Andres Freund and...@2ndquadrant.com wrote: Why not do this from a function/background worker in the backend where you can go via the buffer manager to avoid torn pages et al. If you use a buffer

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

On Tue, Jun 18, 2013 at 9:42 AM, Jeff Davis pg...@j-davis.com wrote: I'm not sure what the resolution of Alvaro's concern was, so I left the flag reporting the same as the previous patch. Alvaro's concern was that the new flags added (those added by the foreign key locks patch) do something

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

On Thu, Jun 27, 2013 at 12:07 AM, Peter Geoghegan p...@heroku.com wrote: I'm not sure what the resolution of Alvaro's concern was, so I left the flag reporting the same as the previous patch. Alvaro's concern was that the new flags added (those added by the foreign key locks patch) do

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

On 2013-06-27 09:51:07 -0400, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: On 2013-06-26 21:18:49 -0700, Peter Geoghegan wrote: Heroku are interested in online verification of basebackups (i.e. using checksums to verify the integrity of heap files as they are backed up,

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

Andres Freund and...@2ndquadrant.com writes: On 2013-06-26 21:18:49 -0700, Peter Geoghegan wrote: Heroku are interested in online verification of basebackups (i.e. using checksums to verify the integrity of heap files as they are backed up, with a view to relying less and less on logical

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

On Mon, 2013-06-24 at 20:34 -0400, Josh Kupershmidt wrote: This patch is in the current CommitFest, does it still need to be reviewed? If so, I notice that the version in pgfoundry's CVS is rather different than the version the patch seems to have been built against (presumably the

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

Jeff Davis pg...@j-davis.com writes: On Mon, 2013-06-24 at 20:34 -0400, Josh Kupershmidt wrote: This patch is in the current CommitFest, does it still need to be reviewed? If so, I notice that the version in pgfoundry's CVS is rather different than the version the patch seems to have been

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

On Wed, Jun 26, 2013 at 8:27 PM, Tom Lane t...@sss.pgh.pa.us wrote: TBH, I've always been annoyed that pg_filedump is GPL and so there's no way for us to just ship it in contrib. (That stems from Red Hat corporate policy of a dozen years ago, but the conflict is real anyway.) If somebody is

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

On Mon, 2013-06-24 at 20:34 -0400, Josh Kupershmidt wrote: This patch is in the current CommitFest, does it still need to be reviewed? If so, I notice that the version in pgfoundry's CVS is rather different than the version the patch seems to have been built against (presumably the

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

On Tue, Jun 18, 2013 at 12:42 PM, Jeff Davis pg...@j-davis.com wrote: Attached a new diff for pg_filedump that makes use of the above change. I'm not sure what the resolution of Alvaro's concern was, so I left the flag reporting the same as the previous patch. This patch is in the current

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

Josh Kupershmidt schmi...@gmail.com writes: This patch is in the current CommitFest, does it still need to be reviewed? If so, I notice that the version in pgfoundry's CVS is rather different than the version the patch seems to have been built against (presumably the pg_filedump-9.2.0.tar.gz

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

On Thu, 2013-06-13 at 20:09 -0400, Tom Lane wrote: What I propose we do about this is reduce backend/storage/page/checksum.c to something like #include postgres.h #include storage/checksum.h #include storage/checksum_impl.h Attached a new diff for pg_filedump that makes use of the above

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

On Thu, 2013-06-13 at 20:09 -0400, Tom Lane wrote: What I propose we do about this is reduce backend/storage/page/checksum.c to something like #include postgres.h #include storage/checksum.h #include storage/checksum_impl.h moving all the code currently in the file into a new .h file.

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

Jeff Davis pg...@j-davis.com writes: I have a question about the commit though: shouldn't both functions be static if they are in a .h file? Otherwise, it could lead to naming conflicts. I suppose it's wrong to include the implementation file twice, but it still might be confusing if someone

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

On 2013-06-14 11:59:04 -0400, Tom Lane wrote: Jeff Davis pg...@j-davis.com writes: I have a question about the commit though: shouldn't both functions be static if they are in a .h file? Otherwise, it could lead to naming conflicts. I suppose it's wrong to include the implementation file

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

Andres Freund and...@2ndquadrant.com writes: On 2013-06-14 11:59:04 -0400, Tom Lane wrote: Ah, you are right, I forgot the #ifndef CHECKSUM_IMPL_H dance. Will fix in a bit. That won't help against errors if it's included in two different files/translation units though. Good point, but

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

Jeff Davis pg...@j-davis.com writes: The patch is a bit ugly: I had to copy some code, and copy the entire checksum.c file (minus some Asserts, which don't work in an external program). Suggestions welcome. What I propose we do about this is reduce backend/storage/page/checksum.c to something

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

On Mon, 2013-06-10 at 01:28 -0400, Alvaro Herrera wrote: Hm, note that XMAX_SHR_LOCK is two bits, so when that flag is present you will get the three lock modes displayed with the above code, which is probably going to be misleading. htup_details.h does this: /* * Use these to test

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

Jeff Davis wrote: I was hesitant to do too much interpretation of the bits. Do you think it would be better to just remove the test for XMAX_SHR_LOCK? I don't know, but then I'm biased because I know what that specific bit combination means. I guess someone that doesn't know is going to be

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

Alvaro Herrera alvhe...@2ndquadrant.com writes: Jeff Davis wrote: I was hesitant to do too much interpretation of the bits. Do you think it would be better to just remove the test for XMAX_SHR_LOCK? I don't know, but then I'm biased because I know what that specific bit combination means. I

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

On Mon, 2013-06-10 at 11:38 -0400, Tom Lane wrote: The thing I'm not too happy about is having to copy the checksum code into pg_filedump. We just got rid of the need to do that for the CRC code, and here it is coming back again. Can't we rearrange the core checksum code similarly to what we

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

Jeff Davis wrote: On Mon, 2013-06-10 at 11:38 -0400, Tom Lane wrote: The thing I'm not too happy about is having to copy the checksum code into pg_filedump. We just got rid of the need to do that for the CRC code, and here it is coming back again. Can't we rearrange the core checksum

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

Alvaro Herrera alvhe...@2ndquadrant.com writes: Jeff Davis wrote: The CRC implementation is entirely in header files. Do you think we need to go that far, or is it fine to just put it in libpgport and link that to pg_filedump? If a lib is okay, use libpgcommon please, not libpgport. But I

[HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

Attached is a first draft of an update to pg_filedump for 9.3. I know pg_filedump is a pgfoundry project, but that seems like it's just there to host the download; so please excuse the slightly off-topic post here on -hackers. I made a few changes to support 9.3, which were mostly fixes related

Re: [HACKERS] pg_filedump 9.3: checksums (and a few other fixes)

Jeff Davis wrote: --- 1000,1015 strcat (flagString, HASEXTERNAL|); if (infoMask HEAP_HASOID) strcat (flagString, HASOID|); + if (infoMask HEAP_XMAX_KEYSHR_LOCK) + strcat (flagString, XMAX_KEYSHR_LOCK|); if (infoMask HEAP_COMBOCID)

[HACKERS] pg_filedump improvements

Alvaro Herrera alvhe...@commandprompt.com writes: Also, what do you think about adding the ability to dump pg_filenode.map files? Do you think it belongs in pg_filedump, or should we look at doing that elsewhere? Not sure. It does already contain the ability to dump pg_control, but that

Re: [HACKERS] pg_filedump moved to pgfoundry

On 18/01/11 18:04, Tom Lane wrote: David Fetterda...@fetter.org writes: Who's the copyright holder(s)? If it's all individual contributors, Red Hat policy is not in play. Sorry David, it was written on the company's dime. However, I doubt that Red Hat derives any value from this useful

Re: [HACKERS] pg_filedump moved to pgfoundry

On Tue, Jan 18, 2011 at 09:14:41PM +1300, Mark Kirkwood wrote: On 18/01/11 18:04, Tom Lane wrote: David Fetterda...@fetter.org writes: Who's the copyright holder(s)? If it's all individual contributors, Red Hat policy is not in play. Sorry David, it was written on the company's dime.

Re: [HACKERS] pg_filedump moved to pgfoundry

David Fetter da...@fetter.org writes: I'm guessing there's a Policy® at Red Hat that software made on its dime be GPL (v2, I'd guess), and that getting an exception would involve convening its board or similarly drastic action. It's company policy, and while it *might* be possible to get an

Re: [HACKERS] pg_filedump moved to pgfoundry

On Tue, Jan 18, 2011 at 10:53 AM, Tom Lane t...@sss.pgh.pa.us wrote: David Fetter da...@fetter.org writes: I'm guessing there's a PolicyŽ at Red Hat that software made on its dime be GPL (v2, I'd guess), and that getting an exception would involve convening its board or similarly drastic

Re: [HACKERS] pg_filedump moved to pgfoundry

2011/1/18 Robert Haas robertmh...@gmail.com: On Tue, Jan 18, 2011 at 10:53 AM, Tom Lane t...@sss.pgh.pa.us wrote: David Fetter da...@fetter.org writes: I'm guessing there's a PolicyŽ at Red Hat that software made on its dime be GPL (v2, I'd guess), and that getting an exception would involve

Re: [HACKERS] pg_filedump moved to pgfoundry

On 19/01/11 05:51, Robert Haas wrote: I'm not sure why they'd care, but it certainly doesn't seem worth spending the amount of time arguing about it that we are. David and Mark are, of course, free to spend their time petitioning Red Hat for relicensing if they are so inclined, but they aren't

[HACKERS] pg_filedump moved to pgfoundry

I've gotten permission to move pg_filedump from its former home at sources.redhat.com to pgfoundry. You can find the historical release tarballs as well as current sources at http://pgfoundry.org/projects/pgfiledump/ One advantage of doing this is it will be a lot easier to let other

Re: [HACKERS] pg_filedump moved to pgfoundry

On Mon, Jan 17, 2011 at 09:48:58PM -0500, Tom Lane wrote: I've gotten permission to move pg_filedump from its former home at sources.redhat.com to pgfoundry. You can find the historical release tarballs as well as current sources at http://pgfoundry.org/projects/pgfiledump/ One

Re: [HACKERS] pg_filedump moved to pgfoundry

David Fetter da...@fetter.org writes: On Mon, Jan 17, 2011 at 09:48:58PM -0500, Tom Lane wrote: (Before someone suggests folding it into contrib/: we can't because of license issues. pg_filedump is GPL, per Red Hat company policy, and that's not going to change.) Who's the copyright

[HACKERS] pg_filedump for 9.0?

Hi, Does anybody know if pg_filedump for PostgreSQL 9.0 already exists? -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] pg_filedump for 9.0?

Tatsuo Ishii is...@postgresql.org writes: Does anybody know if pg_filedump for PostgreSQL 9.0 already exists? It's on my todo list to look at that, but right now I would think that it doesn't need any changes since 8.4. regards, tom lane -- Sent via pgsql-hackers

Re: [HACKERS] pg_filedump for 9.0?

On Tue, 2010-10-05 at 10:12 -0400, Tom Lane wrote: Does anybody know if pg_filedump for PostgreSQL 9.0 already exists? It's on my todo list to look at that, but right now I would think that it doesn't need any changes since 8.4. Is there a test suite or so ? I can give it a try while

Re: [HACKERS] pg_filedump for 9.0?

Excerpts from Devrim GÜNDÜZ's message of mar oct 05 10:16:45 -0400 2010: On Tue, 2010-10-05 at 10:12 -0400, Tom Lane wrote: Does anybody know if pg_filedump for PostgreSQL 9.0 already exists? It's on my todo list to look at that, but right now I would think that it doesn't need any

Re: [HACKERS] pg_filedump for 9.0?

Excerpts from Alvaro Herrera's message of mar oct 05 12:15:45 -0400 2010: Excerpts from Devrim GÜNDÜZ's message of mar oct 05 10:16:45 -0400 2010: On Tue, 2010-10-05 at 10:12 -0400, Tom Lane wrote: Does anybody know if pg_filedump for PostgreSQL 9.0 already exists? It's on my todo

[HACKERS] pg_filedump strangeness

Hi, I'm chasing an apparent index corruption problem, and I came across something I can't quite explain in pg_filedump. Say I dump a non-leaf btree index page: *** * PostgreSQL File/Block Formatted Dump Utility - Version 8.3.0 * *

Re: [HACKERS] pg_filedump strangeness

Alvaro Herrera alvhe...@commandprompt.com writes: I'm chasing an apparent index corruption problem, and I came across something I can't quite explain in pg_filedump. Say I dump a non-leaf btree index page: I think this is actually OK. Remember that in a non-rightmost page, item 1 is the high

Re: [HACKERS] pg_filedump strangeness

Tom Lane wrote: Alvaro Herrera alvhe...@commandprompt.com writes: I'm chasing an apparent index corruption problem, and I came across something I can't quite explain in pg_filedump. Say I dump a non-leaf btree index page: I think this is actually OK. Remember that in a non-rightmost

Re: [HACKERS] pg_filedump strangeness

Tom Lane wrote: Alvaro Herrera alvhe...@commandprompt.com writes: I'm chasing an apparent index corruption problem, and I came across something I can't quite explain in pg_filedump. Say I dump a non-leaf btree index page: I think this is actually OK. Remember that in a non-rightmost

Re: [HACKERS] pg_filedump for CVS HEAD

Alvaro Herrera [EMAIL PROTECTED] writes: Who is in charge of pg_filedump now? It's usually me that fixes it for new PG versions. I don't normally try to track CVS HEAD, just update it at release time. I noticed that the latest version (for 8.3) does not play nice with HEAD, because of

[HACKERS] pg_filedump for CVS HEAD

Hi, Who is in charge of pg_filedump now? I noticed that the latest version (for 8.3) does not play nice with HEAD, because of changes in ControlFileData. The attached patch fixes that, allowing it to compile. I didn't look if there were other changes needed for it to actually work; any clues?

Re: [HACKERS] pg_filedump

Alvaro Herrera [EMAIL PROTECTED] writes: I'm trying to get something from pg_filedump. However, the version published in sources.redhat.com/rhdb doesn't grok a lot of changes in current CVS. I changed all those and made it compile... but looks like that's only the easy part. I get bogus

[HACKERS] pg_filedump

Hello hackers, I'm trying to get something from pg_filedump. However, the version published in sources.redhat.com/rhdb doesn't grok a lot of changes in current CVS. I changed all those and made it compile... but looks like that's only the easy part. I get bogus values everywhere (block sizes,