From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane
Robert Haas 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 connectio
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 - plpgsql.
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 report
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane
Heikki Linnakangas 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
2012/06/26 7:04, Kevin Grittner wrote:
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
On Mon, Jun 18, 2012 at 5:42 PM, Robert Haas 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 there was some streng
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 patch;
Heikki Linnakangas 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 treating the argument as a
file name
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
restore
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 Masao wrote:
> >>> "<<" should be">>". The attached patch fixes this typo.
> >>
> >> Oh, I forgot to attach the patch.. Here is the pa
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 o
On 25.06.2012 21:01, Robert Haas wrote:
On Mon, Jun 25, 2012 at 1:57 PM, Fujii Masao 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. I was thinkin
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
On Mon, Jun 25, 2012 at 3:38 PM, Euler Taveira 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 have an op
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 com
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
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 aroun
On Mon, Jun 25, 2012 at 09:45:26PM +0200, Florian Pflug wrote:
> On Jun25, 2012, at 21:21 , Dimitri Fontaine wrote:
> > Magnus Hagander 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 b
On 25 June 2012 20:59, Tom Lane wrote:
> Andres Freund 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 specific to the
> case where you want a
Robert Haas 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 pg_upgrade can conne
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
Andres Freund 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 inline' *is* C99 co
On Mon, Jun 25, 2012 at 3:45 PM, Florian Pflug wrote:
> On Jun25, 2012, at 21:21 , Dimitri Fontaine wrote:
>> Magnus Hagander 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
On Jun25, 2012, at 21:21 , Dimitri Fontaine wrote:
> Magnus Hagander 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 fa
Magnus Hagander 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/
http://code.google.com/p/fastlz/so
Hi,
On Monday, June 25, 2012 08:13:54 PM Robert Haas wrote:
> On Mon, Jun 25, 2012 at 1:50 PM, Andres Freund
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
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
> 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 th
On Mon, Jun 25, 2012 at 2:49 PM, Alvaro Herrera
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 database
>> names w
Andres Freund 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 a
>> couple mo
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.
Hi,
(munching the mail from Robert and Kevin together)
On Monday, June 25, 2012 06:42:41 PM Kevin Grittner wrote:
> Robert Haas 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
On Mon, Jun 25, 2012 at 1:50 PM, Andres Freund 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 is probably crash-
On Mon, Jun 25, 2012 at 1:57 PM, Fujii Masao 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
The Enter
On Tue, Jun 26, 2012 at 2:53 AM, Fujii Masao wrote:
> On Mon, Jun 25, 2012 at 1:24 AM, Heikki Linnakangas
> wrote:
>> Ok, committed all the WAL format changes now.
>
> I found the typo.
>
> In walsender.c
> - reply.write.xlogid, reply.write.xrecoff,
> - reply.flush.x
On Mon, Jun 25, 2012 at 1:24 AM, Heikki Linnakangas
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,
-reply.apply.xlogid, rep
On Monday, June 25, 2012 05:34:13 PM Robert Haas wrote:
> On Mon, Jun 25, 2012 at 9:43 AM, Andres Freund
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
On Mon, Jun 25, 2012 at 1:24 AM, Heikki Linnakangas
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
successfully completed in 9.1.
pg_
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 h
On Monday, June 25, 2012 05:57:51 PM Tom Lane wrote:
> Andres Freund 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 t
On Mon, Jun 25, 2012 at 8:11 AM, Kevin Grittner
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 @@ PrintControlValues(bool guessed)
On Mon, Jun 25, 2012 at 12:35 PM, Tom Lane wrote:
> Robert Haas 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 som
On Mon, Jun 25, 2012 at 12:42 PM, Kevin Grittner
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 particular topology with a
Robert Haas 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 with the
> tab
Robert Haas 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 the test complet
On Mon, Jun 25, 2012 at 12:07:55PM -0400, Tom Lane wrote:
> "David E. Wheeler" 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 ori
"David E. Wheeler" 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 { die shift };
On Mon, Jun 25, 2012 at 11:50 AM, Tom Lane wrote:
> Robert Haas 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
>> selecti
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 warni
Andres Freund 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 equivalent
> behav
On Sat, Jun 23, 2012 at 6:26 PM, Peter Eisentraut 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 oversight.
>
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-compa
Robert Haas 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 configuration fil
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
On Monday, June 25, 2012 05:15:43 PM Tom Lane wrote:
> Andres Freund 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
On Mon, Jun 25, 2012 at 9:43 AM, Andres Freund 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
>> > ever move
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';
How
On 25 June 2012 13:11, Kevin Grittner 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
> /home/kevin/pg/master/c
Andres Freund 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 there be no oth
Peter Geoghegan writes:
> On 22 June 2012 01:04, 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.
> So those three don't have medium
On Mon, Jun 25, 2012 at 8:11 AM, Kevin Grittner
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
> /home/kevin/p
On Mon, Jun 25, 2012 at 3:46 PM, Tom Lane wrote:
> Pavel Golub 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 sti
Pavel Golub 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 problems
with pg_
On Monday, June 25, 2012 03:08:51 AM Robert Haas wrote:
> On Sun, Jun 24, 2012 at 5:11 PM, Andres Freund
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 to the view it
Peter Eisentraut 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 idiomatic
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 f
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 l
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:
--- a/src/backend/commands/c
On Mon, Jun 25, 2012 at 4:04 AM, Robert Haas wrote:
> On Fri, Jun 22, 2012 at 12:38 PM, Euler Taveira wrote:
>> On 20-06-2012 17:40, Marko Kreen wrote:
>>> On Wed, Jun 20, 2012 at 10:05 PM, Florian Pflug wrote:
I'm starting to think that relying on SSL/TLS for compression of
unencrypte
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
/home/kevin/pg/master/contrib/pg_upgrade/tmp_check/install//home/kevin/pg/master/D
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 i
On Mon, Jun 25, 2012 at 11:42 AM, Peter Eisentraut 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
>
> mingwcompat.c:60
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
dllimpor
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 (
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
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 brea
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 warn
76 matches
Mail list logo
