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
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
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
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
>
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
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,
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
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
87 matches
Mail list logo
