Prev: Stefan's bug (was: max_standby_delay considered harmful)
Next: How to know killed by pg_terminate_backend
From: Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= on 14 May 2010 01:42
On Thu, 2010-05-13 at 17:19 +0200, Magnus Hagander wrote:
> I say remove it. On all accounts.
>
> There's a fork of postgres for EDB AS, shouldn't there be a fork of
> pg_upgrade the same way, if it requires special code? The code in
> community postgresql certainly shouldn't have any EDB AS code in it.

Agreed.
--
Devrim GÜNDÜZ
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
PostgreSQL RPM Repository: http://yum.pgrpms.org
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
From: Magnus Hagander on 14 May 2010 02:46
On Fri, May 14, 2010 at 5:34 AM, Bruce Momjian <bruce(a)momjian.us> wrote:
> Takahiro Itagaki wrote:
>>
>> Bruce Momjian <bruce(a)momjian.us> wrote:
>>
>> > > >> ==== 2. extern PGDLLIMPORT ====
>> > > >> pg_upgrade has own definitions of
>> > > >> extern PGDLLIMPORT Oid binary_upgrade_next_xxx
>> > >
>> > > > The issue here is that you use PGDLLIMPORT where you are importing the
>> > > > variable, not where it is defined.  For example, look at
>> > > > 'seq_page_cost'.  You can see PGDLLIMPORT used where it is imported with
>> > > > 'extern', but not where is it defined.
>> > >
>> > > Right.  Also we are intentionally not exposing those variables in any
>> > > backend .h file, because they are not meant for general use.  So the
>> > > "extern PGDLLIMPORT" isn't going to be in the main backend and has to
>> > > be in pg_upgrade.  This was discussed awhile ago when we put in those
>> > > variables, I believe.
>> >
>> > Yes, this was discussed.
>>
>> I wonder some compilers or linkers might hide unexported global variables
>> from postgres.lib as if they are declared with 'static' specifiers.
>> I'm especially worried about Windows and MSVC. So, if Windows testers
>> can see it works, there was nothing to worry about.
>
> Yes, none of the variables pg_upgrade is referencing are 'static', and
> Magnus tested MSVC and checked MinGW compiles.

Just to be clear, I only verified that it *built*, didn't have time to
check if it actually *worked*.


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

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Heikki Linnakangas on 15 May 2010 03:20
Tom Lane wrote:
> Magnus Hagander <magnus(a)hagander.net> writes:
>> On Thu, May 13, 2010 at 5:06 PM, Bruce Momjian <bruce(a)momjian.us> wrote:
>>> I have added SGML comments to comment out the text that mentions EDB
>>> Advanced Server. Is that enough? Should I remove the text from the
>>> SGML? Should I move it to the bottom of the SGML? Should I remove the
>>> EnterpriseDB Advanced Server checks from the C code too? I don't
>>> remember having to deal with anything like this before, so I am unclear
>>> how to proceed.
>
>> I say remove it. On all accounts.
>
>> There's a fork of postgres for EDB AS, shouldn't there be a fork of
>> pg_upgrade the same way, if it requires special code? The code in
>> community postgresql certainly shouldn't have any EDB AS code in it.
>
> Indeed. Given the (presumably large) delta between EDB's code and ours,
> having to have some delta in pg_upgrade isn't going to make much
> difference for them. I think the community code and docs should
> completely omit any mention of that.

Speaking as the person who has been doing the EDB AS merges recently, I
agree. It was helpful to have that stuff there when it was in pgfoundry,
but now that it's part of the main repository, it just gets in the way.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  | 
Pages: 1 2 3 4
Prev: Stefan's bug (was: max_standby_delay considered harmful)
Next: How to know killed by pg_terminate_backend