pgsql: Create libpgcommon, and move pg_malloc et al to it

On Tue, February 12, 2013 15:55, Alvaro Herrera wrote:

Create libpgcommon, and move pg_malloc et al to it

If at all possible, it would be handy (for testers) if initdb-forcing commits are flagged as such.

(it's not a big deal but I often have large databases in a dev/test-setup that take a while to
re-create...)

Thanks,

Erik Rijkers

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

Erik Rijkers wrote:

On Tue, February 12, 2013 15:55, Alvaro Herrera wrote:

Create libpgcommon, and move pg_malloc et al to it

If at all possible, it would be handy (for testers) if initdb-forcing commits are flagged as such.

Hmm? I don't think this patch requires an initdb at all. It doesn't
touch the database contents at all, does it?

Patches that force an initdb are flagged as such by bumping
CATALOG_VERSION_NO.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

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

On Tue, February 12, 2013 17:01, Alvaro Herrera wrote:

Erik Rijkers wrote:

On Tue, February 12, 2013 15:55, Alvaro Herrera wrote:

Create libpgcommon, and move pg_malloc et al to it

If at all possible, it would be handy (for testers) if initdb-forcing commits are flagged as
such.

Hmm? I don't think this patch requires an initdb at all. It doesn't
touch the database contents at all, does it?

Patches that force an initdb are flagged as such by bumping
CATALOG_VERSION_NO.

I got this:

The database cluster was initialized with PG_CONTROL_VERSION 934, but the server was compiled with
PG_CONTROL_VERSION 935
HINT: It looks like you need to initdb

But I immediately admit that I could well be mistaken; it may have been an older commit that
triggered this complaint of 'needing initdb' on this particular machine. My apologies.

Thanks,

Erik Rijkers

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

Erik Rijkers wrote:

On Tue, February 12, 2013 17:01, Alvaro Herrera wrote:

Erik Rijkers wrote:

On Tue, February 12, 2013 15:55, Alvaro Herrera wrote:

Create libpgcommon, and move pg_malloc et al to it

If at all possible, it would be handy (for testers) if initdb-forcing commits are flagged as
such.

Hmm? I don't think this patch requires an initdb at all. It doesn't
touch the database contents at all, does it?

Patches that force an initdb are flagged as such by bumping
CATALOG_VERSION_NO.

I got this:

The database cluster was initialized with PG_CONTROL_VERSION 934, but the server was compiled with
PG_CONTROL_VERSION 935
HINT: It looks like you need to initdb

But I immediately admit that I could well be mistaken; it may have been an older commit that
triggered this complaint of 'needing initdb' on this particular machine. My apologies.

Ah, yes, that's 62401db45c.

I'm not sure are you suggesting, though. Are you saying that the commit
message should explicitely state "this patch requires initdb" or some
such?

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

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

On Tue, February 12, 2013 17:19, Alvaro Herrera wrote:

Erik Rijkers wrote:

On Tue, February 12, 2013 17:01, Alvaro Herrera wrote:

Erik Rijkers wrote:

On Tue, February 12, 2013 15:55, Alvaro Herrera wrote:

Create libpgcommon, and move pg_malloc et al to it

If at all possible, it would be handy (for testers) if initdb-forcing commits are flagged as
such.

Hmm? I don't think this patch requires an initdb at all. It doesn't
touch the database contents at all, does it?

Patches that force an initdb are flagged as such by bumping
CATALOG_VERSION_NO.

I got this:

The database cluster was initialized with PG_CONTROL_VERSION 934, but the server was compiled
with
PG_CONTROL_VERSION 935
HINT: It looks like you need to initdb

But I immediately admit that I could well be mistaken; it may have been an older commit that
triggered this complaint of 'needing initdb' on this particular machine. My apologies.

Ah, yes, that's 62401db45c.

I'm not sure are you suggesting, though. Are you saying that the commit
message should explicitely state "this patch requires initdb" or some
such?

I was under the impression that this was habitually done in commit messages, but looking back
through the commitlog messages it's not all that clear although sometimes catversion bumps are
explicitly mentioned.

Let's just say that an explicit mention/warning is useful for me, so probably for some others too.
At the same time I'll start monitoring PG_CONTROL_VERSION and CATALOG_VERSION a bit more closely.
That's easy enough too of course...

Thanks,

Erik Rijkers

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

"Erik Rijkers" <er@xs4all.nl> writes:

On Tue, February 12, 2013 17:19, Alvaro Herrera wrote:

I'm not sure are you suggesting, though. Are you saying that the commit
message should explicitely state "this patch requires initdb" or some
such?

I was under the impression that this was habitually done in commit messages, but looking back
through the commitlog messages it's not all that clear although sometimes catversion bumps are
explicitly mentioned.

I think usually if the topic is mentioned in a commit message, it's to
explain why we are (or are not) forcing an initdb. By and large, if a
patch touches catversion.h, that ought to be sufficient warning ...

regards, tom lane

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

On 12.02.2013 16:55, Alvaro Herrera wrote:

Create libpgcommon, and move pg_malloc et al to it

libpgcommon is a new static library to allow sharing code among the
various frontend programs and backend; this lets us eliminate duplicate
implementations of common routines. We avoid libpgport, because that's
intended as a place for porting issues; per discussion, it seems better
to keep them separate.

The first use case, and the only implemented by this patch, is pg_malloc
and friends, which many frontend programs were already using.

At the same time, we can use this to provide palloc emulation functions
for the frontend; this way, some palloc-using files in the backend can
also be used by the frontend cleanly. To do this, we change palloc() in
the backend to be a function instead of a macro on top of
MemoryContextAlloc(). This was previously believed to cause loss of
performance, but this implementation has been tweaked by Tom and Andres
so that on modern compilers it provides a slight improvement over the
previous one.

The new header file, fe_memutils.h, is not installed anywhere by "make
install". That makes #include "postgres_fe.h" to fail in any program
compiled out-of-tree, with pgxs.

Where should it be installed? postgres_fe.h and port.h are installed to
include/internal, so that would seem logical. I wonder what the
"internal" actually means there, though. If we want to encourage
frontend programs to use these, "internal" doesn't sound right.

- Heikki

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