> int counts[1]; /* variable-length array of counts, xinfo flags define
> length of array and meaning of counts */
Damn, that's much cleaner than what I did. I don't know why
I stuck with the idea that it had to be:
int
array
int
array
...
instead of:
int
int
...
array
array
...
which mak
this is a second version: now using
intcounts[1]; /* variable-length array of counts */
in xl_xact_commit to keep track of number of
different arrays at the end of the struct.
Waiting for feedbacks...
Leonardo
commitlog_lessbytes00.patch
Description: Binary data
--
Se
On Wed, May 18, 2011 at 12:40 AM, Max Bourinov wrote:
> Hi Highly Respected Hackers!
>
> I have a task to pass arrays, records and in some cases array of
> records as a parameter to the stored procedures in PostgreSQL. I will
> use JDBC to work with PostgreSQL 9.0 At first I would like to learn
>
Darren Duncan writes:
> Would now be a good time to start deprecating the contrib/ directory as a
> way to distribute Pg add-ons, with favor given to PGXN and the like instead?
The first important fact is that contrib/ code is maintained by the
PostgreSQL-core product team, and I guess they prefe
Greg Smith wrote:
Attached is a second patch to move a number of extensions from
contrib/ to src/test/. Extensions there are built by the default
built target, making installation of the postgresql-XX-contrib package
unnecessary for them to be available.
That was supposed to be contrib/ to s
> By the time the startup process
> releases the AccessExclusiveLock acquired by the proposed
> UNLOGGED -> normal conversion process, that relfilenode
> needs to be either fully copied or unlinked all over again.
> (Alternately, find some other way to make sure queries don't
> read the half-c
On 05/18/2011 10:30 AM, Dimitri Fontaine wrote:
> Darren Duncan writes:
>> Would now be a good time to start deprecating the contrib/ directory as a
>> way to distribute Pg add-ons, with favor given to PGXN and the like instead?
>
> The first important fact is that contrib/ code is maintained by
I broke the Win32 build members by using access(X_OK) in pg_upgrade. I
have a fix for this but looking at pg_upgrade's exec.c, I see for
Win32:
if ((buf.st_mode & S_IXUSR) == 0)
I am confused why Windows supports S_IXUSR but not X_OK.
--
Bruce Momjian http://momjian.us
On Wed, May 18, 2011 at 04:02:59PM +0100, Leonardo Francalanci wrote:
> > By the time the startup process
> > releases the AccessExclusiveLock acquired by the proposed
> > UNLOGGED -> normal conversion process, that relfilenode
> > needs to be either fully copied or unlinked all over again.
> >
On Wed, May 18, 2011 at 11:41, Bruce Momjian wrote:
> I broke the Win32 build members by using access(X_OK) in pg_upgrade. I
> have a fix for this but looking at pg_upgrade's exec.c, I see for
> Win32:
>
> if ((buf.st_mode & S_IXUSR) == 0)
>
> I am confused why Windows supports S_IXUSR
Bruce Momjian wrote:
> I broke the Win32 build members by using access(X_OK) in pg_upgrade. I
> have a fix for this but looking at pg_upgrade's exec.c, I see for
> Win32:
>
> if ((buf.st_mode & S_IXUSR) == 0)
>
> I am confused why Windows supports S_IXUSR but not X_OK.
I have applied
On May 18, 2011, at 10:30 AM, Dimitri Fontaine wrote:
> The other problem is that the facility we need to provide the most is
> binary distributions (think apt-get). Lots of site won't ever compile
> stuff on their production servers. So while PGXN is a good tool, it's
> not a universal answer.
Magnus Hagander wrote:
> On Wed, May 18, 2011 at 11:41, Bruce Momjian wrote:
> > I broke the Win32 build members by using access(X_OK) in pg_upgrade. ?I
> > have a fix for this but looking at pg_upgrade's exec.c, I see for
> > Win32:
> >
> > ? ? ? ? ? ?if ((buf.st_mode & S_IXUSR) == 0)
> >
> > I a
I reviewed the process for configuring replication, and found that we
don't have an example for allowing replication access in pg_hba.conf.
Before we release 9.1, I think we should add this example to make it
more obvious this is a necessary part of replication configuration.
At the risk of starti
On Wed, May 18, 2011 at 12:16, Bruce Momjian wrote:
> Magnus Hagander wrote:
>> On Wed, May 18, 2011 at 11:41, Bruce Momjian wrote:
>> > I broke the Win32 build members by using access(X_OK) in pg_upgrade. ?I
>> > have a fix for this but looking at pg_upgrade's exec.c, I see for
>> > Win32:
>> >
On Wed, May 18, 2011 at 12:15 PM, David E. Wheeler wrote:
> On May 18, 2011, at 10:30 AM, Dimitri Fontaine wrote:
>
>> The other problem is that the facility we need to provide the most is
>> binary distributions (think apt-get). Lots of site won't ever compile
>> stuff on their production server
On May 18, 2011, at 12:24 PM, Christopher Browne wrote:
> It'll be time to drop the contrib material from the "core" when that
> shift leads to a 1 line configuration change somewhere that leads to
> packages for Debian/Fedora/Ports drawing their code from the new spot.
>
> I'd fully expect that
And this patch is aligned in a more pleasing way.
-selena
--
http://chesnok.com
pg_hba_bikeshed2.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, May 18, 2011 at 12:17 PM, Selena Deckelmann wrote:
> At the risk of starting an epic bikeshedding thread, I've attached a
> small patch that includes an example for both ipv4 and ipv6 localhost
> configuration.
My "bikeshedding" would be to ensure that the sample pg_hba.conf
includes some
"David E. Wheeler" writes:
> On May 18, 2011, at 10:30 AM, Dimitri Fontaine wrote:
>> The other problem is that the facility we need to provide the most is
>> binary distributions (think apt-get). Lots of site won't ever compile
>> stuff on their production servers. So while PGXN is a good tool,
On Wed, May 18, 2011 at 9:35 AM, Christopher Browne wrote:
> On Wed, May 18, 2011 at 12:17 PM, Selena Deckelmann
> wrote:
>> At the risk of starting an epic bikeshedding thread, I've attached a
>> small patch that includes an example for both ipv4 and ipv6 localhost
>> configuration.
>
> My "bik
On May 18, 2011, at 1:23 PM, Tom Lane wrote:
>> I think building tools so that PGXN distributions are automatically
>> harvested and turned into StackBuilder/RPM/.deb binaries would be the place
>> to start on that.
>
> Hmmm ... I think the real point of those policies about "no source
> builds
"David E. Wheeler" writes:
> I think building tools so that PGXN distributions are automatically
> harvested and turned into StackBuilder/RPM/.deb binaries would be the place
> to start on that.
Well, I'm not sure I buy into that idea, I need to think about it some
more. The thing with debian fo
On May 18, 2011, at 1:47 PM, Dimitri Fontaine wrote:
> Well, I'm not sure I buy into that idea, I need to think about it some
> more. The thing with debian for example is that the package building
> needs to be all automatic, and determistic — you're not granted to have
> the next version build a
On Wed, May 18, 2011 at 13:47, Dimitri Fontaine wrote:
> "David E. Wheeler" writes:
>> I think building tools so that PGXN distributions are automatically
>> harvested and turned into StackBuilder/RPM/.deb binaries would be the place
>> to start on that.
>
> Well, I'm not sure I buy into that ide
On May 18, 2011, at 2:47 PM, Magnus Hagander wrote:
> I don't see why it couldn't, at least for a fair number of
> extensions.. It does require the ability to differentiate between
> patch releases and feature releases, though, which I believe is
> currently missing in pgxn (correct me if i'm wron
On Wed, May 18, 2011 at 10:25, Greg Smith wrote:
> Attached is a second patch to move a number of extensions from contrib/ to
> src/test/. Extensions there are built by the default built target, making
> installation of the postgresql-XX-contrib package unnecessary for them to be
> available.
+1
On Wed, May 18, 2011 at 14:49, David E. Wheeler wrote:
> On May 18, 2011, at 2:47 PM, Magnus Hagander wrote:
>
>> I don't see why it couldn't, at least for a fair number of
>> extensions.. It does require the ability to differentiate between
>> patch releases and feature releases, though, which I
On May 18, 2011, at 2:58 PM, Magnus Hagander wrote:
> Does it support having both v 1.3.1 and v1.4.0 and v2.0.2 at the same
> time? I somehow got the idea that old versions were removed when I
> uploaded a new one, but I happy to be wrong :-)
The distribution has only one version, of course, but
On Wed, May 18, 2011 at 15:05, David E. Wheeler wrote:
> On May 18, 2011, at 2:58 PM, Magnus Hagander wrote:
>
>> Does it support having both v 1.3.1 and v1.4.0 and v2.0.2 at the same
>> time? I somehow got the idea that old versions were removed when I
>> uploaded a new one, but I happy to be wro
On May 18, 2011, at 3:08 PM, Magnus Hagander wrote:
>> The distribution has only one version, of course, but perl extensions in
>> 9.1, you can include multiple versions of an extension in one distribution.
>
> Won't that break if different (major) versions have different dependencies?
I don't
On Wed, May 18, 2011 at 15:17, David E. Wheeler wrote:
> On May 18, 2011, at 3:08 PM, Magnus Hagander wrote:
>
>>> The distribution has only one version, of course, but perl extensions in
>>> 9.1, you can include multiple versions of an extension in one distribution.
>>
>> Won't that break if dif
On May 18, 2011, at 3:22 PM, Magnus Hagander wrote:
> If I include both version 1 and version 2 of an extension in one. And
> version 2 has more dependencies than version 1 (or the other way
> around). Then those dependencies will be required for version 1 as
> well...
Yes. But if they're that de
"David E. Wheeler" writes:
> Yes. But if they're that decoupled, then they ought to be in separate
> distributions.
I somehow fail to picture how you map distributions with debian
packages. The simple way is to have a distribution be a single source
package that will produce as many binary packa
On Wed, May 18, 2011 at 2:57 PM, Magnus Hagander wrote:
> On Wed, May 18, 2011 at 10:25, Greg Smith wrote:
>> Some of my personal discussions of this topic have suggested that some other
>> popular extensions like pgcrypto and hstore get converted too. I think
>> those all fail test (3), and I'm
On May 18, 2011, at 3:27 PM, Dimitri Fontaine wrote:
> "David E. Wheeler" writes:
>> Yes. But if they're that decoupled, then they ought to be in separate
>> distributions.
>
> I somehow fail to picture how you map distributions with debian
> packages. The simple way is to have a distribution b
On Wed, May 18, 2011 at 15:29, Marko Kreen wrote:
> On Wed, May 18, 2011 at 2:57 PM, Magnus Hagander wrote:
>> On Wed, May 18, 2011 at 10:25, Greg Smith wrote:
>>> Some of my personal discussions of this topic have suggested that some other
>>> popular extensions like pgcrypto and hstore get con
Greg Smith wrote:
Any packager who grabs the shared/postgresql/extension directory in
9.1, which I expect to be all of them, shouldn't need any changes to
pick up this adjustment. For example, pgstattuple installs these files:
share/postgresql/extension/pgstattuple--1.0.sql
share/postgresql/e
On Wed, May 18, 2011 at 1:02 AM, Jaime Casanova wrote:
> So we the lock will be released at end of the session or when the
> UNLOCK DATABASE command is invoked, right?
> A question: why will we beign so rude by killing other sessions
> instead of avoid new connections and wait until the current se
The attached, applied patch improves pg_upgrade error reporting if the
bin or data directories do not exist or are not directories. Previously
the error message was not clear.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It
Excerpts from Christopher Browne's message of mié may 18 18:33:14 -0400 2011:
> On Wed, May 18, 2011 at 1:02 AM, Jaime Casanova wrote:
> > So we the lock will be released at end of the session or when the
> > UNLOCK DATABASE command is invoked, right?
> > A question: why will we beign so rude by k
Two things that could be changed from this example to make it more useful:
-Document at least a little bit more how this is different from the
"all/all" rule. I can imagine users wondering "do I use this instead of
the other one? In addition? Is it redundant if I have 'all' in there?
A lit
Excerpts from Greg Smith's message of mié may 18 23:07:13 -0400 2011:
> Two things that could be changed from this example to make it more useful:
> -The default database is based on your user name, which is postgres in
> most packaged builds but not if you compile your own. I don't know
> whet
On May 18, 2011, at 6:11 PM, Alvaro Herrera wrote:
> Excerpts from Christopher Browne's message of mié may 18 18:33:14 -0400 2011:
>> On Wed, May 18, 2011 at 1:02 AM, Jaime Casanova
>> wrote:
>>> So we the lock will be released at end of the session or when the
>>> UNLOCK DATABASE command is in
Excerpts from David Christensen's message of jue may 19 00:55:36 -0400 2011:
> How would this differ from just UPDATE pg_database SET datallowconn = FALSE
> for the databases in question?
Several ways actually. First, it is automatically gone when the locking
session disconnects (so it clean up
On Thursday, May 19, 2011 06:55:36 AM David Christensen wrote:
> On May 18, 2011, at 6:11 PM, Alvaro Herrera wrote:
> > Excerpts from Christopher Browne's message of mié may 18 18:33:14 -0400
2011:
> >> On Wed, May 18, 2011 at 1:02 AM, Jaime Casanova
wrote:
> >>> So we the lock will be released
Hi,
I am trying to build Postgresql 8.3.15 on Win32 with VS2005.
I was able to build all the projects except uuid-ossp.
I am getting the following error
fatal error LNK1104: cannot open file
'c:\prog\pgsql\depend\ossp-uuid\lib\uuid.lib'
I tried to get the code for uuid-1.6.2 projec
47 matches
Mail list logo
