Re: walprotocol.h vs frontends

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: walprotocol.h vs frontends
Date: 2011-08-15 16:50:43
Message-ID: CABUevExKMLnfwX8ou0ad8EVJptXGKr_wZW6m=k6OLE31xd7Lmg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 15, 2011 at 18:40, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> On Mon, Aug 15, 2011 at 16:53, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Don't think you should expose fsec_t, nor most of those macros.  The
>>> foo_per_bar values are just namespace clutter.
>
>> Hmm, ok. I just went for what seemed like a reasonable subset. I do
>> also need the SECS_PER_DAY and those constants in order to be able to
>> convert the timestamp value.
>
> Uh ... "convert"?  That seems to require a whole lot more knowledge
> about timestamps than what is exposed by the proposed new header.
> I thought you were just hoping to compile a struct containing a
> TimestampTz field, not actually do anything with that field.

Um, bad choice of words. I don't need to convert, really, but I do
need to stick the current timestamp into a TimestampTz field.

>>> I don't like the idea of exposing those to frontends, either.  What do
>>> you actually *need* out of that, and why?
>
>> PrevLogSeg - which also brings in XLogSegsPerFile.
>> XLogFileName
>> XLogFileSize - which brings in XLogSegsPerFile and XLogSegSize
>
>> PrevLogSeg should be self explaining, as should xlogfilename.
>
>> XLogFileSize is required by XLByteAdvance() which is already in
>> xlogdefs.h - so xlogdefs.h actually has a hidden dependency on
>> xlog_internal.h here today.
>
> Yeah, and the question remains why is "frontend" code using any of that?
>
> I'm inclined to think that there is zero chance of this code being
> "frontend" in the sense of being at any real arm's length from backend
> implementation details, and so you should just forget these header
> maneuvers and do what pg_resetxlog.c does, ie
>
> /*
>  * We have to use postgres.h not postgres_fe.h here, because there's so much
>  * backend-only stuff in the XLOG include files we need.  But we need a
>  * frontend-ish environment otherwise.  Hence this ugly hack.
>  */
> #define FRONTEND 1
>
> #include "postgres.h"

That does seem to work, yes. I completely forgot about that hack. And
I agree that's probably th eway to do it...

Now I just need to figure out how to get to GetCurrentTimestamp() to
be accessible - or just copy it over under a different name...

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2011-08-15 17:06:29 Re: our buffer replacement strategy is kind of lame
Previous Message Tom Lane 2011-08-15 16:40:58 Re: walprotocol.h vs frontends