On Fri, Dec 2, 2016 at 1:36 PM, Haribabu Kommi wrote:
> Patch received feedback at the end of commitfest.
> Closed in 2016-11 commitfest with "moved to next CF".
> Please feel free to update the status once you submit the updated patch.
And the thread has died as well weeks ago. I am marking that
On Fri, Dec 2, 2016 at 2:21 AM, Vladimir Rusinov
wrote:
> This patch does not have a reviewer, so I've decided to try myself on.
>
> Disclaimer: although I review quite a lot of code daily, this is my first
> review for PostgreSQL. I don't know code very well, and frankly I don't
> really know C
This patch does not have a reviewer, so I've decided to try myself on.
Disclaimer: although I review quite a lot of code daily, this is my first
review for PostgreSQL. I don't know code very well, and frankly I don't
really know C very well.
Hope my effort are not vain and will be helpful to someb
On Mon, Jul 18, 2016 at 8:10 PM, Magnus Hagander wrote:
>
>
> On Thu, Jul 14, 2016 at 8:27 PM, Andres Freund wrote:
>>
>> On 2016-07-14 13:46:23 +0200, Magnus Hagander wrote:
>> > Currently, if you run pg_xlogdump with -f, you have to specify an end
>> > position in an existing file, or if you do
On Fri, Aug 26, 2016 at 10:03 PM, Fujii Masao wrote:
> On Wed, Mar 23, 2016 at 7:04 PM, Pavan Deolasee
> wrote:
>>
>>
>> On Wed, Mar 23, 2016 at 1:13 PM, Michael Paquier
>> wrote:
>>>
>>>
>>> + /*
>>> +* Compute targetRecOff. It should typically be greater than short
>>> +*
On Wed, Mar 23, 2016 at 7:04 PM, Pavan Deolasee
wrote:
>
>
> On Wed, Mar 23, 2016 at 1:13 PM, Michael Paquier
> wrote:
>>
>>
>> + /*
>> +* Compute targetRecOff. It should typically be greater than short
>> +* page-header since a valid record can't , but can also be zero
>> w
On Thu, Jul 14, 2016 at 8:27 PM, Andres Freund wrote:
> On 2016-07-14 13:46:23 +0200, Magnus Hagander wrote:
> > Currently, if you run pg_xlogdump with -f, you have to specify an end
> > position in an existing file, or if you don't it will only follow until
> the
> > end of the current file.
>
>
On 2016-07-14 13:46:23 +0200, Magnus Hagander wrote:
> Currently, if you run pg_xlogdump with -f, you have to specify an end
> position in an existing file, or if you don't it will only follow until the
> end of the current file.
That's because specifying a file explicitly says that you only want
On 14 July 2016 at 07:46, Magnus Hagander wrote:
> Currently, if you run pg_xlogdump with -f, you have to specify an end
> position in an existing file, or if you don't it will only follow until the
> end of the current file.
>
> That seems like an oversight - if you specify -f with no end positi
On Mon, Jul 11, 2016 at 5:20 PM, Andres Freund wrote:
> On 2016-07-11 13:36:37 +0200, Magnus Hagander wrote:
> > When you don't specify a start segment to pg_xlogdump, you get:
> >
> > pg_xlogdump: no start log position given in range mode.
> >
> >
> > What is "range mode", and is there any other
Currently, if you run pg_xlogdump with -f, you have to specify an end
position in an existing file, or if you don't it will only follow until the
end of the current file.
That seems like an oversight - if you specify -f with no end position, it
should follow "into the future" for any new files tha
On 2016-07-11 13:36:37 +0200, Magnus Hagander wrote:
> When you don't specify a start segment to pg_xlogdump, you get:
>
> pg_xlogdump: no start log position given in range mode.
>
>
> What is "range mode", and is there any other mode for pg_xlogdump? Should
> it not just be "no start log positi
When you don't specify a start segment to pg_xlogdump, you get:
pg_xlogdump: no start log position given in range mode.
What is "range mode", and is there any other mode for pg_xlogdump? Should
it not just be "no start log position or segment given" or something like
that?
--
Magnus Hagander
On 1 April 2016 at 21:30, Craig Ringer wrote:
> I'll attach the new testcase once I either get it to reproduce this bug or
> give up and leave the basic xlogdump testcase alone.
>
I had another bash at this and I still can't reproduce it on master using
the giant commit record approach Andres s
On 31 March 2016 at 16:13, Andres Freund wrote:
> It's probably easier to just generate a humongous commit record. You can
> do so by having a *lot* of subtransactions. Relatively easy to do with
> plpgsql by creating them in a loop (SELECT txid_current() in EXCEPTION
> bearing block ought to su
On 2016-03-31 09:41:46 +0530, Pavan Deolasee wrote:
> On Thu, Mar 31, 2016 at 6:27 AM, Craig Ringer wrote:
> >
> >
> > Can you describe the process used to generate the sample WAL segment?
> >
> >
> Shame that I can't find the sql file used to create the problematic WAL
> segment. But this is what
On Thu, Mar 31, 2016 at 6:27 AM, Craig Ringer wrote:
>
>
> Can you describe the process used to generate the sample WAL segment?
>
>
Shame that I can't find the sql file used to create the problematic WAL
segment. But this is what I did.
I wrote a plpgsql function which inserts rows in a loop, ev
On 23 March 2016 at 18:04, Pavan Deolasee wrote:
>
>
> On Wed, Mar 23, 2016 at 1:13 PM, Michael Paquier <
> michael.paqu...@gmail.com> wrote:
>
>>
>> + /*
>> +* Compute targetRecOff. It should typically be greater than short
>> +* page-header since a valid record can't , but
On 23 March 2016 at 18:04, Pavan Deolasee wrote:
>
>
> On Wed, Mar 23, 2016 at 1:13 PM, Michael Paquier <
> michael.paqu...@gmail.com> wrote:
>
>>
>> + /*
>> +* Compute targetRecOff. It should typically be greater than short
>> +* page-header since a valid record can't , but
On Mon, Mar 28, 2016 at 10:15 PM, Andres Freund wrote:
> It's definitely too late for that; they're going to be wrapped in a
> couple hours.
I have added this patch to the next CF so as we do not lose track of this bug:
https://commitfest.postgresql.org/10/593/
--
Michael
--
Sent via pgsql-ha
On 2016-03-28 13:21:41 +0530, Pavan Deolasee wrote:
> On Wed, Mar 23, 2016 at 6:16 PM, Michael Paquier
> wrote:
>
> >
> >
> > I'd just add dots at the end of the sentences in the comment blocks
> > because that's project style, but I'm being picky, except that the
> > logic looks quite good.
> >
On Wed, Mar 23, 2016 at 6:16 PM, Michael Paquier
wrote:
>
>
> I'd just add dots at the end of the sentences in the comment blocks
> because that's project style, but I'm being picky, except that the
> logic looks quite good.
>
Since this is a bug affecting all stable branches, IMHO it will be a
On Wed, Mar 23, 2016 at 7:04 PM, Pavan Deolasee
wrote:
>
>
> On Wed, Mar 23, 2016 at 1:13 PM, Michael Paquier
> wrote:
>>
>>
>> + /*
>> +* Compute targetRecOff. It should typically be greater than short
>> +* page-header since a valid record can't , but can also be zero
>> w
On Wed, Mar 23, 2016 at 1:13 PM, Michael Paquier
wrote:
>
> + /*
> +* Compute targetRecOff. It should typically be greater than short
> +* page-header since a valid record can't , but can also be zero
> when
> +* caller has supplied a page-aligned address or when we
On Wed, Mar 23, 2016 at 3:43 PM, Pavan Deolasee
wrote:
> While investigating some issue, I found that pg_xlogdump fails to dump
> contents from a WAL file if the file has continuation data from previous WAL
> record and the data spans more than one page. In such cases,
> XLogFindNextRecord() fails
On Mon, Sep 28, 2015 at 9:47 AM, Peter Eisentraut wrote:
> The pg_xlogdump man page states that it cannot read .partial WAL files
> and that they need to be renamed. It seems to me with about the same
> number of lines we could just make it accept those files, no?
FWIW, the discussion has happen
The pg_xlogdump man page states that it cannot read .partial WAL files
and that they need to be renamed. It seems to me with about the same
number of lines we could just make it accept those files, no?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Thu, Mar 19, 2015 at 11:25 AM, Heikki Linnakangas wrote:
> I'm guessing that the current state of affairs is just an oversight. I tried
> changing it so that xlogreader.c is built into pg_xlogdump without copying,
> and it seemed to work. But I'm using a very recent version of MSVC - perhaps
>
When a frontend program needs to compile a file from another directory,
Mkvcbuild.pm usually does something like this:
$pgdumpall->AddFile('src\bin\pg_dump\keywords.c');
$pgdumpall->AddFile('src\backend\parser\kwlookup.c');
But for pg_xlogdump, it does this:
foreach
On 2014-09-19 19:34:08 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > Hi,
> >
> > On 2014-09-19 15:39:37 +0530, Abhijit Menon-Sen wrote:
> > > I've attached the revised patch, split up differently:
> > >
> > > 1. Introduce rm_identify, change rm_desc, glue the two together in
> > >xl
Andres Freund wrote:
> Hi,
>
> On 2014-09-19 15:39:37 +0530, Abhijit Menon-Sen wrote:
> > I've attached the revised patch, split up differently:
> >
> > 1. Introduce rm_identify, change rm_desc, glue the two together in
> >xlog.c
> > 2. Introduce pg_xlogdump --stats[=record].
>
> I've pushed
Hi,
On 2014-09-19 15:39:37 +0530, Abhijit Menon-Sen wrote:
> I've attached the revised patch, split up differently:
>
> 1. Introduce rm_identify, change rm_desc, glue the two together in
>xlog.c
> 2. Introduce pg_xlogdump --stats[=record].
I've pushed these after some fixing up.
As we previ
At 2014-09-19 15:39:37 +0530, a...@2ndquadrant.com wrote:
>
> I hope I didn't miss anything this time.
But of course I did. The attached fixup makes the output of pg_xlogdump
match that of xlog_outdesc for unidentifiable records (UNKNOWN (%x)).
Sorry for the inconvenience.
-- Abhijit
diff --git a
I've attached the revised patch, split up differently:
1. Introduce rm_identify, change rm_desc, glue the two together in
xlog.c
2. Introduce pg_xlogdump --stats[=record].
The requested changes (16, filter, z:, UNKNOWN) are included. The
grammar nitpicking and rebase cruft is^Ware^Wain't inclu
Hi,
On 2014-09-19 14:38:29 +0530, Abhijit Menon-Sen wrote:
> > b) I'm not against it, but I wonder if the best way to add the
> >SizeOfXLogRecord to the record size. It's just as much part of the
> >FPI. And this means that the record length will be > 0 even if all
> >the record data h
At 2014-09-19 10:44:48 +0200, and...@2ndquadrant.com wrote:
>
> > # snprintfs that use %lld, %qd, or %I64d as the format. If none of these
> > -# work, fall back to our own snprintf emulation (which we know uses %lld).
> > +# works, fall back to our own snprintf emulation (which we know uses %lld
At 2014-09-19 13:24:11 +0530, a...@2ndquadrant.com wrote:
>
> Good enough?
Not quite. I've attached a small additional patch that shifts the
responsibility of adding rm_name to the output from xlog_outrec to
xlog_outdesc. Now we get WAL_DEBUG output like this:
LOG: INSERT @ 0/16C51D0: prev 0/16C
On 2014-09-19 13:24:11 +0530, Abhijit Menon-Sen wrote:
> diff --git a/configure.in b/configure.in
> index 1392277..c3c458c 100644
> --- a/configure.in
> +++ b/configure.in
> @@ -1637,7 +1637,7 @@ fi
> # If we found "long int" is 64 bits, assume snprintf handles it. If
> # we found we need to use
Hi.
I've attached two patches here:
0001-Make-pg_xlogdump-record-stats-display-summary-statis.patch is my
earlier patch to pg_xlogdump, rebased to master. It introduces the new
rm_identify callback, but doesn't touch rm_desc. Other than rebasing to
master after the INT64_FORMAT changes, I haven't
On 09/11/2014 12:22 PM, Andres Freund wrote:
On 2014-09-11 12:14:42 +0300, Heikki Linnakangas wrote:
On 09/11/2014 11:43 AM, Abhijit Menon-Sen wrote:
At 2014-08-21 10:06:39 +0300, hlinnakan...@vmware.com wrote:
I think the names that rm_identify returns should match those that the
rm_desc func
On 2014-09-11 12:14:42 +0300, Heikki Linnakangas wrote:
> On 09/11/2014 11:43 AM, Abhijit Menon-Sen wrote:
> >At 2014-08-21 10:06:39 +0300, hlinnakan...@vmware.com wrote:
> >>I think the names that rm_identify returns should match those that the
> >>rm_desc functions print.
> >
> >I had originally
On 09/11/2014 11:43 AM, Abhijit Menon-Sen wrote:
At 2014-08-21 10:06:39 +0300, hlinnakan...@vmware.com wrote:
I think the names that rm_identify returns should match those that the
rm_desc functions print.
I had originally started off trying to keep the output in sync, but it
doesn't work very
At 2014-08-21 10:06:39 +0300, hlinnakan...@vmware.com wrote:
>
> Committed the patch to add INT64_MODIFIER, with minor fixes.
Thank you.
> The new rm_identify method needs to be documented. […]
> Perhaps add comments to the RmgrData struct, explaining
> all of the methods.
OK, I'll submit a patc
On 07/07/2014 10:32 PM, Abhijit Menon-Sen wrote:
At 2014-07-07 09:48:44 +0200, and...@2ndquadrant.com wrote:
I'd suggest only defining INT64_MODIFIER here and build INT64_FORMAT,
UINT64_FORMAT ontop, in c.h.
Oh, I see. I'm sorry, I misread your earlier suggestion. Regenerated
patches attached
At 2014-07-07 09:48:44 +0200, and...@2ndquadrant.com wrote:
>
> I'd suggest only defining INT64_MODIFIER here and build INT64_FORMAT,
> UINT64_FORMAT ontop, in c.h.
Oh, I see. I'm sorry, I misread your earlier suggestion. Regenerated
patches attached. Is this what you had in mind?
-- Abhijit
diff
On 2014-07-04 18:59:07 +0530, Abhijit Menon-Sen wrote:
> At 2014-07-04 11:34:21 +0200, and...@2ndquadrant.com wrote:
> >
> > I think we're going to have to redefine the
> > PGAC_FUNC_SNPRINTF_LONG_LONG_INT_FORMAT callsite in configure.in to
> > define INT64_MODIFIER='"ll/l/I64D"'
>
> I've attached
At 2014-07-04 13:43:46 -0400, alvhe...@2ndquadrant.com wrote:
>
> Now, I see that pg_xlogdump is checking for NULL return, but I'm not
> sure this is the best possible API.
Note that the patched pg_xlogdump will display "rm_name/0xNN" for any
records that rm_identify returns a NULL for.
Earlier,
Andres Freund wrote:
> On 2014-07-04 18:31:34 +0800, gotoschool6g wrote:
> > Carp the code:
> >
> > const char *
> > clog_identify(uint8 info)
> > {
> > switch (info)
> > {
> > case CLOG_ZEROPAGE:
> >return "ZEROPAGE";
> > case CLOG_TRUNCATE:
> >return "TRUNCATE";
>
At 2014-07-04 11:34:21 +0200, and...@2ndquadrant.com wrote:
>
> I think we're going to have to redefine the
> PGAC_FUNC_SNPRINTF_LONG_LONG_INT_FORMAT callsite in configure.in to
> define INT64_MODIFIER='"ll/l/I64D"'
I've attached a patch to do this, and also add INT64_MODIFIER to
pg_config.h.in: 0
On 2014-07-04 18:31:34 +0800, gotoschool6g wrote:
> >
> > I'm pretty sure that most committers would want to apply the
> > rm_identity part in a separate commit first. Could you make it
> > two patches, one introducing rm_identity, and another with
> > xlogdump using it?
>
> Carp the code:
>
>
> I'm pretty sure that most committers would want to apply the
> rm_identity part in a separate commit first. Could you make it
> two patches, one introducing rm_identity, and another with
> xlogdump using it?
Carp the code:
const char *
clog_identify(uint8 info)
{
switch (info)
{
On 2014-07-04 15:34:14 +0530, Abhijit Menon-Sen wrote:
> At 2014-07-04 11:34:21 +0200, and...@2ndquadrant.com wrote:
> >
> > So we're leaking memory here? For --stats that could well be
> > relevant...
>
> Will fix (I think using a static buffer would be OK here).
In that place, yes. There there'
At 2014-07-04 11:34:21 +0200, and...@2ndquadrant.com wrote:
>
> So we're leaking memory here? For --stats that could well be
> relevant...
Will fix (I think using a static buffer would be OK here).
> I think we're going to have to redefine the
> PGAC_FUNC_SNPRINTF_LONG_LONG_INT_FORMAT callsite in
Hi,
On 2014-07-04 14:42:03 +0530, Abhijit Menon-Sen wrote:
> Sure, attached.
>
> +const char *
> +heap_identify(uint8 info)
> +{
> + const char *id = NULL;
> +
> + switch (info & XLOG_HEAP_OPMASK)
> + {
> + case XLOG_HEAP_INSERT:
> + id = "INSERT";
> +
At 2014-07-04 10:54:08 +0200, and...@2ndquadrant.com wrote:
>
> I'm pretty sure that most committers would want to apply the
> rm_identity part in a separate commit first. Could you make it
> two patches, one introducing rm_identity, and another with
> xlogdump using it?
Sure, attached.
-- Abhiji
On 2014-07-04 14:16:42 +0530, Abhijit Menon-Sen wrote:
> At 2014-07-04 08:38:17 +, dilip.ku...@huawei.com wrote:
> >
> > Once you fix above erros, I think patch is ok from my side.
>
> I've attached two updated patches here, including the fix to the usage
> message. I'll mark this ready for co
At 2014-07-04 08:38:17 +, dilip.ku...@huawei.com wrote:
>
> Once you fix above erros, I think patch is ok from my side.
I've attached two updated patches here, including the fix to the usage
message. I'll mark this ready for committer now. (The rm_identify patch
is posted separately from the x
On 04 July 2014 12:07, Abhijit Menon-Sen Wrote,
> -Original Message-
> From: Abhijit Menon-Sen [mailto:a...@2ndquadrant.com]
> Sent: 04 July 2014 12:07
> To: Dilip kumar
> Cc: pgsql-hackers@postgresql.org; furu...@pm.nttdata.co.jp
> Subject: Re: [HACKERS] pg_xlogdump --
At 2014-06-30 05:19:10 +, dilip.ku...@huawei.com wrote:
>
> Please fix these issues and send the updated patch..
>
> I will continue reviewing the patch..
Did you get anywhere with the updated patch?
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On 07/02/2014 09:20 AM, Marti Raudsepp wrote:
> You might also add units (kB/MB) to the table like pg_size_pretty,
> although that would make the magnitudes harder to gauge.
What 'du' does, or a subset of, may be worthwhile.
-k: kB
-b: blocks
-m: MB
-h: human-readable auto-scaling
though I thin
At 2014-07-02 04:20:31 +0300, ma...@juffo.org wrote:
>
> As far as functionality goes, it does exactly what I needed it to do;
> the output is very clear.
Good to hear.
> You might also add units (kB/MB) to the table like pg_size_pretty,
> although that would make the magnitudes harder to gauge.
On Tue, Jul 1, 2014 at 11:13 PM, Abhijit Menon-Sen wrote:
> In CF terms, did you form any opinion while porting the patch I posted
> about whether it's sensible/ready for inclusion in 9.5?
I didn't look at the code more than necessary to make the build work.
As far as functionality goes, it does
At 2014-07-01 16:39:57 +0300, ma...@juffo.org wrote:
>
> > Here's a patch to make pg_xlogdump print summary statistics instead
> > of individual records.
>
> Thanks! I had a use for this feature so I backported the (first) patch
> to PostgreSQL 9.3. It's a rush job so it's ugly and may have bugs,
On Wed, Jun 4, 2014 at 1:47 PM, Abhijit Menon-Sen wrote:
> Here's a patch to make pg_xlogdump print summary statistics instead of
> individual records.
Thanks! I had a use for this feature so I backported the (first) patch
to PostgreSQL 9.3. It's a rush job so it's ugly and may have bugs, but
it
At 2014-06-30 12:05:06 +0530, a...@2ndquadrant.com wrote:
>
> It may be that the best thing to do would be to avoid using
> optional_argument altogether, and have separate --stats and
> --stats-per-record options. Thoughts?
That's what I've done in the attached patch, except I've called the new
op
At 2014-06-30 05:19:10 +, dilip.ku...@huawei.com wrote:
>
> I have started reviewing the patch..
Thanks.
> 1. Patch applied to git head cleanly.
> 2. Compiled in Linux -- Some warnings same as mentioned by furuyao
I've attached an updated version of the patch which should fix the
warnings
On 13 June 2014 13:01, Abhijit Menon-Sen Wrote
>
> I've changed this to use %zu at Álvaro's suggestion. I'll post an
> updated patch after I've finished some (unrelated) refactoring.
I have started reviewing the patch..
1. Patch applied to git head cleanly.
2. Compiled in Linux -- Some warning
At 2014-06-10 18:04:13 +0900, furu...@pm.nttdata.co.jp wrote:
>
> The function works fine. It is a good to the learning of PostgreSQL.
Thanks for having a look.
> pg_xlogdump.c: In function ‘XLogDumpStatsRow’:
> pg_xlogdump.c:851: warning: format ‘%20llu’ expects type ‘long long unsigned
> int’,
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Abhijit
> Menon-Sen
> Sent: Wednesday, June 04, 2014 7:47 PM
> To: pgsql-hackers@postgresql.org
> Subject: [HACKERS] pg_xlogdump --stats
>
&
Hi.
Here's a patch to make pg_xlogdump print summary statistics instead of
individual records.
By default, for each rmgr it shows the number of records, the size of
rmgr-specific records, the size of full-page images, and the combined
size. With --stats=record it shows these figures for each rmgr
On 2013-02-26 15:52:01 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-02-25 18:15:48 -0500, Peter Eisentraut wrote:
> >> compat.c: In function ‘timestamptz_to_str’:
> >> compat.c:56:9: error: passing argument 1 of ‘localtime’ from incompatible
> >> pointer type [-Werror]
> >> In file
Andres Freund writes:
> On 2013-02-25 18:15:48 -0500, Peter Eisentraut wrote:
>> compat.c: In function âtimestamptz_to_strâ:
>> compat.c:56:9: error: passing argument 1 of âlocaltimeâ from
>> incompatible pointer type [-Werror]
>> In file included from compat.c:21:0:
>> /usr/include/time.
On Tue, Feb 26, 2013 at 12:02 PM, Peter Eisentraut wrote:
> On 2/26/13 11:45 AM, Tom Lane wrote:
>> But let's not break the cases that do work. One
>> of the functions of contrib/ is to serve as models/skeletons for
>> external modules. If we pull out the "useless" PGXS support then we'll
>> jus
On 26 February 2013 17:02, Peter Eisentraut wrote:
> Well, this is exactly the problem. Because of this skeleton idea, most
> external extension modules do not build unless you set USE_PGXS=1 before
> building, because they think that they live in contrib by default, which
> is completely bizarre
On 2/26/13 11:45 AM, Tom Lane wrote:
> But let's not break the cases that do work. One
> of the functions of contrib/ is to serve as models/skeletons for
> external modules. If we pull out the "useless" PGXS support then we'll
> just be making it that much harder to copy a contrib module and star
Andres Freund writes:
> Wait what? So I need to make install before I can compile extensions?
> That doesn't seem to be something realistic.
You know, any extension that's not in our source tree out there is
maintained in a way to target all supported versions of PostgreSQL from
the same sources.
Andres Freund writes:
> Well, it is broken for xlogdump because it needs a sourcetree arround.
> All I personally really want to do is to replace the usual stanza for
> pg_xlogdump with something like:
> ifdef USE_PGXS
> $(error Building pg_xlogdump with PGXS is not supported)
> else
> ...
Seem
On 2013-02-26 11:33:48 -0500, Tom Lane wrote:
> [ Sigh... ] Why this eagerness to fix what isn't broken?
Well, it is broken for xlogdump because it needs a sourcetree arround.
All I personally really want to do is to replace the usual stanza for
pg_xlogdump with something like:
ifdef USE_PGXS
$
On 2013-02-26 17:23:01 +0100, Dimitri Fontaine wrote:
> Peter Eisentraut writes:
> > I for one wonder why we even have PGXS support in contrib at all. It's
> > not documented or tested anywhere, so it might as well not exist.
Agreed. I personally think we just should build contrib/ as part of th
Tom Lane writes:
> work today --- in particular, this proposal will break building contrib
> before the main tree has been installed.
True that.
> If somebody wants to set up a buildfarm member that occasionally tests
> PGXS building of contrib/, that's fine with me. But it isn't, and never
> w
On Wed, Feb 27, 2013 at 1:25 AM, Andres Freund wrote:
> Hi,
>
> On 2013-02-27 00:34:54 +0900, Fujii Masao wrote:
>> Hi,
>>
>> When I compiled pg_xlogdump in HEAD, I got the following error.
>>
>> make: *** No rule to make target `rmgrdesc.o', needed by `pg_xlogdump'.
>> Stop.
>>
>> $ uname -a
>>
Dimitri Fontaine writes:
> Peter Eisentraut writes:
>> I for one wonder why we even have PGXS support in contrib at all. It's
>> not documented or tested anywhere, so it might as well not exist.
> I think I did about the same comment back when cooking the extension
> patch, and the answer then
Hi,
On 2013-02-27 00:34:54 +0900, Fujii Masao wrote:
> Hi,
>
> When I compiled pg_xlogdump in HEAD, I got the following error.
>
> make: *** No rule to make target `rmgrdesc.o', needed by `pg_xlogdump'. Stop.
>
> $ uname -a
> Darwin hrk.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23
> 1
Peter Eisentraut writes:
> I for one wonder why we even have PGXS support in contrib at all. It's
> not documented or tested anywhere, so it might as well not exist.
I think I did about the same comment back when cooking the extension
patch, and the answer then was all about providing PGXS usage
Hi,
When I compiled pg_xlogdump in HEAD, I got the following error.
make: *** No rule to make target `rmgrdesc.o', needed by `pg_xlogdump'. Stop.
$ uname -a
Darwin hrk.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23
16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64
Regards,
Hi,
On 2013-02-25 18:15:48 -0500, Peter Eisentraut wrote:
> compat.c: In function ‘timestamptz_to_str’:
> compat.c:56:9: error: passing argument 1 of ‘localtime’ from incompatible
> pointer type [-Werror]
> In file included from compat.c:21:0:
> /usr/include/time.h:237:19: note: expected ‘const t
compat.c: In function ‘timestamptz_to_str’:
compat.c:56:9: error: passing argument 1 of ‘localtime’ from incompatible
pointer type [-Werror]
In file included from compat.c:21:0:
/usr/include/time.h:237:19: note: expected ‘const time_t *’ but argument is of
type ‘pg_time_t *’
gcc 4.7.2
--
Se
On Sun, 2013-02-24 at 09:34 -0500, Tom Lane wrote:
> > I independently wonder whether we should remove the PGXS stub from
> > xlogdump, given it relies on a full sourcetree available?
>
> I'd just as soon keep its Makefile looking like all the others.
>
If the code doesn't actually work, it shoul
Andres Freund writes:
> On 2013-02-23 14:54:51 -0800, Jeff Janes wrote:
>> I don't know if the Makefile needs to be taught not to delete it, or taught
>> how to recreate it once deleted.
> It shouldn't be deleted,
I came to the same conclusion and committed that a few minutes before
you posted.
On 2013-02-23 14:54:51 -0800, Jeff Janes wrote:
> If I run "make clean", or "make maintainer-clean", this deletes the file
> contrib/pg_xlogdump/rmgrdesc.c. And then config/make doesn't know how to
> get it back again.
>
> I don't know if the Makefile needs to be taught not to delete it, or taug
On Fri, Feb 22, 2013 at 11:58 AM, Alvaro Herrera
wrote:
> Andres Freund wrote:
> > On 2013-02-13 12:09:37 -0300, Alvaro Herrera wrote:
> > > Here's an updated version of pg_xlogdump. This is rebased on top of
> the
> > > committed xlogreader, palloc restructuring and libpgcommon, PG_RMGR
> > > st
On 2013-02-22 16:58:37 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > On 2013-02-13 12:09:37 -0300, Alvaro Herrera wrote:
> > > Here's an updated version of pg_xlogdump. This is rebased on top of the
> > > committed xlogreader, palloc restructuring and libpgcommon, PG_RMGR
> > > stuff, an
Andres Freund wrote:
> On 2013-02-13 12:09:37 -0300, Alvaro Herrera wrote:
> > Here's an updated version of pg_xlogdump. This is rebased on top of the
> > committed xlogreader, palloc restructuring and libpgcommon, PG_RMGR
> > stuff, and is basically a revamped version of what Andres submitted in
On 2013-02-13 12:09:37 -0300, Alvaro Herrera wrote:
> Here's an updated version of pg_xlogdump. This is rebased on top of the
> committed xlogreader, palloc restructuring and libpgcommon, PG_RMGR
> stuff, and is basically a revamped version of what Andres submitted in
> http://www.postgresql.org/m
Here's an updated version of pg_xlogdump. This is rebased on top of the
committed xlogreader, palloc restructuring and libpgcommon, PG_RMGR
stuff, and is basically a revamped version of what Andres submitted in
http://www.postgresql.org/message-id/1357672187-7693-5-git-send-email-and...@2ndquadran
95 matches
Mail list logo
