Bruce Momjian writes:
> Tom Lane wrote:
>> I would have gone the other way on that one, if possible. Seems like
>> xlog.h ought to be the lower-level file.
> Agreed. Let me work on that.
Uh, I just did it. Painful. It would have been a lot easier before
the pgrminclude run, because that bake
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> You seem to have entirely missed the point of Alvaro's remark, which is
> >> that you've got xlog.h including walsender.h (still) as well as
> >> walsender.h including xlog.h. That's broken.
>
> > Oh, OK, done. xlog.h removed from
Hi hackers,
I'm pleased to announce the latest release of xlogdump.
xlogdump is a tool for extracting data from WAL segment files.
Here is xlogdump README:
https://github.com/snaga/xlogdump/blob/master/xlogdump/README.xlogdump
xlogdump was originally developed by Tom Lane and Diogo Biazus around
Bruce Momjian writes:
> Tom Lane wrote:
>> You seem to have entirely missed the point of Alvaro's remark, which is
>> that you've got xlog.h including walsender.h (still) as well as
>> walsender.h including xlog.h. That's broken.
> Oh, OK, done. xlog.h removed from walsender.h and tested.
I wo
Tom Lane wrote:
> Bruce Momjian writes:
> > Alvaro Herrera wrote:
> >> Hmm, so you included walsender.h into xlog.h? That seems a bit funny
> >> considering that walsender.h already includes xlog.h. It seems the
> >> reason for this is only the AllowCascadeReplication() definition. Maybe
> >> t
Bruce Momjian writes:
> Alvaro Herrera wrote:
>> Hmm, so you included walsender.h into xlog.h? That seems a bit funny
>> considering that walsender.h already includes xlog.h. It seems the
>> reason for this is only the AllowCascadeReplication() definition. Maybe
>> that should go elsewhere inst
Alvaro Herrera wrote:
> Excerpts from Bruce Momjian's message of vie sep 02 12:20:50 -0300 2011:
>
> > Wow, that is interesting. So the problem is the inclusion of
> > replication/walsender.h in xlog.h. Hard to see how that could cause the
> > cube regression tests to fail, but of course, it is.
Peter Eisentraut writes:
> On fre, 2011-09-02 at 19:49 -0400, Tom Lane wrote:
>> The only one that's problematic is pg_regress.so; contrib modules are
>> already installed in $libdir. I still think that installing
>> pg_regress.so in $libdir may be the most reasonable solution, assuming
>> that t
FYI, here are all the C files with over 6k lines:
- 45133 ./interfaces/ecpg/preproc/preproc.c
- 33651 ./backend/parser/gram.c
- 17551 ./backend/parser/scan.c
14209 ./bin/pg_dump/pg_dump.c
10590 ./backend/access/transam/xlog.c
9764 ./backend/commands/tablecmds.c
8681 ./backend/util
On 09/03/2011 04:49 PM, Dimitri Fontaine wrote:
Andrew Dunstan writes:
Oh, I meant just having it create separate custom format files for each
database. As shell scripts all over the world have been doing for years,
but it would be nice if it was simply built in.
I guess it could be done, al
Magnus Hagander writes:
> Attached patch implements a "low watermark wal location" in the
> walsender shmem array. Setting this value in a walsender prevents
> transaction log removal prior to this point - similar to how
> wal_keep_segments work, except with an absolute number rather than
Cool.
Andrew Dunstan writes:
>> Oh, I meant just having it create separate custom format files for each
>> database. As shell scripts all over the world have been doing for years,
>> but it would be nice if it was simply built in.
>
> I guess it could be done, although I'm not going to do it :-) I'm mor
On Fri, Sep 02, 2011 at 04:27:46PM -0500, Ross J. Reedstrom wrote:
> On Fri, Sep 02, 2011 at 02:05:45PM -0500, k...@rice.edu wrote:
> > On Fri, Sep 02, 2011 at 09:54:07PM +0300, Peter Eisentraut wrote:
> > > On ons, 2011-08-31 at 13:12 -0500, Ross J. Reedstrom wrote:
> > > > Hmm, this thread seems
Peter Eisentraut wrote:
> But if you think about it, it doesn't really test pg_upgrade, it tests
> pg_dump. So the test could just as well be moved to src/bin/pg_dump/
> and be labeled "pg_dump smoke test" or whatever. (Minor detail: The bug
> fix above involved the --binary-upgrade flag, so it i
On fre, 2011-09-02 at 19:49 -0400, Tom Lane wrote:
> The only one that's problematic is pg_regress.so; contrib modules are
> already installed in $libdir. I still think that installing
> pg_regress.so in $libdir may be the most reasonable solution, assuming
> that the delta involved isn't too grea
15 matches
Mail list logo
