-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Sep 17, 2010 at 11:21:13PM -0400, Robert Haas wrote:
[...]
> Wow, 100 processes??! Really? I guess I don't actually know how large
> modern proctables are, but on my MacOS X machine, for example, there
> are only 75 processes showing up righ
Robert Haas writes:
> Wow, 100 processes??! Really? I guess I don't actually know how large
> modern proctables are, but on my MacOS X machine, for example, there
> are only 75 processes showing up right now in "ps auxww". My Fedora
> 12 machine has 97. That's including a PostgreSQL instance in
On Fri, Sep 17, 2010 at 4:49 PM, Markus Wanner wrote:
>> If you're optimizing for
>> ability to respond quickly to a sudden load, keeping idle backends
>> will probably win even when the number of them you're keeping around
>> is fairly high. If you're optimizing for minimal overall resource
>> c
On Sat, Sep 18, 2010 at 11:46 AM, Robert Haas wrote:
> wrote:
>> One of my proposal is we don't have to keep the original input text.
>> We store JSON data in effective internal formats. If users want to get
>> human-readable output, they can use stringify() with indentation option.
>
> There's a
On Fri, Sep 17, 2010 at 10:28 PM, Itagaki Takahiro
wrote:
> One of my proposal is we don't have to keep the original input text.
> We store JSON data in effective internal formats. If users want to get
> human-readable output, they can use stringify() with indentation option.
There's a trade-off
Itagaki Takahiro wrote:
> On Sat, Sep 18, 2010 at 6:45 AM, Joseph Adams
> wrote:
> >> Why do we need to store the value in UTF8 encoding?
> >
> > because the JSON code needs to handle Unicode escapes like
> > "\u266B", but there is no simple and efficient way (that I know of) to
> > convert sing
On Sat, Sep 18, 2010 at 6:45 AM, Joseph Adams
wrote:
>> Why do we need to store the value in UTF8 encoding?
>
> because the JSON code needs to handle Unicode escapes like
> "\u266B", but there is no simple and efficient way (that I know of) to
> convert single characters to/from the server encod
Apologies. I'm new to Postgres and I didn't see that feature. It satisfies
what I want to do.
Thanks.
On Thu, Sep 16, 2010 at 7:34 PM, Fujii Masao wrote:
> On Fri, Sep 17, 2010 at 6:49 AM, fazool mein wrote:
> > I am designing a heartbeat system between replicas to know when a replica
> > goes
Thom Brown wrote:
> > VACUUM mvcc_demo;
> > VACUUM
> > SELECT pg_relation_size('mvcc_demo');
> > ?pg_relation_size
> > --
> > ? ? ? ? ? ? ? ?0
> > (1 row)
> >
>
> That's odd. When I delete val 2, the freespace goes back up in 9.0rc1
> (attached).
Your numbers are odd too. With o
I wrote:
> Oh, mystery explained upon comparing the cvs2git.options files.
> I was using Max's file which had this in it:
> ExcludeRegexpStrategyRule(r'unlabeled-.*'),
> I think I'll rerun without that just to convince myself of what it is
> we're dropping. But right now it seems that everythi
On 18 September 2010 02:00, Bruce Momjian wrote:
> Bruce Momjian wrote:
>> Can anyone explain why VACUUM after INSERT shows steadily decreasing
>> freespace, while DELETE of the same rows does not decrease consistently?
>>
>> Specifically, after one row is inserted I see:
>>
>> SELECT pg_fre
> timestamptz is a preferred type, so no you probably can't change that
> without breaking a lot of stuff. It's not immediately clear to me why
> that's wrong anyway.
Just that having a value implicitly acquire time zone information it
didn't originally have seems dangerous. But I can't come up
Bruce Momjian wrote:
> Can anyone explain why VACUUM after INSERT shows steadily decreasing
> freespace, while DELETE of the same rows does not decrease consistently?
>
> Specifically, after one row is inserted I see:
>
> SELECT pg_freespace('mvcc_demo');
>pg_freespace
> -
Can anyone explain why VACUUM after INSERT shows steadily decreasing
freespace, while DELETE of the same rows does not decrease consistently?
Specifically, after one row is inserted I see:
SELECT pg_freespace('mvcc_demo');
pg_freespace
--
(0,8128)
Josh Berkus writes:
> I was noticing that, where we have a function which has two versions,
> timestamp and timestamptz (for example, date_trunc()), if I use a DATE
> timestamptz is the default cast. Shouldn't timestamp without time zone
> be the default? Is this something we can fix without an
Folks,
I was noticing that, where we have a function which has two versions,
timestamp and timestamptz (for example, date_trunc()), if I use a DATE
timestamptz is the default cast. Shouldn't timestamp without time zone
be the default? Is this something we can fix without an overhaul of the
type
On Fri, Sep 17, 2010 at 4:50 PM, Peter Eisentraut wrote:
> On tor, 2010-09-16 at 19:14 -0400, Robert Haas wrote:
>> I think that there should be a function which returns just this one
>> piece of data and is not automatically called as part of select * from
>> pg_stat_activity. Then we could even
Magnus Hagander writes:
> On Sat, Sep 18, 2010 at 00:06, Tom Lane wrote:
>> [ scratches head ... ] That's weird. We probably ought to figure out
>> why you and I are getting different results. I wonder if there's some
>> other discrepancy in the anoncvs pull?
> Could be.
Oh, mystery explaine
On Sat, Sep 18, 2010 at 00:06, Tom Lane wrote:
> Magnus Hagander writes:
>> On Fri, Sep 17, 2010 at 23:01, Tom Lane wrote:
>>> git branch -D unlabeled-1.44.2
>>> git branch -D unlabeled-1.51.2
>>> git branch -D unlabeled-1.59.2
>>> git branch -D unlabeled-1.87.2
>>> git branch -D unlabeled-1.90.
Magnus Hagander writes:
> On Fri, Sep 17, 2010 at 23:01, Tom Lane wrote:
>> git branch -D unlabeled-1.44.2
>> git branch -D unlabeled-1.51.2
>> git branch -D unlabeled-1.59.2
>> git branch -D unlabeled-1.87.2
>> git branch -D unlabeled-1.90.2
>>
>> You should not need any of the above; I don't s
On Fri, Sep 17, 2010 at 8:32 AM, Itagaki Takahiro
wrote:
> On Fri, Aug 13, 2010 at 7:33 PM, Joseph Adams
> wrote:
>> Updated patch: the JSON code has all been moved into core, so this
>> patch is now for a built-in data type.
>
> I have a question about the design of the JSON type. Why do we nee
On Fri, Sep 17, 2010 at 23:21, Tom Lane wrote:
> Actually, the simplest way to handle this might be to just delete all
> five of those tags during the conversion, and then I'll put them back
> in the right places later when I add the other old-release tags.
> That way we won't have any tags gettin
On Fri, Sep 17, 2010 at 23:01, Tom Lane wrote:
> BTW, on the cleanup steps:
>
> # Remove bogus branches
> git branch -D unlabeled-1.44.2
> git branch -D unlabeled-1.51.2
> git branch -D unlabeled-1.59.2
> git branch -D unlabeled-1.87.2
> git branch -D unlabeled-1.90.2
>
> You should not need any o
Tom Lane wrote:
> Bruce Momjian writes:
> > + This means that UPDATE, DELETE, and SELECT can trigger space
> > + reclamation, while INSERT ... VALUES cannot because it does not retrieve
> > + a row.
>
> I don't believe that's correct. It might have happened to work that way
> for you in a partic
I wrote:
> In addition to the above, we're going to want to clean up the
> Release_2_0_0 and Release_2_0 tags, but I'm not sure if there's
> a reasonable way to script those when the commit SHA1's aren't frozen
> yet. I can give you timestamps for the commits they should point at,
> but I lack the
Thom Brown wrote:
> On 17 September 2010 20:52, Bruce Momjian wrote:
> > I would like to apply the attached patch to README.HOT so clarify when
> > single-page cleanup happens, e.g. not during INSERT.
> >
>
> "... when the page is nearly full (<10%) ..."
>
> Shouldn't that be >90%?
>
> "... whi
FYI, I have compiled/installed git 1.7.3.rc2 on my BSD/OS 4.3.1 machine
with the attached minor changes.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
*** ./git-1.7.3.rc2/Makefile.
BTW, on the cleanup steps:
# Remove bogus branches
git branch -D unlabeled-1.44.2
git branch -D unlabeled-1.51.2
git branch -D unlabeled-1.59.2
git branch -D unlabeled-1.87.2
git branch -D unlabeled-1.90.2
You should not need any of the above; I don't see those being generated
anymore with the cl
On tor, 2010-09-16 at 19:14 -0400, Robert Haas wrote:
> I think that there should be a function which returns just this one
> piece of data and is not automatically called as part of select * from
> pg_stat_activity. Then we could eventually decide to give backends a
> way to know if that function
Robert,
On 09/17/2010 05:52 PM, Robert Haas wrote:
Technically, you could start an autonomous transaction from within an
autonomous transaction, so I don't think there's a hard maximum of one
per normal backend. However, I agree that the expected case is to not
have very many.
Thanks for poin
On Fri, Sep 17, 2010 at 20:37, Magnus Hagander wrote:
> On Fri, Sep 17, 2010 at 20:32, Tom Lane wrote:
>> I wrote:
>>> Something in the rsync process thinks that ignoring subdirectories
>>> named "core" is a good idea. I'm a bit surprised nobody ever noticed
>>> these were missing from anoncvs b
On fre, 2010-09-17 at 18:15 +0900, KaiGai Kohei wrote:
> * At the ATPrepAddColumn(), it seems to me someone added a check
> to prevent adding a new column to typed table, as you try to
> add in this patch.
Good catch. Redundant checks removed.
> * At the ATPrepAlterColumnType(), you enclosed
Bruce Momjian writes:
> + This means that UPDATE, DELETE, and SELECT can trigger space
> + reclamation, while INSERT ... VALUES cannot because it does not retrieve
> + a row.
I don't believe that's correct. It might have happened to work that way
for you in a particular test. It's certainly not
On 17 September 2010 20:52, Bruce Momjian wrote:
> I would like to apply the attached patch to README.HOT so clarify when
> single-page cleanup happens, e.g. not during INSERT.
>
"... when the page is nearly full (<10%) ..."
Shouldn't that be >90%?
"... while INSERT ... VALUES cannot because it
I would like to apply the attached patch to README.HOT so clarify when
single-page cleanup happens, e.g. not during INSERT.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Index: src
Simon Riggs writes:
> On Fri, 2010-09-17 at 21:20 +0900, Fujii Masao wrote:
>> What synchronization level does each combination of sync_replication
>> and sync_replication_service lead to?
>
> There are only 4 possible outcomes. There is no combination, so we don't
> need a table like that above.
Simon Riggs writes:
> On Fri, 2010-09-17 at 21:20 +0900, Fujii Masao wrote:
>> According to what I heard, some people want to guarantee that all the
>> transactions are *always* written in *all* the synchronous standbys.
>
> You don't need standby registration at all. You can do that with a
> sing
Magnus Hagander writes:
> Will not doing the backbranches make it harder to backport patches?
> Probably shouldn't, unless you're changing the very first line of the
> file, right?
The $PostgreSQL$ lines haven't been a backporting problem in the past,
so I don't see why they'd be one now.
On Fri, Sep 17, 2010 at 20:49, Tom Lane wrote:
> I looked a bit more at your pggit_migrate stuff. I'm not terribly happy
> with the proposed clean_keywords.pl script. I'd like it to reduce the
> $PostgreSQL$ thingies to the full pathname of the file, rather than
> try to remove all trace of them
On 09/17/2010 02:37 PM, Magnus Hagander wrote:
On Fri, Sep 17, 2010 at 20:32, Tom Lane wrote:
I wrote:
Something in the rsync process thinks that ignoring subdirectories
named "core" is a good idea. I'm a bit surprised nobody ever noticed
these were missing from anoncvs before ...
That's b
I looked a bit more at your pggit_migrate stuff. I'm not terribly happy
with the proposed clean_keywords.pl script. I'd like it to reduce the
$PostgreSQL$ thingies to the full pathname of the file, rather than
try to remove all trace of them, eg
*$PostgreSQL: pgsql/src/port/unsetenv.c,v
On Fri, Sep 17, 2010 at 20:32, Tom Lane wrote:
> I wrote:
>> Something in the rsync process thinks that ignoring subdirectories
>> named "core" is a good idea. I'm a bit surprised nobody ever noticed
>> these were missing from anoncvs before ...
>
> That's because they aren't. It's the -C switch
I wrote:
> Something in the rsync process thinks that ignoring subdirectories
> named "core" is a good idea. I'm a bit surprised nobody ever noticed
> these were missing from anoncvs before ...
That's because they aren't. It's the -C switch in your rsync call
that's at fault. (And this demonstr
On Fri, Sep 17, 2010 at 20:24, Tom Lane wrote:
> I wrote:
>> Hmm. I didn't try rsync'ing from anoncvs ... I logged into the master
>> and tar'd up the /cvsroot directory ;-). I wonder if there's something
>> wrong with the anoncvs copy of that subdirectory? Will do the rsync
>> and compare.
>
>
I wrote:
> Hmm. I didn't try rsync'ing from anoncvs ... I logged into the master
> and tar'd up the /cvsroot directory ;-). I wonder if there's something
> wrong with the anoncvs copy of that subdirectory? Will do the rsync
> and compare.
Doh:
Only in myrepo/pgsql/contrib/retep/uk/org/retep/xm
Magnus Hagander writes:
> Just to confirm, you ran your patch against current cvs, right? So you
> also got the "hunk succeeded at offset 1 line" a whole bunch of times?
> Then it's not that that's broken.
Right, the patch still applies fine, it's just off by a line or so in
many places (probably
At 2010-09-16 21:22:54 +0900, itagaki.takah...@gmail.com wrote:
>
> Please read the thread. The patch is intended to be applied after
> "sequence scan + sort for CLUSTER" patch.
Sorry. I missed that. The patch looks fine, then.
-- ams
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
On Fri, Sep 17, 2010 at 19:20, Tom Lane wrote:
> Magnus Hagander writes:
>> On Fri, Sep 17, 2010 at 18:28, Robert Haas wrote:
>>> Sorry, I must not have cleaned out the old state properly.
>
>> Turns out I did th esame thing from my box to the repo on git.postgresql.org.
>
>> So I've now wiped t
Robert Haas writes:
> I was just noticing that, on this page here:
> http://www.postgresql.org/docs/9.0/static/catalogs.html
> ...all of the catalogs are in alphabetical order, except for
> pg_db_role_setting, which is filed in the place in alphabetical order
> where it would belong if the name w
On 17 September 2010 18:17, Robert Haas wrote:
> I was just noticing that, on this page here:
>
> http://www.postgresql.org/docs/9.0/static/catalogs.html
>
> ...all of the catalogs are in alphabetical order, except for
> pg_db_role_setting, which is filed in the place in alphabetical order
> where
Magnus Hagander writes:
> On Fri, Sep 17, 2010 at 18:28, Robert Haas wrote:
>> Sorry, I must not have cleaned out the old state properly.
> Turns out I did th esame thing from my box to the repo on git.postgresql.org.
> So I've now wiped that repository and re-pushed mine. Can you give it
> ano
I was just noticing that, on this page here:
http://www.postgresql.org/docs/9.0/static/catalogs.html
...all of the catalogs are in alphabetical order, except for
pg_db_role_setting, which is filed in the place in alphabetical order
where it would belong if the name were spelled pg_setting.
Is th
On Fri, Sep 17, 2010 at 18:28, Robert Haas wrote:
> On Fri, Sep 17, 2010 at 11:55 AM, Robert Haas wrote:
>> On Fri, Sep 17, 2010 at 11:39 AM, Tom Lane wrote:
>>> Robert Haas writes:
Magnus posted an updated conversion this morning.
>>>
http://git.postgresql.org/gitweb?p=postgresql-mig
Robert Haas writes:
>> On Fri, Sep 17, 2010 at 11:39 AM, Tom Lane wrote:
>>> and I only see nine. It's got some *other* problems though; compared
>>> to a conversion I just finished locally, it's missing a whole lot of
>>> history for some of the old jdbc files.
> What's the problem with the ol
On Fri, Sep 17, 2010 at 11:55 AM, Robert Haas wrote:
> On Fri, Sep 17, 2010 at 11:39 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> Magnus posted an updated conversion this morning.
>>
>>> http://git.postgresql.org/gitweb?p=postgresql-migration.git;a=summary
>>
>>> Evidently, however, he didn't
We will take another run at converting our CVS repository to Git on
Monday (the 20th). Hopefully this won't interfere too much with
the commitfest, since most work will still be on reviewing rather than
actual committing at that point.
As before, there will be a "quiet time" to let interested peo
On 2010-09-17 10:09, Heikki Linnakangas wrote:
I think it makes most sense to set sync vs. async in the master, and
the level of synchronicity in the slave. Although I have sympathy
for the argument that it's simpler if you configure it all from the
master side as well.
Just a comment as a
On 09/17/2010 11:39 AM, Tom Lane wrote:
Is there any possibility that "git clone" isn't very trustworthy?
It's a bit scary that we don't see identical views of this repository.
I should have thought that very unlikely.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
On Fri, 2010-09-17 at 16:09 +0300, Heikki Linnakangas wrote:
> >> I don't expect any meaningful differences in terms of performance
> >> between any of the discussed options. The big question right now is...
> >
> > This is the critical point. Politely, I would observe that *You* do not
> > think
On Fri, Sep 17, 2010 at 11:39 AM, Tom Lane wrote:
> Robert Haas writes:
>> Magnus posted an updated conversion this morning.
>
>> http://git.postgresql.org/gitweb?p=postgresql-migration.git;a=summary
>
>> Evidently, however, he didn't do the same things you did, because
>> there are DEFINITELY mo
On Fri, Sep 17, 2010 at 11:29 AM, Markus Wanner wrote:
> autonomous transactions: max. one per normal backend (correct?), way fewer
> should suffice in most cases, only control data to be passed around
Technically, you could start an autonomous transaction from within an
autonomous transaction, s
On Fri, 2010-09-17 at 11:30 -0400, Aidan Van Dyk wrote:
> * Robert Haas [100917 11:24]:
> > On Fri, Sep 17, 2010 at 11:22 AM, Simon Riggs wrote:
> > > On Fri, 2010-09-17 at 09:36 -0400, Aidan Van Dyk wrote:
> > >
> > >> I want to have them configured in a fsync WAL/style sync rep, I want to
> > >
Robert Haas writes:
> Magnus posted an updated conversion this morning.
> http://git.postgresql.org/gitweb?p=postgresql-migration.git;a=summary
> Evidently, however, he didn't do the same things you did, because
> there are DEFINITELY more than 9 manufactured commits in this one.
Um ... I just
* Robert Haas [100917 11:24]:
> On Fri, Sep 17, 2010 at 11:22 AM, Simon Riggs wrote:
> > On Fri, 2010-09-17 at 09:36 -0400, Aidan Van Dyk wrote:
> >
> >> I want to have them configured in a fsync WAL/style sync rep, I want to
> >> make sure that if the master comes up first after I get power back
Hi,
On 09/16/2010 07:47 PM, Robert Haas wrote:
It would be nice if there were a way to create
a general facility here that we could then build various applications
on, but I'm not sure whether that's the case. We had some
back-and-forth about what is best for replication vs. what is best for
va
On Fri, Sep 17, 2010 at 11:22 AM, Simon Riggs wrote:
> On Fri, 2010-09-17 at 09:36 -0400, Aidan Van Dyk wrote:
>
>> I want to have them configured in a fsync WAL/style sync rep, I want to
>> make sure that if the master comes up first after I get power back, it's
>> not going to be claiming transa
On Fri, 2010-09-17 at 09:36 -0400, Aidan Van Dyk wrote:
> I want to have them configured in a fsync WAL/style sync rep, I want to
> make sure that if the master comes up first after I get power back, it's
> not going to be claiming transactions are committed while the slave
> (which happens to hav
On Tue, Sep 14, 2010 at 10:19 AM, Tom Lane wrote:
> Attached is an updated repository.fixups script that inserts dead
> revisions in every case where a new file was back-patched into an
> existing branch. With that, we are down to a total of nine manufactured
> commits, to wit:
> [details]
Magnu
Tom Lane wrote:
> That assumption is absolutely, totally not going to fly.
Understood; I'm already working on it based on Heikki's input.
>> This needs to work when the xid of a transaction is found in the
>> MVCC data of a tuple for any overlapping serializable transaction
>> -- even if tha
"Kevin Grittner" writes:
> Heikki Linnakangas wrote:
>> That sounds like it can eat through your shared memory very quickly
>> if you have a lot of subtransactions.
> Hmmm I've never explicitly used subtransactions, so I don't tend
> to think of them routinely going too deep. And the stru
* Fujii Masao [100917 07:57]:
> Synchronous replication is basically used to reduce the
> downtime, and "wait forever" option opposes that.
Hm... I'm not sure I'ld agree with that. I'ld rather have some
downtime, and my data available, then have less downtime, but find that
I'm
* Robert Haas [100917 07:44]:
> On Fri, Sep 17, 2010 at 7:31 AM, Simon Riggs wrote:
> > The only thing standby registration allows you to do is know whether
> > there was supposed to be a standby there, but yet it isn't there now. I
> > don't see that point as being important because it seems str
On 17/09/10 15:56, Simon Riggs wrote:
On Fri, 2010-09-17 at 13:41 +0300, Heikki Linnakangas wrote:
On 17/09/10 12:49, Simon Riggs wrote:
Without performance tests to demonstrate "why", these do sound hard to
understand. But we should note that DRBD offers recv ("B") and fsync
("C") as separate
On Fri, 2010-09-17 at 21:43 +0900, Fujii Masao wrote:
> On Fri, Sep 17, 2010 at 5:09 PM, Heikki Linnakangas
> wrote:
> > * Quorum commit. Wait until n standbys acknowledge. n=1 and n=all servers
> > can be seen as important special cases of this.
>
> I think that we should skip quorum commit at t
On Fri, 2010-09-17 at 13:41 +0300, Heikki Linnakangas wrote:
> On 17/09/10 12:49, Simon Riggs wrote:
> > Fujii has long talked about 4 levels of service also. Why change? I had
> > thought that part was pretty much agreed between all of us.
>
> Now you lost me. I agree that we need 4 levels of ser
On Fri, 2010-09-17 at 20:56 +0900, Fujii Masao wrote:
> On Fri, Sep 17, 2010 at 7:41 PM, Heikki Linnakangas
> wrote:
> >> The question is do we want standby registration on master and if so,
> >> why?
> >
> > Well, aside from how to configure synchronous replication, standby
> > registration would
On Fri, 2010-09-17 at 21:20 +0900, Fujii Masao wrote:
> On Fri, Sep 17, 2010 at 8:31 PM, Simon Riggs wrote:
> > The only thing standby registration allows you to do is know whether
> > there was supposed to be a standby there, but yet it isn't there now. I
> > don't see that point as being importa
On Fri, Sep 17, 2010 at 8:43 AM, Fujii Masao wrote:
> On Fri, Sep 17, 2010 at 5:09 PM, Heikki Linnakangas
> wrote:
>> * Quorum commit. Wait until n standbys acknowledge. n=1 and n=all servers
>> can be seen as important special cases of this.
>
> I think that we should skip quorum commit at the f
On Fri, Sep 17, 2010 at 5:09 PM, Heikki Linnakangas
wrote:
> * Quorum commit. Wait until n standbys acknowledge. n=1 and n=all servers
> can be seen as important special cases of this.
I think that we should skip quorum commit at the first phase
because the design seems to be still poorly-thought
On Fri, 2010-09-17 at 21:20 +0900, Fujii Masao wrote:
> What synchronization level does each combination of sync_replication
> and sync_replication_service lead to? I'd like to see something like
> the following table.
>
> sync_replication | sync_replication_service | result
> --
On Fri, Aug 13, 2010 at 7:33 PM, Joseph Adams
wrote:
> Updated patch: the JSON code has all been moved into core, so this
> patch is now for a built-in data type.
I have a question about the design of the JSON type. Why do we need to
store the value in UTF8 encoding? It's true the RFC of JSON sa
On Tue, Sep 14, 2010 at 12:01:18PM -0400, Tom Lane wrote:
> Well ... I guess the other attitude we could take is that that was a
> private development branch of Michael's. If we'd been working in git
Actually it wasn't. This branch was created when ecpg grew too big for the
released version of bi
On Fri, Sep 17, 2010 at 8:31 PM, Simon Riggs wrote:
> The only thing standby registration allows you to do is know whether
> there was supposed to be a standby there, but yet it isn't there now. I
> don't see that point as being important because it seems strange to me
> to want to wait for a stan
Heikki Linnakangas wrote:
> On 17/09/10 14:56, Kevin Grittner wrote:
>> Heikki Linnakangas wrote:
>>> Why not use SubTransGetTopmostTransaction() ?
>>
>> This needs to work when the xid of a transaction is found in the
>> MVCC data of a tuple for any overlapping serializable transaction
>> -- even
On 17/09/10 14:56, Kevin Grittner wrote:
Heikki Linnakangas wrote:
Why not use SubTransGetTopmostTransaction() ?
This needs to work when the xid of a transaction is found in the MVCC
data of a tuple for any overlapping serializable transaction -- even
if that transaction has completed and its
On Fri, Sep 17, 2010 at 7:41 PM, Heikki Linnakangas
wrote:
>> The question is do we want standby registration on master and if so,
>> why?
>
> Well, aside from how to configure synchronous replication, standby
> registration would help with retaining the right amount of WAL in the
> master. wal_ke
Heikki Linnakangas wrote:
> So, the purpose of SerializableXidHash is to provide quick access
> to the SERIALIZABLEXACT struct of a top-level transaction, when you
> know its transaction id or any of its subtransaction ids.
Right.
> To implement the "or any of its subtransaction ids" part, y
On Fri, Sep 17, 2010 at 7:31 AM, Simon Riggs wrote:
> The only thing standby registration allows you to do is know whether
> there was supposed to be a standby there, but yet it isn't there now. I
> don't see that point as being important because it seems strange to me
> to want to wait for a stan
On Fri, Sep 17, 2010 at 6:41 AM, Heikki Linnakangas
wrote:
>>> So what should the user interface be like? Given the 1st and 2nd
>>> requirement, we need standby registration. If some standbys are
>>> important and others are not, the master needs to distinguish between
>>> them to be able to deter
On Fri, 2010-09-17 at 13:41 +0300, Heikki Linnakangas wrote:
> On 17/09/10 12:49, Simon Riggs wrote:
> > This isn't just about UI, there are significant and important
> > differences between the proposals in terms of the capability and control
> > they offer.
>
> Sure. The point of focusing on the
Simon Riggs writes:
> So far, I have added the point that if a user requests a level of
> confirmation that is currently unavailable, then it will use the highest
> level of confirmation available now. That stops us from waiting for
> timeout for every transaction we run if standby goes down hard,
On 17/09/10 12:49, Simon Riggs wrote:
This isn't just about UI, there are significant and important
differences between the proposals in terms of the capability and control
they offer.
Sure. The point of focusing on the UI is that the UI demonstrates what
capability and control a proposal offe
On Fri, 2010-09-17 at 12:30 +0300, Heikki Linnakangas wrote:
> If the synchronicity is configured in the standby, how does the master
> know that there's a synchronous slave out there that it should wait for,
> if that slave isn't connected at the moment?
That isn't a question you need standby
Heikki Linnakangas writes:
> If the synchronicity is configured in the standby, how does the master know
> that there's a synchronous slave out there that it should wait for, if that
> slave isn't connected at the moment?
That's what quorum is trying to solve. The master knows how many votes
per
On Fri, Sep 17, 2010 at 5:09 PM, Heikki Linnakangas
wrote:
> That said, there's a few small things that can be progressed regardless of
> the details of synchronous replication. There's the changes to trigger
> failover with a signal, and it seems that we'll need some libpq changes to
> allow ackn
On Fri, 2010-09-17 at 11:09 +0300, Heikki Linnakangas wrote:
> (changed subject again.)
>
> On 17/09/10 10:06, Simon Riggs wrote:
> > I don't think we can determine how far to implement without considering
> > both approaches in detail. With regard to your points below, I don't
> > think any of th
On 17/09/10 12:10, Dimitri Fontaine wrote:
Heikki Linnakangas writes:
* Support multiple standbys with various synchronization levels.
* What happens if a synchronous standby isn't connected at the moment?
Return immediately vs. wait forever.
* Per-transaction control. Some transactions are i
On Fri, Sep 17, 2010 at 5:09 PM, Heikki Linnakangas
wrote:
> That said, there's a few small things that can be progressed regardless of
> the details of synchronous replication. There's the changes to trigger
> failover with a signal, and it seems that we'll need some libpq changes to
> allow ackn
On Fri, 2010-09-17 at 09:15 +0100, Simon Riggs wrote:
> On Fri, 2010-09-17 at 11:09 +0300, Heikki Linnakangas wrote:
> > That said, there's a few small things that can be progressed
> > regardless of the details of synchronous replication. There's the
> > changes to trigger failover with a signal,
(2010/08/09 5:54), Peter Eisentraut wrote:
> For the next review cycle, here is a patch that adds some ALTER TYPE
> subcommands for composite types:
>
> ALTER TYPE ... ADD ATTRIBUTE
> ALTER TYPE ... DROP ATTRIBUTE
> ALTER TYPE ... ALTER ATTRIBUTE ... SET DATA TYPE
> ALTER TYPE ... RENAME ATTRIBUTE
1 - 100 of 104 matches
Mail list logo
