On sön, 2012-06-24 at 16:05 -0400, Robert Haas wrote:
diff --git a/src/backend/catalog/genbki.pl b/src/backend/catalog/genbki.pl
index ebc4825..7d66da9 100644
--- a/src/backend/catalog/genbki.pl
+++ b/src/backend/catalog/genbki.pl
@@ -19,6 +19,8 @@
use strict;
use warnings;
Hi Pavel,
On Mon, 2012-06-25 at 08:26 +0300, Pavel Golub wrote:
Hello, Pgsql-bugs.
According to the Moving tablespaces thread started by Bruce
http://archives.postgresql.org/pgsql-docs/2011-12/msg3.php
pg_tablespace.spclocation column is removed in the 9.2beta. However
this breaks
Hello, Guillaume.
You wrote:
GL Hi Pavel,
GL On Mon, 2012-06-25 at 08:26 +0300, Pavel Golub wrote:
Hello, Pgsql-bugs.
According to the Moving tablespaces thread started by Bruce
http://archives.postgresql.org/pgsql-docs/2011-12/msg3.php
pg_tablespace.spclocation column is removed in
On 05/31/2012 11:52 AM, Jeff Davis wrote:
On Wed, 2012-05-16 at 23:14 +0200, Miroslav Šimulčík wrote:
Hi all,
as a part of my master's thesis I have created temporal support patch
for PostgreSQL. It enables the creation of special temporal tables
with entries versioning. Modifying operations
I've tried to cross-compile PostgreSQL from Linux to Windows, following
the ideas of Andrew Dunstan [0]. This works quite well. I see two
compiler warnings altogether, which might be worth getting rid of:
#1
mingwcompat.c:60:1: warning: ‘RegisterWaitForSingleObject’ redeclared without
On Mon, Jun 25, 2012 at 11:42 AM, Peter Eisentraut pete...@gmx.net wrote:
I've tried to cross-compile PostgreSQL from Linux to Windows, following
the ideas of Andrew Dunstan [0]. This works quite well. I see two
compiler warnings altogether, which might be worth getting rid of:
#1
Shigeru:
Thank you very much for your review. Comments are inline below, and a
new patch is attached.
On Fri, Jun 22, 2012 at 10:06:53AM +0900, Shigeru HANADA wrote:
(2012/05/01 0:30), Ryan Kelly wrote:
On Mon, Apr 30, 2012 at 09:02:33AM -0400, Alvaro Herrera wrote:
Well, do *you* want it?
On HEAD at the moment, `make check-world` is failing on a 32-bit Linux
build:
+ pg_upgrade -d
/home/kevin/pg/master/contrib/pg_upgrade/tmp_check/data.old -D
/home/kevin/pg/master/contrib/pg_upgrade/tmp_check/data -b
On Mon, Jun 25, 2012 at 4:04 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jun 22, 2012 at 12:38 PM, Euler Taveira eu...@timbira.com wrote:
On 20-06-2012 17:40, Marko Kreen wrote:
On Wed, Jun 20, 2012 at 10:05 PM, Florian Pflug f...@phlo.org wrote:
I'm starting to think that relying on
Fujita-san,
The revised patch is almost good for me.
Only point I noticed is the check for redundant or duplicated options
I pointed out on the previous post.
So, if you agree with the attached patch, I'd like to hand over this
patch for committers.
All I changed is:
---
On Jun25, 2012, at 04:04 , Robert Haas wrote:
If, for
example, someone can demonstrate that an awesomebsdlz compresses 10x
as fast as OpenSSL... that'd be pretty compelling.
That, actually, is demonstrably the case for at least Google's snappy.
(and LZO, but that's not an option since its
On Mon, Jun 25, 2012 at 03:12:46PM +0200, Florian Pflug wrote:
On Jun25, 2012, at 04:04 , Robert Haas wrote:
If, for
example, someone can demonstrate that an awesomebsdlz compresses 10x
as fast as OpenSSL... that'd be pretty compelling.
That, actually, is demonstrably the case for at
Peter Eisentraut pete...@gmx.net writes:
On sön, 2012-06-24 at 16:05 -0400, Robert Haas wrote:
+local $SIG{__WARN__} = sub { die $_[0] };
This seems like a band-aid.
I'd think of it as a safety net.
+1 for the concept of turning warnings into errors, but is that really
the cleanest, most
On Monday, June 25, 2012 03:08:51 AM Robert Haas wrote:
On Sun, Jun 24, 2012 at 5:11 PM, Andres Freund and...@2ndquadrant.com
wrote:
There are some interesting problems related to locking and snapshots
here. Not sure if they are resolvable:
We need to restrict SnapshotNow to represent
Pavel Golub pa...@microolap.com writes:
I'm aware of problems caused by this hard coded column. My proposal is
to convert pg_tablespace to system view may be?
It's not that easy to make a 100% backwards compatible view for a system
catalog. The main sticking point is the OID column; see recent
On Mon, Jun 25, 2012 at 3:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavel Golub pa...@microolap.com writes:
I'm aware of problems caused by this hard coded column. My proposal is
to convert pg_tablespace to system view may be?
It's not that easy to make a 100% backwards compatible view for a
On Mon, Jun 25, 2012 at 8:11 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
On HEAD at the moment, `make check-world` is failing on a 32-bit Linux
build:
+ pg_upgrade -d
/home/kevin/pg/master/contrib/pg_upgrade/tmp_check/data.old -D
Peter Geoghegan pe...@2ndquadrant.com writes:
On 22 June 2012 01:04, Tom Lane t...@sss.pgh.pa.us wrote:
This is nonsense. There are at least three buildfarm machines running
compilers that do not pretend to be gcc (at least, configure
recognizes them as not gcc) and are not MSVC either.
So
Andres Freund and...@2ndquadrant.com writes:
On Friday, June 22, 2012 02:04:02 AM Tom Lane wrote:
This is nonsense. There are at least three buildfarm machines running
compilers that do not pretend to be gcc (at least, configure
recognizes them as not gcc) and are not MSVC either.
Should
On 25 June 2012 13:11, Kevin Grittner kevin.gritt...@wicourts.gov wrote:
On HEAD at the moment, `make check-world` is failing on a 32-bit Linux
build:
+ pg_upgrade -d
/home/kevin/pg/master/contrib/pg_upgrade/tmp_check/data.old -D
/home/kevin/pg/master/contrib/pg_upgrade/tmp_check/data -b
On Jun 25, 2012, at 3:35 PM, Tom Lane wrote:
+1 for the concept of turning warnings into errors, but is that really
the cleanest, most idiomatic way to do so in Perl? Sheesh.
It’s the most backward-compatible, but the most idiomatic way to do it
lexically is:
use warnings 'FATAL';
On Mon, Jun 25, 2012 at 9:43 AM, Andres Freund and...@2ndquadrant.com wrote:
The only theoretical way I see against that problem would be to postpone
all relation unlinks untill everything that could possibly read them has
finished. Doesn't seem to alluring although it would be needed if we
On Monday, June 25, 2012 05:15:43 PM Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On Friday, June 22, 2012 02:04:02 AM Tom Lane wrote:
This is nonsense. There are at least three buildfarm machines running
compilers that do not pretend to be gcc (at least, configure
On 24-06-2012 23:04, Robert Haas wrote:
So I think we really
need someone to try this both ways and compare. Right now it seems
like we're mostly speculating on how well either approach would work,
which is not as good as having some experimental results.
Not a problem. That's what I'm
Robert Haas robertmh...@gmail.com writes:
On MacOS X, on latest sources, initdb fails:
creating directory /Users/rhaas/pgsql/src/test/regress/./tmp_check/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 32MB
creating
Excerpts from David E. Wheeler's message of lun jun 25 11:23:34 -0400 2012:
On Jun 25, 2012, at 3:35 PM, Tom Lane wrote:
+1 for the concept of turning warnings into errors, but is that really
the cleanest, most idiomatic way to do so in Perl? Sheesh.
It’s the most backward-compatible,
On Sat, Jun 23, 2012 at 6:26 PM, Peter Eisentraut pete...@gmx.net wrote:
About the new --maintenance-db options:
Why was this option not added to createuser and dropuser? In the
original discussion[0] they were mentioned, but it apparently never made
it into the code.
Oops. That was an
Andres Freund and...@2ndquadrant.com writes:
On Monday, June 25, 2012 05:15:43 PM Tom Lane wrote:
So you propose to define any compiler that strictly implements C99 as
not sensible and not one that will be able to compile Postgres?
I propose to treat any compiler which has no way to get to
On Jun 25, 2012, at 5:51 PM, Alvaro Herrera wrote:
However, that works only for the current lexical scope. If there are
warnings in the code you are calling from the current scope, the use of
`local $SIG{__WARN__}` is required.
So lets add 'FATAL' to the already existing use warnings
On Mon, Jun 25, 2012 at 11:50 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On MacOS X, on latest sources, initdb fails:
creating directory /Users/rhaas/pgsql/src/test/regress/./tmp_check/data ...
ok
creating subdirectories ... ok
selecting default
David E. Wheeler da...@justatheory.com writes:
Hrm, I think that `use warnings 'FATAL';` might only work for core warnings.
Which is annoying. I missed what was warning up-thread, but the most
foolproof way to make all warnings fatal is the originally suggested
local $SIG{__WARN__} = sub
On Mon, Jun 25, 2012 at 12:07:55PM -0400, Tom Lane wrote:
David E. Wheeler da...@justatheory.com writes:
Hrm, I think that `use warnings 'FATAL';` might only work for core
warnings. Which is annoying. I missed what was warning up-thread, but the
most foolproof way to make all warnings
Robert Haas rh...@postgresql.org writes:
Remove sanity test in XRecOffIsValid.
Commit 061e7efb1b4c5b8a5d02122b7780531b8d5bf23d changed the rules
for splitting xlog records across pages, but neglected to update this
test. It's possible that there's some better action here than just
removing
Robert Haas robertmh...@gmail.com wrote:
I bet for a lot of replication systems, the answer is do a full
resync. In other words, we either forbid the operation outright
when the table is enabled for logical replication, or else we emit
an LCR that says, in effect, transaction 12345 monkeyed
On Mon, Jun 25, 2012 at 12:42 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Perhaps the first question is: Is there enough in common between
logical replication (and all the topologies that might be created
with that) and the proposal on the table (which seems to be based
around one
On Mon, Jun 25, 2012 at 12:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas rh...@postgresql.org writes:
Remove sanity test in XRecOffIsValid.
Commit 061e7efb1b4c5b8a5d02122b7780531b8d5bf23d changed the rules
for splitting xlog records across pages, but neglected to update this
test.
On Mon, Jun 25, 2012 at 8:11 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
On HEAD at the moment, `make check-world` is failing on a 32-bit Linux
build:
This appears to be because of the following hunk from commit
dfda6ebaec6763090fb78b458a979b558c50b39b:
@@ -558,10 +536,10 @@
On Monday, June 25, 2012 05:57:51 PM Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On Monday, June 25, 2012 05:15:43 PM Tom Lane wrote:
So you propose to define any compiler that strictly implements C99 as
not sensible and not one that will be able to compile Postgres?
I
Wasn't this more of an issue in de-coupling compression from encryption ?
On 25 Jun 2012, at 16:36, Euler Taveira wrote:
On 24-06-2012 23:04, Robert Haas wrote:
So I think we really
need someone to try this both ways and compare. Right now it seems
like we're mostly speculating on how
On Mon, Jun 25, 2012 at 1:24 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Ok, committed all the WAL format changes now.
This breaks pg_resetxlog -l at all. When I ran pg_resetxlog -l 0x01,0x01,0x01
in the HEAD, I got the following error message though the same command
On Monday, June 25, 2012 05:34:13 PM Robert Haas wrote:
On Mon, Jun 25, 2012 at 9:43 AM, Andres Freund and...@2ndquadrant.com
wrote:
The only theoretical way I see against that problem would be to
postpone all relation unlinks untill everything that could possibly
read them has
On Mon, Jun 25, 2012 at 1:24 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Ok, committed all the WAL format changes now.
I found the typo.
In walsender.c
-reply.write.xlogid, reply.write.xrecoff,
-reply.flush.xlogid, reply.flush.xrecoff,
-
On Tue, Jun 26, 2012 at 2:53 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Jun 25, 2012 at 1:24 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Ok, committed all the WAL format changes now.
I found the typo.
In walsender.c
- reply.write.xlogid,
On Mon, Jun 25, 2012 at 1:57 PM, Fujii Masao masao.fu...@gmail.com wrote:
should be . The attached patch fixes this typo.
Oh, I forgot to attach the patch.. Here is the patch.
I committed both of the patches you posted to this thread.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
On Mon, Jun 25, 2012 at 1:50 PM, Andres Freund and...@2ndquadrant.com wrote:
Its an argument why related infrastructure would be interesting to more than
that patch and thats not bad.
If the garbage collecting is done in a very simplistic manner it doesn't sound
too hard... The biggest problem
Hi,
(munching the mail from Robert and Kevin together)
On Monday, June 25, 2012 06:42:41 PM Kevin Grittner wrote:
Robert Haas robertmh...@gmail.com wrote:
I bet for a lot of replication systems, the answer is do a full
resync. In other words, we either forbid the operation outright
when
Excerpts from Robert Haas's message of lun jun 25 11:57:36 -0400 2012:
Really, I think
pg_upgrade needs this option too, unless we're going to kill the
problem at its root by providing a reliable way to enumerate database
names without first knowing the name one that you can connect to.
I
Andres Freund and...@2ndquadrant.com wrote:
We most particularly *don't* want DDL to replicate automatically,
because the schema changes are deployed along with related
software changes, and we like to pilot any changes for at least a
few days. Depending on the release, the rollout may take
On Mon, Jun 25, 2012 at 2:49 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of lun jun 25 11:57:36 -0400 2012:
Really, I think
pg_upgrade needs this option too, unless we're going to kill the
problem at its root by providing a reliable way to enumerate
Excerpts from Robert Haas's message of lun jun 25 14:58:25 -0400 2012:
On Mon, Jun 25, 2012 at 2:49 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of lun jun 25 11:57:36 -0400 2012:
Really, I think
pg_upgrade needs this option too, unless we're
Hi,
On Monday, June 25, 2012 08:13:54 PM Robert Haas wrote:
On Mon, Jun 25, 2012 at 1:50 PM, Andres Freund and...@2ndquadrant.com
wrote:
Its an argument why related infrastructure would be interesting to more
than that patch and thats not bad.
If the garbage collecting is done in a very
Magnus Hagander mag...@hagander.net writes:
Or that it takes less code/generates cleaner code...
So we're talking about some LZO things such as snappy from google, and
that would be another run time dependency IIUC.
I think it's time to talk about fastlz:
http://fastlz.org/
On Jun25, 2012, at 21:21 , Dimitri Fontaine wrote:
Magnus Hagander mag...@hagander.net writes:
Or that it takes less code/generates cleaner code...
So we're talking about some LZO things such as snappy from google, and
that would be another run time dependency IIUC.
I think it's time to
On Mon, Jun 25, 2012 at 3:45 PM, Florian Pflug f...@phlo.org wrote:
On Jun25, 2012, at 21:21 , Dimitri Fontaine wrote:
Magnus Hagander mag...@hagander.net writes:
Or that it takes less code/generates cleaner code...
So we're talking about some LZO things such as snappy from google, and
that
Andres Freund and...@2ndquadrant.com writes:
On Monday, June 25, 2012 05:57:51 PM Tom Lane wrote:
Well, my response is no. I could see saying that we require (some) C99
features at this point, but not features that are in no standard, no
matter how popular gcc might be.
Also, 'static
Excerpts from Kevin Grittner's message of lun jun 25 14:50:54 -0400 2012:
One fine point regarding before and after images -- if a value
doesn't change in an UPDATE, there's no reason to include it in both
the BEFORE and AFTER tuple images, as long as we have the null
column bitmaps -- or
Robert Haas robertmh...@gmail.com writes:
From pg_upgrade's perspective, it would
be nice to have a flag that starts the server in some mode where
nobody but pg_upgrade can connect to it and all connections are
automatically allowed, but it's not exactly clear how to implement
nobody but
On 25 June 2012 20:59, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com writes:
Also, 'static inline' *is* C99 conforming as far as I can see?
Hmm. I went back and re-read the C99 spec, and it looks like most of
the headaches we had in the past with C99 inline are
On Mon, Jun 25, 2012 at 09:45:26PM +0200, Florian Pflug wrote:
On Jun25, 2012, at 21:21 , Dimitri Fontaine wrote:
Magnus Hagander mag...@hagander.net writes:
Or that it takes less code/generates cleaner code...
So we're talking about some LZO things such as snappy from google, and
that
Hi all,
I've been working on a new system view, pg_stat_lwlocks, to observe
LWLock, and just completed my 'proof-of-concept' code that can work
with version 9.1.
Now, I'd like to know the possibility of this feature for future
release.
With this patch, DBA can easily determine a bottleneck
On 25-06-2012 16:45, Florian Pflug wrote:
Agreed. If we extend the protocol to support compression, and not rely
on SSL, then let's pick one of these LZ77-style compressors, and let's
integrate it into our tree.
If we have an option to have it out of our tree, good; if not, let's integrate
On 25-06-2012 14:30, Greg Jaskiewicz wrote:
Wasn't this more of an issue in de-coupling compression from encryption ?
Let me give a try to take some conclusion. If we decide for an independent
compression code instead of an SSL-based one, that is a possibility to be
tested: SSL + SSL-based
On Mon, Jun 25, 2012 at 3:38 PM, Euler Taveira eu...@timbira.com wrote:
On 25-06-2012 16:45, Florian Pflug wrote:
Agreed. If we extend the protocol to support compression, and not rely
on SSL, then let's pick one of these LZ77-style compressors, and let's
integrate it into our tree.
If we
On 6/25/12 1:29 PM, Satoshi Nagayasu wrote:
(1) Performance
I've measured LWLock performance both with and without the patch,
and confirmed that this patch does not affect the LWLock perfomance
at all.
This would be my main concern with this patch; it's hard for me to
imagine that it
On 25.06.2012 21:01, Robert Haas wrote:
On Mon, Jun 25, 2012 at 1:57 PM, Fujii Masaomasao.fu...@gmail.com wrote:
should be. The attached patch fixes this typo.
Oh, I forgot to attach the patch.. Here is the patch.
I committed both of the patches you posted to this thread.
Thanks Robert.
On 12-06-21 04:37 AM, Andres Freund wrote:
Hi Steve,
Thanks!
Attached is a detailed review of the patch.
Very good analysis, thanks!
Another reasons why we cannot easily do 1) is that subtransactions aren't
discernible from top-level transactions before the top-level commit happens,
we can
Excerpts from Heikki Linnakangas's message of lun jun 25 20:09:34 -0400 2012:
On 25.06.2012 21:01, Robert Haas wrote:
On Mon, Jun 25, 2012 at 1:57 PM, Fujii Masaomasao.fu...@gmail.com wrote:
should be. The attached patch fixes this typo.
Oh, I forgot to attach the patch.. Here is the
I wrote:
Barring objections or better ideas, I'll push forward with applying
this patch and the dependency-fixup patch.
Applied and back-patched.
BTW, I had complained at the end of the pgsql-bugs thread about bug #6699
that it seemed like FK constraints would get prevented from being
restored
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
So I think we should change pg_resetxlog -l option to take a WAL file
name as argument, and fix pg_upgrade accordingly.
Seems reasonable I guess. It's really specifying a starting WAL
location, but only to file granularity, so
2012/06/26 6:44, Josh Berkus wrote:
On 6/25/12 1:29 PM, Satoshi Nagayasu wrote:
(1) Performance
I've measured LWLock performance both with and without the patch,
and confirmed that this patch does not affect the LWLock perfomance
at all.
This would be my main concern with this
On Mon, Jun 18, 2012 at 5:42 PM, Robert Haas robertmh...@gmail.com wrote:
Hmm. That was actually a gloss I added on existing code to try to
convince myself that it was safe; I don't think that the changes I
made make that any more or less safe than it was before.
Right, sorry. I thought
2012/06/26 7:04, Kevin Grittner wrote:
Josh Berkusj...@agliodbs.com wrote:
On 6/25/12 1:29 PM, Satoshi Nagayasu wrote:
(1) Performance
I've measured LWLock performance both with and without the
patch, and confirmed that this patch does not affect the LWLock
perfomance at all.
This
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
So I think we should change pg_resetxlog -l option to take a WAL file
name as argument, and fix pg_upgrade accordingly.
I cleaned up the framework patch a bit. My version's attached. Mainly,
returning false for failure in some code paths that are only going to
have the caller elog(FATAL) is rather pointless -- it seems much better
to just have the code itself do the elog(FATAL). In any case, I
searched for
Hello
I worked on simple patch, that enable access from server side to
client side data. It add two new hooks to libpq - one for returning of
local context, second for setting of local context.
A motivation is integration of possibilities of psql console together
with stronger language -
75 matches
Mail list logo
