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/
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 |