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 -fstack-protector
> --param=ssp-buffer-size=4 -
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 -Wmissing-prototype
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
pg_filedump-9.5.0.tar.
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 to
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
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
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 ment
Em domingo, 31 de agosto de 2014, Christoph Berg escreveu:
> Re: Fabrízio de Royes Mello 2014-06-25
> >
> > On Wed, Jun 25, 2014 at 3:52 PM, Tom Lane > 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 all the
Re: Fabrízio de Royes Mello 2014-06-25
> On Wed, Jun 25, 2014 at 3:52 PM, Tom Lane 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 all the comments to C89
> > style and then pgindent it, but I don't see myself get
=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= 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 C89
style and then p
On Wed, Jun 25, 2014 at 1:28 PM, Tom Lane wrote:
>
> =?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes:
> > On Wed, Jun 25, 2014 at 12:31 PM, Tom Lane wrote:
> >> Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= writes:
> >>> Will there be a pg_filedump for 9.4? I'd like to finish package tests
> >>> before we
=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes:
> On Wed, Jun 25, 2014 at 12:31 PM, Tom Lane wrote:
>> Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= 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
On Wed, Jun 25, 2014 at 12:31 PM, Tom Lane wrote:
>
> Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= 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
Devrim =?ISO-8859-1?Q?G=FCnd=FCz?= 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.
regards, tom l
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 , @DevrimGunduzT
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
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 noti
Alvaro Herrera 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 hand, trying to be ni
Tom Lane escribió:
> Alvaro Herrera 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
>
Josh Berkus 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 committed
On 07/08/2013 04:59 PM, Tom Lane wrote:
> Alvaro Herrera 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
Alvaro Herrera 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 of them is set. Bu
On Mon, Jul 8, 2013 at 11:52 AM, Alvaro Herrera
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 one of the others whe
Peter Geoghegan escribió:
> On Mon, Jul 8, 2013 at 10:28 AM, Jeff Davis 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
On Mon, Jul 8, 2013 at 10:28 AM, Jeff Davis 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 bits.
Alvar
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 produc
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?
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 t
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 use
Andres Freund 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 backups).
> Why not
On 2013-06-27 09:51:07 -0400, Tom Lane wrote:
> Andres Freund 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 t
On Thu, Jun 27, 2013 at 12:07 AM, Peter Geoghegan 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 cute w
On Tue, Jun 18, 2013 at 9:42 AM, Jeff Davis 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 cute with re-using
On 2013-06-26 23:42:55 -0700, Peter Geoghegan wrote:
> On Wed, Jun 26, 2013 at 11:27 PM, Andres Freund
> 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 po
On Wed, Jun 26, 2013 at 11:27 PM, Andres Freund 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 had considered that, b
On 2013-06-26 21:18:49 -0700, Peter Geoghegan wrote:
> On Wed, Jun 26, 2013 at 8:27 PM, Tom Lane 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 th
On Wed, Jun 26, 2013 at 8:27 PM, Tom Lane 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 sufficiently exc
Jeff Davis 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 built
>> agains
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 pg_filed
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 pg_filed
Josh Kupershmidt 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 release), and
>
On Tue, Jun 18, 2013 at 12:42 PM, Jeff Davis 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 CommitFest, does
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 t
Andres Freund 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 there's not any real
On 2013-06-14 11:59:04 -0400, Tom Lane wrote:
> Jeff Davis 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, bu
Jeff Davis 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 tries. Two idea
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 ne
Jeff Davis 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 like
#include
Alvaro Herrera 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 think a
> .h would
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
> > che
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
Alvaro Herrera 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 guess someone tha
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
s
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 w
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 & H
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 tw
Alvaro Herrera 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 seems like rather a wart (no
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
2011/1/18 Robert Haas :
> On Tue, Jan 18, 2011 at 10:53 AM, Tom Lane wrote:
>> David Fetter 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 act
On Tue, Jan 18, 2011 at 10:53 AM, Tom Lane wrote:
> David Fetter 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,
David Fetter 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
exception, the e
On Tue, Jan 18, 2011 at 09:14:41PM +1300, Mark Kirkwood wrote:
> On 18/01/11 18:04, Tom Lane wrote:
> >David Fetter 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
On 18/01/11 18:04, Tom Lane wrote:
David Fetter 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 product
being excl
David Fetter 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 holder(s)? If i
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
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
folk
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 o
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
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 bu
Tatsuo Ishii 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 mailing list (pgsql-hacke
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:
Tom Lane wrote:
> Alvaro Herrera 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 th
Tom Lane wrote:
> Alvaro Herrera 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 th
Alvaro Herrera 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 key not a data entry.
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
*
* F
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?
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 ch
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 bog
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,
79 matches
Mail list logo
