On Fri, 2010-09-17 at 14:33 +0900, Fujii Masao wrote:
> On Thu, Sep 16, 2010 at 4:18 AM, Simon Riggs wrote:
> > We definitely have the time, so the question is, what are the best
> > ideas?
>
> Before advancing the review of each patch, we must determine what
> should be committed in 9.1, and wha
(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 those points could be committed first.
Yeah, I think we need to decide on the
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, and it seems that we'll
> need some libpq changes to allow ack
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 important, others are not.
>
> * Quor
(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
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,
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 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, 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 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
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, 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
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
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 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
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, 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
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: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
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
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 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
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, 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 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, 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, 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, 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, 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 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 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 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
* 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
* 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
"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
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
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
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 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
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
* 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
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
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
> > >
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, 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, 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 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 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
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 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
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 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
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
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
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
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 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
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
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
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
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:
> 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: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 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 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
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
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.
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
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.
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
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
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 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
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
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 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
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
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.
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
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
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
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
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 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
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 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 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 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
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
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
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)
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
> -
> 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
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
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
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
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
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
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 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
1 - 100 of 104 matches
Mail list logo
