I have been updating my work in progress here:
http://git.postgresql.org/gitweb?p=users/jdavis/postgres.git;a=log;h=refs/heads/rangetypes
Right now, it's not in a reviewable state, but those interested can
glance through the code.
Quick synopsis (for illustration purposes only; don't expect much
On Tue, Dec 28, 2010 at 22:17, Magnus Hagander wrote:
>>> We definitely need the very basic level for 9.1, and we can always
>>> improve on it later :-)
>
>>> pg_stat_walsender. It would then only need the columns for procpid,
>>> usesysid, usename, client_addr, client_port, and the WALsender
>>>
On Sun, Dec 12, 2010 at 5:15 AM, Simon Riggs wrote:
> On Sat, 2010-12-11 at 22:03 +0100, Heikki Linnakangas wrote:
>> (Moving to pgsql-hackers)
>>
>> On 10.12.2010 20:21, Tom Lane wrote:
>> > Simon Riggs writes:
>> >> Reduce spurious Hot Standby conflicts from never-visible records.
>> >> Hot Sta
On 01/03/2011 12:15 PM, I wrote:
The following patch allows me to build the 8.3 and 8.4 branches using
Visual Studio 2008, once the build system is patched. But I don't
really know why. HEAD and 9.0 build fine without it. But those
branches branches fail with a complaint about IPPROTO_IPV6
On Mon, Jan 3, 2011 at 8:04 PM, Tom Lane wrote:
> Dave Page writes:
>> On Mon, Jan 3, 2011 at 6:50 PM, Tom Lane wrote:
>>> Magnus Hagander writes:
And we're not going to be changing the version that's actually used
for the official binary builds, so all you'll accomplish then is to
>>
Excerpts from Andres Freund's message of lun ene 03 12:03:58 -0300 2011:
> On Monday, January 03, 2011 03:38:56 PM Alvaro Herrera wrote:
> > Is anybody working on this patch?
> I am. Wont be finished in the next two days though (breakin last night...)
Okay ... I will be moving to a new house this
On Mon, Dec 20, 2010 at 1:19 PM, Noah Misch wrote:
> texteq, textne, byteaeq and byteane detoast their arguments, then check for
> equality of length. Unequal lengths imply the answer trivially; given equal
> lengths, the functions proceed to compare the actual bytes. We can skip
> detoasting en
On Mon, Jan 3, 2011 at 8:11 AM, Christian Ullrich wrote:
> this patch adds support for connecting to servers running on Windows
> and requesting SSPI authentication. It does this by treating
> AUTH_REQ_SSPI the same as AUTH_REQ_GSS if no native SSPI support is
> available.
I have to confess that
On Sun, Jan 2, 2011 at 6:43 AM, Dimitri Fontaine wrote:
> Dimitri Fontaine writes:
>> make -C contrib/citext install
>> psql -f .../head/share/contrib/citext.sql
>> psql
>> dim=# do $$ begin execute 'alter operator class public.citext_ops using
>> btree set schema utils'; end; $$;
>> ser
On Mon, Jan 3, 2011 at 17:23, Robert Haas wrote:
> On Mon, Jan 3, 2011 at 11:20 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> On the other hand, the REPLICATION privilege is denying you the right to
>>> perform an operation *even though you already are authenticated as a
>>> superuser*. I don'
On Jan 3, 2011, at 12:23 PM, Dimitri Fontaine wrote:
> "David E. Wheeler" writes:
>> The fact that the last two messages in the thread say something else
>> does not mean that they represent the consensus.
>
> Yeah, but as I'm the one writing the code, I gave myself more than one
> vote. And did
On Mon, Jan 3, 2011 at 3:15 PM, Dimitri Fontaine wrote:
>> On the other hand, I can certainly think of times when even a pretty
>> dumb implementation of this would have saved me some time.
>
> You mean like those:
>
> https://labs.omniti.com/labs/pgtreats/wiki/getddl
> https://github.com/dimitr
Andrew Dunstan writes:
> But more importantly, the buildfarm is about more than just "official
> build platform" support.
Agreed, we should be testing as many build platforms as possible. I was
just concerned about whether we were losing any coverage.
regards, tom lane
On 01/03/2011 03:04 PM, Tom Lane wrote:
Dave Page writes:
On Mon, Jan 3, 2011 at 6:50 PM, Tom Lane wrote:
Magnus Hagander writes:
And we're not going to be changing the version that's actually used
for the official binary builds, so all you'll accomplish then is to
have the buildfarm test
"David E. Wheeler" writes:
> The fact that the last two messages in the thread say something else
> does not mean that they represent the consensus.
Yeah, but as I'm the one writing the code, I gave myself more than one
vote. And did consider the alternatives but didn't like them so much.
> Righ
Bernd, are you still working on this?
On fre, 2010-10-15 at 13:36 -0400, Tom Lane wrote:
> Bernd Helmle writes:
> > Here is an updated version of the patch. It fixes the following issues
> > Andrew discovered during his review cycle:
>
> I looked through this a bit. It's not ready to commit u
"David E. Wheeler" writes:
>> http://pgsql.tapoueh.org/extensions/doc/html/extend-extension.html
>
> I was responding to your email mentioning it, which did not reference said
> docs.
Fair enough, I'm still interested in you telling me if I get to rewrite
them all or if it's explaining the thin
Robert Haas writes:
> I have to admit I'm a bit unsold on the approach as well. It seems
> like you could write a short Perl script which would transform a text
> format dump into the proposed format pretty easily, and if you did
> that and published the script, then the next poor shmuck who had
Dave Page writes:
> On Mon, Jan 3, 2011 at 6:50 PM, Tom Lane wrote:
>> Magnus Hagander writes:
>>> And we're not going to be changing the version that's actually used
>>> for the official binary builds, so all you'll accomplish then is to
>>> have the buildfarm test something different form what
On Mon, Jan 3, 2011 at 6:50 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Jan 3, 2011 at 19:08, Andrew Dunstan wrote:
>>> I'm not going to maintain more than one buildfarm member doing MSVC, and and
>>> if we were to adopt your policy I would not be able to use a modern-ish
>>> versio
On Jan 3, 2011, at 11:46 AM, Dimitri Fontaine wrote:
> Not what I have understood.
>
> http://archives.postgresql.org/pgsql-hackers/2010-12/msg01014.php
> http://archives.postgresql.org/pgsql-hackers/2010-12/msg01045.php
>
> AS there was no answer, the meaning for me is that it was ok to
> pro
On Jan 3, 2011, at 11:54 AM, Dimitri Fontaine wrote:
>> That's what I understood your original "UPGRADE from NULL" being. Did I
>> misread you?
>
> Are the docs about the feature, available handy in HTML so that you
> don't have to read them in SGML at my git repository, are they *that*
> bad?
>
On Mon, Jan 3, 2011 at 2:46 PM, Joel Jacobson wrote:
> My major concern of parsing the schema file is I would never fully
> trust the output from the script, even if the regex is extremely
> paranoid and really strict, there is still a risk it contains a bug.
That could possibly be resolved by us
"David E. Wheeler" writes:
> That's what I understood your original "UPGRADE from NULL" being. Did I
> misread you?
Are the docs about the feature, available handy in HTML so that you
don't have to read them in SGML at my git repository, are they *that*
bad?
http://pgsql.tapoueh.org/extension
On Jan 3, 2011, at 11:51 AM, Tom Lane wrote:
> 1. Doesn't work if you're upgrading an installation that has more than
> one database using the extension. There's only one library directory.
>
> 2. Not possible from a permissions standpoint. Even if you think it'd
> be smart to have the postgres
"David E. Wheeler" writes:
> On Jan 3, 2011, at 11:42 AM, Tom Lane wrote:
>> ... that flat out doesn't work. If the upgrade script tries to add
>> functions that didn't exist in the old .so, it'll fail.
> Right, what I'm saying is that `ALTER EXTENSION foo UPGRADE;` should install
> the .so, to
On Jan 3, 2011, at 11:49 AM, Dimitri Fontaine wrote:
> "David E. Wheeler" writes:
>> I rather doubt that "WRAPPER" will be accepted as a reserved word in the
>> grammar.
>
> It's already in the grammar, and I didn't change its "level".
Okay.
>>> dim=# create wrapper extension lo;
>>> CREATE E
"David E. Wheeler" writes:
> I rather doubt that "WRAPPER" will be accepted as a reserved word in the
> grammar.
It's already in the grammar, and I didn't change its "level".
>> dim=# create wrapper extension lo;
>> CREATE EXTENSION
>
> What happened to your UPGRADE from NULL idea?
You upgrade
"David E. Wheeler" writes:
> I thought we were going to try to avoid having entries for upgrades in
> the control file.
Not what I have understood.
http://archives.postgresql.org/pgsql-hackers/2010-12/msg01014.php
http://archives.postgresql.org/pgsql-hackers/2010-12/msg01045.php
AS there wa
> Robert Haas writes:
>> I have to admit I'm a bit unsold on the approach as well. It seems
>> like you could write a short Perl script which would transform a text
>> format dump into the proposed format pretty easily, and if you did
>> that and published the script, then the next poor shmuck wh
On Jan 3, 2011, at 11:42 AM, Tom Lane wrote:
> It is, but I don't see any alternative. As Dimitri said, the .so will
> typically be installed by a packaging system, so we don't have any
> opportunity to run SQL code beforehand. In any case ...
>
>> The new .so should not be installed until the
"David E. Wheeler" writes:
> On Dec 29, 2010, at 2:01 PM, Dimitri Fontaine wrote:
>> At the time you tell PostgreSQL about the new extension, the shared
>> object file has been in place for some time already, and the upgrade SQL
>> script has not been ran yet.
> That sounds dangerous.
It is, but
On Mon, Jan 3, 2011 at 2:23 PM, Andrew Dunstan wrote:
> Incidentally, I just went looking for VS2005/Express on microsoft.com. I
> don't know if they still make it available, but if they do it's fairly well
> hidden. I could find VS2008/Express and VS2010/Express very easily. ISTM
> that having su
On 01/03/2011 01:50 PM, Tom Lane wrote:
It might be reasonable to argue that this particular patch
is too invasive to be safe to back-patch, but I don't agree with the
premise that it isn't a reasonable topic for a back-patch.
The patch for the non-buildsystem code is one line. The rest is a
Robert Haas writes:
> On Mon, Jan 3, 2011 at 1:34 PM, Tom Lane wrote:
>> Yeah, that's exactly it. I can think of some possible uses for
>> splitting up pg_dump output, but frankly "to ease diff-ing" is not
>> one of them. For that problem, it's nothing but a crude kluge that
>> only sort-of hel
On Jan 1, 2011, at 2:30 PM, Dimitri Fontaine wrote:
> To support that is quite simple in fact, as the following commands will
> do the trick:
>
> CREATE WRAPPER EXTENSION ...;-- don't run the script
> ALTER OBJECT ... SET EXTENSION ...; -- that's in the upgrade script
> ALTER EXTENSIO
On Mon, Jan 3, 2011 at 2:01 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>> Kevin Grittner wrote:
>
>>> Before you decide to taunt me again, I guess I should point out a
>>> few things here.
>>
>> Sorry, that was intended as good-natured humor, not taunting.
>
> Oh, I took it that way. I gues
On Dec 29, 2010, at 2:01 PM, Dimitri Fontaine wrote:
># lo
>comment = 'managing Large Objects'
>version = '9.1devel'
>relocatable = true
>upgrade_from_null = 'null => lo.upgrade.sql'
>
> Here, any property that begins with 'upgrade_from_' is considered as an
> upgrade setup an
On Mon, Jan 3, 2011 at 1:34 PM, Tom Lane wrote:
> Robert Haas writes:
>> On the specific issue of overloaded functions, I have a feeling that
>> the only feasible option is going to be to put them all in the same
>> file. If you put them in different files, the names will either be
>> very long
Robert Haas wrote:
> Kevin Grittner wrote:
>> Before you decide to taunt me again, I guess I should point out a
>> few things here.
>
> Sorry, that was intended as good-natured humor, not taunting.
Oh, I took it that way. I guess my attempt at humor through an
oblique reference to a line fr
On Mon, Jan 3, 2011 at 19:50, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Jan 3, 2011 at 19:08, Andrew Dunstan wrote:
>>> I'm not going to maintain more than one buildfarm member doing MSVC, and and
>>> if we were to adopt your policy I would not be able to use a modern-ish
>>> version
Magnus Hagander writes:
> On Mon, Jan 3, 2011 at 19:08, Andrew Dunstan wrote:
>> I'm not going to maintain more than one buildfarm member doing MSVC, and and
>> if we were to adopt your policy I would not be able to use a modern-ish
>> version of the compiler/SDK and also build all the live branc
2011/1/3 Tom Lane :
> pg_dump from dumping objects in a consistent order ... and once you do
> that, you don't need this patch.
> Yeah, that's exactly it. I can think of some possible uses for
> splitting up pg_dump output, but frankly "to ease diff-ing" is not
> one of them. For that problem, it
On Mon, Jan 3, 2011 at 1:18 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> Users hate having to do explicit locking (especially users whose
>> names rhyme with Bevin Bittner)
>
> :-)
>
> Before you decide to taunt me again, I guess I should point out a
> few things here.
Sorry, that was int
Robert Haas writes:
> On the specific issue of overloaded functions, I have a feeling that
> the only feasible option is going to be to put them all in the same
> file. If you put them in different files, the names will either be
> very long (because they'll have to include the argument types) or
2011/1/3 Robert Haas :
> will become confusing for users and hard for us to maintain. We're
> going to need to agree on something that won't be perfect for
> everyone, but will hopefully be a sufficient improvement for enough
> people to be worth doing.
Good point.
I think we can at least agree t
On Mon, Jan 3, 2011 at 19:08, Andrew Dunstan wrote:
>
>
> On 01/03/2011 12:43 PM, Magnus Hagander wrote:
>>
>> On Mon, Jan 3, 2011 at 18:15, Andrew Dunstan wrote:
>>>
>>> The following patch allows me to build the 8.3 and 8.4 branches using
>>> Visual
>>> Studio 2008, once the build system is pat
On Mon, Jan 3, 2011 at 7:11 AM, Dmitry Koterov wrote:
> To me, this is a wonderful feature, thanks! I think many people would be
> happy if this patch woud be included to the mainstream (and it is quite
> short and simple).
> About name ordering - I think that the problem exists for objects:
> 1.
Robert Haas wrote:
> Users hate having to do explicit locking (especially users whose
> names rhyme with Bevin Bittner)
:-)
Before you decide to taunt me again, I guess I should point out a
few things here.
Should SSI and MERGE both make it into 9.1, there's every reason to
believe that ru
On 01/03/2011 12:43 PM, Magnus Hagander wrote:
On Mon, Jan 3, 2011 at 18:15, Andrew Dunstan wrote:
The following patch allows me to build the 8.3 and 8.4 branches using Visual
Studio 2008, once the build system is patched. But I don't really know why.
HEAD and 9.0 build fine without it. But t
On Mon, 2011-01-03 at 19:01 +0200, Heikki Linnakangas wrote:
> > If we do that, then we definitely need a catch-all WHEN statement, so
> > that we can say
> >
> > WHEN NOT MATCHED
> >INSERT
> > WHEN MATCHED
> >UPDATE
> > ELSE
> >{ INSERT into another table so we can try again in a minu
On Mon, Jan 3, 2011 at 12:01 PM, Heikki Linnakangas
wrote:
>> If we do that, then we definitely need a catch-all WHEN statement, so
>> that we can say
>>
>> WHEN NOT MATCHED
>> INSERT
>> WHEN MATCHED
>> UPDATE
>> ELSE
>> { INSERT into another table so we can try again in a minute
>> or RAIS
On Mon, Jan 3, 2011 at 18:15, Andrew Dunstan wrote:
>
> The following patch allows me to build the 8.3 and 8.4 branches using Visual
> Studio 2008, once the build system is patched. But I don't really know why.
> HEAD and 9.0 build fine without it. But those branches branches fail with a
> complai
The following patch allows me to build the 8.3 and 8.4 branches using
Visual Studio 2008, once the build system is patched. But I don't really
know why. HEAD and 9.0 build fine without it. But those branches
branches fail with a complaint about IPPROTO_IPV6 being undefined.
The patch seems h
On Mon, Jan 3, 2011 at 11:36 AM, Florian Pflug wrote:
> On Jan3, 2011, at 17:21 , Robert Haas wrote:
>> On Mon, Jan 3, 2011 at 11:08 AM, Heikki Linnakangas
>>> In serializable mode you get a serialization error.
>>
>> I don't think this part is true. You can certainly do this:
>>
>> CREATE TABLE
On 03.01.2011 18:49, Simon Riggs wrote:
On Mon, 2011-01-03 at 18:35 +0200, Heikki Linnakangas wrote:
On 03.01.2011 18:29, Simon Riggs wrote:
On Mon, 2011-01-03 at 18:08 +0200, Heikki Linnakangas wrote:
It works in read committed mode, because you acquire a new snapshot
after the LOCK TABLE, a
On Mon, 2011-01-03 at 18:35 +0200, Heikki Linnakangas wrote:
> On 03.01.2011 18:29, Simon Riggs wrote:
> > On Mon, 2011-01-03 at 18:08 +0200, Heikki Linnakangas wrote:
> >
> >> It works in read committed mode, because you acquire a new snapshot
> >> after the LOCK TABLE, and anyone else who modifie
On Jan3, 2011, at 17:21 , Robert Haas wrote:
> On Mon, Jan 3, 2011 at 11:08 AM, Heikki Linnakangas
>> In serializable mode you get a serialization error.
>
> I don't think this part is true. You can certainly do this:
>
> CREATE TABLE test (a int);
> BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABL
On 03.01.2011 18:29, Simon Riggs wrote:
On Mon, 2011-01-03 at 18:08 +0200, Heikki Linnakangas wrote:
It works in read committed mode, because you acquire a new snapshot
after the LOCK TABLE, and anyone else who modified the table must commit
before the lock is granted. In serializable mode you
On Mon, 2011-01-03 at 18:08 +0200, Heikki Linnakangas wrote:
> It works in read committed mode, because you acquire a new snapshot
> after the LOCK TABLE, and anyone else who modified the table must commit
> before the lock is granted. In serializable mode you get a serialization
> error.
If i
* Magnus Hagander (mag...@hagander.net) wrote:
> It's already a basic requirement that they need to be the same -
> replicating over a CREATE TABLESPACE is going to fail otherwise..
> Being able to deal with that in a nice way would be good, of course,
> but we don't have that today.
If CREATE TAB
On Mon, Jan 3, 2011 at 11:20 AM, Tom Lane wrote:
> Robert Haas writes:
>> On the other hand, the REPLICATION privilege is denying you the right to
>> perform an operation *even though you already are authenticated as a
>> superuser*. I don't think there's anywhere else in the system where
>> we
On Mon, Jan 3, 2011 at 11:08 AM, Heikki Linnakangas
wrote:
> On 03.01.2011 18:02, Robert Haas wrote:
>>
>> On Mon, Jan 3, 2011 at 10:58 AM, Heikki Linnakangas
>> wrote:
>>>
>>> On 03.01.2011 17:56, Stephen Frost wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
>
> Like Heikk
Robert Haas writes:
> On the other hand, the REPLICATION privilege is denying you the right to
> perform an operation *even though you already are authenticated as a
> superuser*. I don't think there's anywhere else in the system where
> we allow a privilege to non-super-users but deny that same
On Mon, Jan 3, 2011 at 17:17, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Mon, Jan 3, 2011 at 10:42 AM, Magnus Hagander wrote:
>> > Well, they need to be put back in the same location on the other
>> > machine (slave in case of replication, tarball otherwise). If I j
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Jan 3, 2011 at 10:42 AM, Magnus Hagander wrote:
> > Well, they need to be put back in the same location on the other
> > machine (slave in case of replication, tarball otherwise). If I just
> > traverse the symlinks, they'll just appears as a
On Mon, Jan 3, 2011 at 17:14, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jan 3, 2011 at 10:42 AM, Magnus Hagander wrote:
>>> Well, they need to be put back in the same location on the other
>>> machine (slave in case of replication, tarball otherwise). If I just
>>> traverse the symlinks,
Robert Haas writes:
> On Mon, Jan 3, 2011 at 10:42 AM, Magnus Hagander wrote:
>> Well, they need to be put back in the same location on the other
>> machine (slave in case of replication, tarball otherwise). If I just
>> traverse the symlinks, they'll just appears as a subdirectory of
>> pg_tblsp
On 03.01.2011 18:02, Robert Haas wrote:
On Mon, Jan 3, 2011 at 10:58 AM, Heikki Linnakangas
wrote:
On 03.01.2011 17:56, Stephen Frost wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
Like Heikki, I'd rather have the feature without a workaround for the
concurrency issues than no feature
On 01/03/2011 10:58 AM, Heikki Linnakangas wrote:
In general, I also thought/expected to have some kind of UPSERT type
capability with our initial MERGE support, even if it requires a big
lock and won't operate concurrently, etc.
You can of course LOCK TABLE as a work-around, if that's what
On Mon, Jan 3, 2011 at 10:58 AM, Heikki Linnakangas
wrote:
> On 03.01.2011 17:56, Stephen Frost wrote:
>>
>> * Robert Haas (robertmh...@gmail.com) wrote:
>>>
>>> Like Heikki, I'd rather have the feature without a workaround for the
>>> concurrency issues than no feature.
>>
>> I'm still trying to
On Mon, Jan 3, 2011 at 6:00 AM, Magnus Hagander wrote:
> On Fri, Dec 31, 2010 at 15:38, Magnus Hagander wrote:
>> On Thu, Dec 30, 2010 at 15:54, Peter Eisentraut wrote:
>>> On ons, 2010-12-29 at 11:09 +0100, Magnus Hagander wrote:
I've applied this version (with some minor typo-fixes).
>>>
On 03.01.2011 17:56, Stephen Frost wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
Like Heikki, I'd rather have the feature without a workaround for the
concurrency issues than no feature.
I'm still trying to figure out the problem with having the table-level
lock, unless we really think p
* Robert Haas (robertmh...@gmail.com) wrote:
> Like Heikki, I'd rather have the feature without a workaround for the
> concurrency issues than no feature.
I'm still trying to figure out the problem with having the table-level
lock, unless we really think people will be doing concurrent MERGE's
whe
On Mon, Jan 3, 2011 at 10:42 AM, Magnus Hagander wrote:
> Well, they need to be put back in the same location on the other
> machine (slave in case of replication, tarball otherwise). If I just
> traverse the symlinks, they'll just appears as a subdirectory of
> pg_tblspc on the other machine, won
Magnus Hagander writes:
> On Mon, Jan 3, 2011 at 16:29, Tom Lane wrote:
>> Wait a minute. Isn't this problem about to metastasize into "I need to
>> read *every* global catalog from walsender"? If not, why not? If so,
>> I think we need another answer.
> Um, why would I need that? I need to b
On Mon, 3 Jan 2011 10:44:19 +0100, Magnus Hagander
wrote:
Yeah, it looks that way - it's missing the ordering of the contrib
I'll run it once for that now, and then please rebase your
patch on top of that - makes it easier to review it.
The rebased patch can be grabbed from http://www.piening.
Excerpts from Magnus Hagander's message of lun ene 03 12:25:28 -0300 2011:
> Can someone throw me a pointer or two on how to actually do that? :-)
> Am I correct in assuming I need to add it to
> RelationCacheInitializePhase2(), and to do that, need to figure out
> how to define a TableSpaceRelati
On Mon, Jan 3, 2011 at 16:40, Robert Haas wrote:
> On Mon, Jan 3, 2011 at 10:37 AM, Magnus Hagander wrote:
>> On Mon, Jan 3, 2011 at 16:34, Robert Haas wrote:
>>> On Mon, Jan 3, 2011 at 10:25 AM, Magnus Hagander
>>> wrote:
I'm working on completing Heikki's patch for streaming base backup
On Mon, Jan 3, 2011 at 10:37 AM, Magnus Hagander wrote:
> On Mon, Jan 3, 2011 at 16:34, Robert Haas wrote:
>> On Mon, Jan 3, 2011 at 10:25 AM, Magnus Hagander wrote:
>>> I'm working on completing Heikki's patch for streaming base backups,
>>> and have run into a problem:
>>>
>>> In order to dump
On Mon, Jan 3, 2011 at 16:34, Robert Haas wrote:
> On Mon, Jan 3, 2011 at 10:25 AM, Magnus Hagander wrote:
>> I'm working on completing Heikki's patch for streaming base backups,
>> and have run into a problem:
>>
>> In order to dump all tablespaces properly, I have to know where they
>> are (d'u
On Mon, Jan 3, 2011 at 16:29, Tom Lane wrote:
> Magnus Hagander writes:
>> I'm working on completing Heikki's patch for streaming base backups,
>> and have run into a problem:
>
>> In order to dump all tablespaces properly, I have to know where they
>> are (d'uh). In order to do that, I need to s
On 01/03/2011 06:26 AM, Brar Piening wrote:
No that was probably all.
My patch - fixed as described above - should apply to your repository once
you've run perltidy.
I'll rebase the patch as soon as I return from work unless you tell me
otherwise.
Please, this time let's backpatch the
On Mon, Jan 3, 2011 at 10:25 AM, Magnus Hagander wrote:
> I'm working on completing Heikki's patch for streaming base backups,
> and have run into a problem:
>
> In order to dump all tablespaces properly, I have to know where they
> are (d'uh).
Can you get that directly from the filesystem layout
Excerpts from Robert Haas's message of lun ene 03 12:21:44 -0300 2011:
> Yeah, that's no good. Maybe there's a good way to clear things up
> with an errdetail(), though I'm having a hard time thinking how to
> phrase it.
>
> ERROR: sequence "%s" does not support the requested operation
> DETAIL:
Magnus Hagander writes:
> I'm working on completing Heikki's patch for streaming base backups,
> and have run into a problem:
> In order to dump all tablespaces properly, I have to know where they
> are (d'uh). In order to do that, I need to scan pg_tablespace.
Wait a minute. Isn't this problem
I'm working on completing Heikki's patch for streaming base backups,
and have run into a problem:
In order to dump all tablespaces properly, I have to know where they
are (d'uh). In order to do that, I need to scan pg_tablespace.
However, scanning that from walsender gives me:
FATAL: cannot read
On Sun, Jan 2, 2011 at 4:45 PM, Peter Eisentraut wrote:
> On lör, 2011-01-01 at 17:21 -0500, Robert Haas wrote:
>> > I don't see anything wrong with having 20 or 30 messages of variants of
>> >
>> > "foo cannot be used on bar"
>> >
>> > without placeholders.
>>
>> Well, that's OK with me. It seem
On Monday, January 03, 2011 03:38:56 PM Alvaro Herrera wrote:
> Is anybody working on this patch?
I am. Wont be finished in the next two days though (breakin last night...)
Andres
PS: Alvarro: commandprompt.com doesn't resolv anymore, so I can't send you the
email directly...
--
Sent via pgsq
On Mon, Jan 3, 2011 at 4:02 AM, Jim Nasby wrote:
> FWIW, last time I looked at how Oracle handled compression, it would only
> compress existing data. As soon as you modified a row, it ended up
> un-compressed, presumably in a different page that was also un-compressed.
IIUC, InnoDB basically c
On Mon, Jan 3, 2011 at 8:35 AM, Simon Riggs wrote:
> On Mon, 2011-01-03 at 15:12 +0200, Heikki Linnakangas wrote:
>> This patch has never tried to implement concurrency-safe upsert. It
>> implements the MERGE command as specified by the SQL standard, nothing
>> more, nothing less. Let's not move t
Alvaro Herrera wrote:
> Is anybody working on this patch?
I'm not, but I sure hope someone is -- we could *really* use this in
the SSI patch. With something providing the equivalent
functionality to Andres's previous patch, and about one day's work
in the SSI patch, SSI could guarantee that a
Is anybody working on this patch?
--
Álvaro Herrera
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgr
On Mon, 2011-01-03 at 15:12 +0200, Heikki Linnakangas wrote:
> This patch has never tried to implement concurrency-safe upsert. It
> implements the MERGE command as specified by the SQL standard, nothing
> more, nothing less. Let's not move the goalposts. Googling around, at
> least MS SQL Serv
On 03.01.2011 11:37, Simon Riggs wrote:
On Mon, 2011-01-03 at 01:53 -0500, Greg Smith wrote:
In advance of the planned but not available yet ability to
lock individual index key values, locking the whole table is the only
possible implementation that can work correctly here I'm aware of.
This
Hello all,
this patch adds support for connecting to servers running on Windows
and requesting SSPI authentication. It does this by treating
AUTH_REQ_SSPI the same as AUTH_REQ_GSS if no native SSPI support is
available.
In addition to being generally useful, this is a workaround to a
problem wit
Hello, Filip
2011/1/1 Filip Rembiałkowski
>
> 2010/12/30 JotaComm
>
>> Hello,
>>
>> Last week I had a serious problem with my PostgreSQL database. My
>> autovacuum is OFF, but in September it started to prevent the transaction
>> wraparoud; however last week the following message appeared conti
To me, this is a wonderful feature, thanks! I think many people would be
happy if this patch woud be included to the mainstream (and it is quite
short and simple).
About name ordering - I think that the problem exists for objects:
1. Stored functions.
2. Foreign keys/triggers (objects which has o
On Sun, Jan 2, 2011 at 15:07, Peter Eisentraut wrote:
> On tis, 2010-12-28 at 13:13 +0100, Magnus Hagander wrote:
>> My pg_streamrecv no longer works with 9.1, because it returns
>> PGRES_COPY_BOTH instead of PGRES_COPY_OUT when initating a copy.
>> That's fine.
>>
>> So I'd like to make it work o
Original-Nachricht
> Datum: Mon, 3 Jan 2011 10:44:19 +0100
> Von: Magnus Hagander
> An: Brar Piening
> CC: pgsql-hackers@postgresql.org
> Betreff: Re: [HACKERS] Visual Studio 2010/Windows SDK 7.1 support
> This patch does not apply at all to my repository. Every single hunk
>
1 - 100 of 113 matches
Mail list logo
