>> The current system give people the completely false impression that
>> 7.0 and 7.4 are somehow similar.
>
> On what planet?
on every single planet of the universe, except the one called
"postgrearth", whose inhabitants breathe sql and eat messages from
postgresql mailing lists... :-)
most peop
Max Bowsher wrote:
> On 20/08/10 19:07, Magnus Hagander wrote:
>> On Fri, Aug 20, 2010 at 19:56, Max Bowsher wrote:
>>> On 20/08/10 18:43, Magnus Hagander wrote:
On Fri, Aug 20, 2010 at 19:41, Max Bowsher wrote:
> On 20/08/10 18:30, Magnus Hagander wrote:
>> On Fri, Aug 20, 2010 at 1
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> It's possible that we're arguing for the sake of arguing
No it's not! ;)
> It's nice to be able to keep track of the major version
> number without running out of fingers (at least for a few more years)
> and it's nice to be abl
On Fri, Aug 20, 2010 at 10:43 PM, Joshua D. Drake
wrote:
>> True, we don't always have the best track record for bumping major
>> releases. (ponders) Hmmm...I'm rethinking my immediate rejection of the
>> idea now. 7.3 to 7.4 should have been 7.3 to 8.0. Certainly it was more
>> major than 8.0 to
On Aug 20, 2010, at 7:49 PM, Robert Haas wrote:
> I think the semantic versioning approach makes sense for libraries,
> but it is not too clear to me that it makes sense for other kinds of
> applications. YMMV, of course.
Yeah, I'm more concerned about determining dependencies in extensions and
On Fri, Aug 20, 2010 at 2:12 PM, David E. Wheeler wrote:
> Would it be possible to *always* use three integers? So the next release
> would be "9.0.0beta5" or "9.0.0rc1"? In addition to being more consistent, it
> also means that PostgreSQL would be adhering to Semantic Versioning
> (http://sem
On Aug 20, 2010, at 5:38 PM, Greg Sabino Mullane wrote:
>> Then why are we discussing it on -hackers?
>
> Because you will need buy in from the hackers if you
> ever want to do something as radical as change to
> a two-number, one dot system (or some the slightly
> less radical earlier suggest
On Sat, 2010-08-21 at 01:36 +, Greg Sabino Mullane wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
>
>
> > Look at other DBMSes:
> > Oracle: 8i, 9i, 10g, 11g
> > Informix 9, 10, 11
> > MS SQL Server 7, 2000, 2005, 2008
>
> > is not only confusing but make people think we are so
On Sat, 2010-08-21 at 01:31 +, Greg Sabino Mullane wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
>
>
> >> Flocks? Handful at best, and no reason we should be catering to
> >> their inaccuracies.
>
> > Depends on the goal. If our goal is to continue to add confusion to the
>
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Look at other DBMSes:
> Oracle: 8i, 9i, 10g, 11g
> Informix 9, 10, 11
> MS SQL Server 7, 2000, 2005, 2008
> is not only confusing but make people think we are somehow behind the
> others... someone actually told me that Oracle is in version 1
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
>> Flocks? Handful at best, and no reason we should be catering to
>> their inaccuracies.
> Depends on the goal. If our goal is to continue to add confusion to the
> masses of users we have, you are correct. If our goal is to simplify the
> ab
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Then why are we discussing it on -hackers?
Because you will need buy in from the hackers if you
ever want to do something as radical as change to
a two-number, one dot system (or some the slightly
less radical earlier suggestions). For the
(2010/08/20 23:34), Robert Haas wrote:
2010/8/19 KaiGai Kohei:
(2010/08/20 11:45), Robert Haas wrote:
2010/8/19 KaiGai Kohei:
I also plan to add a security hook on authorization time.
It shall allow external security providers to set up credential of
the authenticated clients.
Please note tha
On Fri, 2010-08-20 at 15:41 -0700, Josh Berkus wrote:
> > Not really a comparable argument. I find it interesting that people are
> > making logical arguments about something that is clearly not in the
> > logical realm. This is marketing people.
>
> Then why are we discussing it on -hackers?
Go
Magnus Hagander writes:
> I have now pushed a complete copy of the latest migrated repository to
> http://git.postgresql.org/gitweb?p=git-migration-test.git;a=summary.
> This one has tkey keyword expansion on, which we decided we want. My
> script that compares branch tips and tags to cvs now sho
> Not really a comparable argument. I find it interesting that people are
> making logical arguments about something that is clearly not in the
> logical realm. This is marketing people.
Then why are we discussing it on -hackers?
--
-- Josh Berkus
On 20/08/10 19:30, Tom Lane wrote:
> Max Bowsher writes:
>> My guess at this point is that there may be a (very old?) version of cvs
>> which, when adding a file to a branch, actually misrecorded the file as
>> having existed on the branch from the moment it was first added to trunk
>> - this woul
On 20/08/10 19:54, Magnus Hagander wrote:
> On Fri, Aug 20, 2010 at 20:52, Tom Lane wrote:
>> Magnus Hagander writes:
>>> In fact, is the only thing that's wrong here the commit message?
>>> Because it's probably trivial to just patch that away.. Hmm, but i
>>> guess we'd like to hav ethe actual
On 20/08/10 18:43, Magnus Hagander wrote:
> On Fri, Aug 20, 2010 at 19:41, Max Bowsher wrote:
>> On 20/08/10 18:30, Magnus Hagander wrote:
>>> On Fri, Aug 20, 2010 at 19:28, Tom Lane wrote:
Max Bowsher writes:
> The history that cvs2svn is aiming to represent here is this:
> 1)
On 20/08/10 19:07, Magnus Hagander wrote:
> On Fri, Aug 20, 2010 at 19:56, Max Bowsher wrote:
>> On 20/08/10 18:43, Magnus Hagander wrote:
>>> On Fri, Aug 20, 2010 at 19:41, Max Bowsher wrote:
On 20/08/10 18:30, Magnus Hagander wrote:
> On Fri, Aug 20, 2010 at 19:28, Tom Lane wrote:
>>>
On 20/08/10 18:30, Magnus Hagander wrote:
> On Fri, Aug 20, 2010 at 19:28, Tom Lane wrote:
>> Max Bowsher writes:
>>> The history that cvs2svn is aiming to represent here is this:
>>
>>> 1) At the time of creation of the REL8_4_STABLE branch, plperl_opmask.pl
>>> did *not* exist.
>>
>>> 2) Later,
On 20/08/10 14:36, Robert Haas wrote:
> On Fri, Aug 20, 2010 at 9:28 AM, Magnus Hagander wrote:
>> I believe Robert had some comments/questions as well :-)
>
> What Magnus means is that I'm a grumpy old developer who complains
> about everything.
>
> Anyway, what I noticed was that we're getting
On 20/08/10 18:28, Tom Lane wrote:
> Max Bowsher writes:
>> The history that cvs2svn is aiming to represent here is this:
>
>> 1) At the time of creation of the REL8_4_STABLE branch, plperl_opmask.pl
>> did *not* exist.
>
>> 2) Later, it was added to trunk.
>
>> 3) Then, someone retroactively a
On Fri, 2010-08-20 at 18:10 -0400, Robert Haas wrote:
> >
> >
> > Maybe we can give marketing brand names to every new version so people
> > is not confused by numbers...
>
> Ah, yes. Because it's so intuitive that Windows 7 comes after Windows 95...
> :-)
Not really a comparable argument. I f
On 20 August 2010 23:10, Robert Haas wrote:
> On Aug 20, 2010, at 5:55 PM, Jaime Casanova wrote:
>> On Fri, Aug 20, 2010 at 4:48 PM, Greg Stark wrote:
>>> On Fri, Aug 20, 2010 at 10:41 PM, Jaime Casanova
>>> wrote:
Look at other DBMSes:
Oracle: 8i, 9i, 10g, 11g
Informix 9, 10, 1
On Fri, Aug 20, 2010 at 23:39, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Aug 20, 2010 at 4:27 PM, Tom Lane wrote:
>>> There are a whole lot of commits listed there that have nothing to do
>>> with anything that ever happened on the 8.3 branch.
>
>> The problem you are looking at here has
On Aug 20, 2010, at 5:55 PM, Jaime Casanova wrote:
> On Fri, Aug 20, 2010 at 4:48 PM, Greg Stark wrote:
>> On Fri, Aug 20, 2010 at 10:41 PM, Jaime Casanova
>> wrote:
>>> Look at other DBMSes:
>>> Oracle: 8i, 9i, 10g, 11g
>>> Informix 9, 10, 11
>>> MS SQL Server 7, 2000, 2005, 2008
>>>
>>> note
I wrote:
> If there are a lot of user-hostile behaviors there, it might be
> worth looking at the possibility of bending the SSI techniques to
> that end
In the "for what it's worth" department, I tried out the current
Serializable Snapshot Isolation (SSI) patch with this test case at
the SERIA
On Fri, Aug 20, 2010 at 10:55 PM, Jaime Casanova wrote:
>> In any case those are all marketing brand names. The actual releases
>> do in fact have real version numbers and no, they aren't all minor
>> releases. Oracle 8i was 8.1.x which was indeed a major release over
>> 8.0.
>>
>
> Maybe we can g
On Fri, Aug 20, 2010 at 4:48 PM, Greg Stark wrote:
> On Fri, Aug 20, 2010 at 10:41 PM, Jaime Casanova
> wrote:
>> Look at other DBMSes:
>> Oracle: 8i, 9i, 10g, 11g
>> Informix 9, 10, 11
>> MS SQL Server 7, 2000, 2005, 2008
>>
>> note the lack of dotes (and even if they actually have dots, those
On Fri, Aug 20, 2010 at 10:41 PM, Jaime Casanova wrote:
> Look at other DBMSes:
> Oracle: 8i, 9i, 10g, 11g
> Informix 9, 10, 11
> MS SQL Server 7, 2000, 2005, 2008
>
> note the lack of dotes (and even if they actually have dots, those are
> minor versions).
>
So your proposal is that we name the
On Fri, Aug 20, 2010 at 04:41:20PM -0500, Jaime Casanova wrote:
> On Fri, Aug 20, 2010 at 1:48 PM, David E. Wheeler
> wrote:
> > On Aug 20, 2010, at 11:47 AM, David Fetter wrote:
> >
> >> The current system give people the completely false impression
> >> that 7.0 and 7.4 are somehow similar.
> >
On Fri, Aug 20, 2010 at 1:48 PM, David E. Wheeler wrote:
> On Aug 20, 2010, at 11:47 AM, David Fetter wrote:
>
>> The current system give people the completely false impression that
>> 7.0 and 7.4 are somehow similar.
>
> On what planet?
>
Look at other DBMSes:
Oracle: 8i, 9i, 10g, 11g
Informix 9
On Aug 20, 2010, at 2:10 PM, Tom Lane wrote:
> 9.0.0 is less than 9.0.0anything. Unless you wire some specific
> knowledge of semantics of particular letter-strings into the comparison
> algorithm, it's difficult to come to another decision, IMO.
That's what Semantic versions do. From the spec's
Robert Haas writes:
> On Fri, Aug 20, 2010 at 4:27 PM, Tom Lane wrote:
>> There are a whole lot of commits listed there that have nothing to do
>> with anything that ever happened on the 8.3 branch.
> The problem you are looking at here has been fixed. We are looking at
> a different problem no
On Fri, 2010-08-20 at 21:17 +, Greg Sabino Mullane wrote:
> David Fetter:
>
> > "We're using Postgre 8"
> >
> > See also all the flocks of tools that claim to support "Postgres 8"
>
> Flocks? Handful at best, and no reason we should be catering to
> their inaccuracies.
Depends on the goal.
* Tom Lane [100820 17:10]:
> BTW, 9.0.0 is also less than 9.0.0.anything ... so sticking another dot
> in there wouldn't help.
Debian's packaging versions "work around" this with the special ~
character, which they define as sorting *before* nothing, meaning
8.4~beta1 < 8.4 < 8.4.0 < 8.
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
David Wheeler:
> No idea what you mean by that, but generally it's a bad idea
> to switch from dotted-integer version numbers and numeric
> version numbers. See Perl (Quel dsastre!).
Yeah, I think Perl is a prime example of how NOT to handle
"David E. Wheeler" writes:
> On Aug 20, 2010, at 12:15 PM, Tom Lane wrote:
>> Well, I for one will fiercely resist adopting any such standard, because
>> it's directly opposite to the way that RPM will sort such version numbers.
> Which is how?
9.0.0 is less than 9.0.0anything. Unless you wire
* Tom Lane [100820 16:28]:
> Uh, no, the excitement is about this:
> http://git.postgresql.org/gitweb?p=postgresql-migration.git;a=shortlog;h=refs/tags/REL8_3_10
>
> There are a whole lot of commits listed there that have nothing to do
> with anything that ever happened on the 8.3 branch.
Sure
On Fri, Aug 20, 2010 at 4:27 PM, Tom Lane wrote:
> Max Bowsher writes:
>> On 20/08/10 21:08, Tom Lane wrote:
>>> I'm still confused as to why this results in such massive weirdness in
>>> the generated git history, though. If it simply caused an extra commit
>>> that adds the new file slightly e
On Fri, Aug 20, 2010 at 11:48:12AM -0700, David Wheeler wrote:
> On Aug 20, 2010, at 11:47 AM, David Fetter wrote:
>
> >> No idea what you mean by that, but generally it's a bad idea to
> >> switch from dotted-integer version numbers and numeric version
> >> numbers. See Perl (Quel désastre!).
> >
Max Bowsher writes:
> On 20/08/10 21:08, Tom Lane wrote:
>> I'm still confused as to why this results in such massive weirdness in
>> the generated git history, though. If it simply caused an extra commit
>> that adds the new file slightly earlier than the commit we think of as
>> adding the file
> In principle we don't need to sharelock the referencing row in either
> update in this example, since the original row version is still there.
> The problem is to know that, given the limited amount of information
> available when performing the second update.
Ah, ok. I get it now.
Now to fig
I wrote:
> In principle we don't need to sharelock the referencing row in either
> update in this example, since the original row version is still there.
s/referencing/referenced/ ... sorry bout that ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hac
On Fri, Aug 20, 2010 at 07:59:55PM +0100, Greg Stark wrote:
> On Fri, Aug 20, 2010 at 7:34 PM, David Fetter wrote:
> > +1 for three-number versions...well, until we really see the light
> > and go to two-number versions. 8.3 and 8.4 are different enough
> > that they shouldn't even mildly appear
On 20/08/10 21:08, Tom Lane wrote:
> Max Bowsher writes:
>>> On Fri, Aug 20, 2010 at 20:52, Tom Lane wrote:
If I understand Max's statements correctly, there is an observable
problem in the actual git history, not just the commit log entries:
it will believe that a file added on a
Max Bowsher writes:
>> On Fri, Aug 20, 2010 at 20:52, Tom Lane wrote:
>>> If I understand Max's statements correctly, there is an observable
>>> problem in the actual git history, not just the commit log entries:
>>> it will believe that a file added on a branch had been there since
>>> the branc
20.Ağu.2010 tarihinde 23:03 saatinde, Josh Berkus
şunları yazdı:
The betas are pre-.0. Maybe we should have 9.0.(-3) instead. Or
8.9.97?
;-)
This is pretty much what Fedora does actually :-)
--
Devrim GÜNDÜZ
PostgreSQL DBA @ Akinon/Markafoni, Red Hat Certified Engineer
devrim~gunduz.o
> Yes, well, it's still implicit, isn't it?
But the last .0 in 9.0.0 is the patch level, effectively. This makes
that .0 inappropriate for betas; the beta number is the patch level,
i.e. 9.0.beta4. It doesn't make any sense to have a 9.0.0beta4, since
we're never going to have a 9.0.2beta4.
Th
On Fri, Aug 20, 2010 at 7:57 PM, Joel Jacobson wrote:
> OK. Thanks for the explanation. It's probably the case in general, but in
> all of my tests (>10), process 2 always aborts. I don't think it is
> arbitrary in this example, or could it be?
Well, note the part where I said "if it does other s
"David E. Wheeler" wrote:
>>> .0 is for releases, not betas. I see no need for an extra
>>> number in beta versions.
>
> Yes, well, it's still implicit, isn't it?
Not the way I read it. If we had a development cycle which resulted
in 8.4.5beta4, then you would have a point. We don't.
Now
Josh Berkus writes:
> Hmmm. It seems to me that we'd need a sharelock on the referenced row
> both times.
No, we don't. The first update knows that it's updating a pre-existing
referencing row and not changing the FK value. If someone were to try
to delete the referenced row, they would see th
* David E. Wheeler (da...@kineticode.com) wrote:
> On Aug 20, 2010, at 12:21 PM, Devrim GÜNDÜZ wrote:
>
> > +1 for Tom's post.
> >
> > 20.Ağu.2010 tarihinde 21:40 saatinde, Tom Lane şunları
> > yazdı:
> >
> >> .0 is for releases, not betas. I see no need for an extra number in
> >> beta versi
Steven Schlansker writes:
> On Aug 19, 2010, at 3:24 PM, Tom Lane wrote:
>> We generally assume that in server-safe encodings, the ctype.h functions
>> will behave sanely on any single-byte value. You can argue the wisdom
>> of that, but deciding to change that policy would be a rather massive
>>
Tatsuo Ishii writes:
>> We generally assume that in server-safe encodings, the ctype.h functions
>> will behave sanely on any single-byte value.
> I think this "wisedom" is only true for C locale. I'm not surprised
> all that it does not work with non C locales.
> From array_funcs.c:
>
On Aug 20, 2010, at 12:21 PM, Devrim GÜNDÜZ wrote:
> +1 for Tom's post.
>
> 20.Ağu.2010 tarihinde 21:40 saatinde, Tom Lane şunları
> yazdı:
>
>> .0 is for releases, not betas. I see no need for an extra number in
>> beta versions.
Yes, well, it's still implicit, isn't it?
David
--
Sent
On Fri, Aug 20, 2010 at 21:22, Max Bowsher wrote:
> On 20/08/10 19:54, Magnus Hagander wrote:
>> On Fri, Aug 20, 2010 at 20:52, Tom Lane wrote:
>>> Magnus Hagander writes:
In fact, is the only thing that's wrong here the commit message?
Because it's probably trivial to just patch that
20.Ağu.2010 tarihinde 21:47 saatinde, David Fetter
şunları yazdı:
The current system give people the completely false impression that
7.0 and 7.4 are somehow similar.
Well, I do find PostgreSQL versioning policy very good, which is
pretty much similar to Linux. For me, 7.x are similar. Reme
Optimized away, check, OK, but why? Because there is no new data in the FK
(table A) at the point of the first update of table B in process 2? But when
process 1 updates A, the FK B->A points to new data, which leads to process
2 tries to acquire a sharelock, which is not granted due to the update
+1 for Tom's post.
--
Devrim GÜNDÜZ
PostgreSQL DBA @ Akinon/Markafoni, Red Hat Certified Engineer
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
20.Ağu.2010 tarihinde 21:40 saatinde, Tom Lane
şunları yazdı:
> It *is* allowed to, and in fact has already done so. The problem is
> that it now needs a sharelock on the referenced row in order to ensure
> that the FK constraint remains satisfied, ie, nobody deletes the
> referenced row before we commit the update. In the general case where
> the referenc
On Aug 20, 2010, at 12:15 PM, Tom Lane wrote:
>> No, I mean 9.0.0beta4. If we were to adopt the Semantic Versioning spec, one
>> would *always* use X.Y.Z, with optional ASCII characters appended to Z to
>> add meaning (including "less than unadorned Z).
>
> Well, I for one will fiercely resist
"David E. Wheeler" writes:
> On Aug 20, 2010, at 12:02 PM, Greg Stark wrote:
>> So I count three integers in both 9.0rc1 and 9.0beta4
> No, I mean 9.0.0beta4. If we were to adopt the Semantic Versioning spec, one
> would *always* use X.Y.Z, with optional ASCII characters appended to Z to add
>
Joel Jacobson writes:
> I fully agree it must obtain a sharelock on the FK, but I cannot understand
> why it is granted it the first time, but not the second time?
It *isn't* granted it the first time, because it doesn't try to acquire
it the first time. That FK check gets optimized away, while
On Aug 20, 2010, at 12:02 PM, Greg Stark wrote:
>> Again, it means the format would be consistent. Always three integers. Nice
>> thing about Semantic Versions is that if you append any ASCII string to the
>> third integer, it automatically means "less than that integer".
>>
>
> So I count thr
On Fri, Aug 20, 2010 at 7:42 PM, David E. Wheeler wrote:
> Again, it means the format would be consistent. Always three integers. Nice
> thing about Semantic Versions is that if you append any ASCII string to the
> third integer, it automatically means "less than that integer".
>
So I count thr
Process 1 updates A in its transaction, which is still going on when process
2 updates B, requiring a sharelock on A, which it is granted. But when
process 2 does its second update of B, also of course requiring a sharelock
on A, it is not granted.
I fully agree it must obtain a sharelock on the F
Josh Berkus wrote:
> That's correct. This is the generic example I was talking about
> earlier on -hackers. I'm not certain it's a bug per spec; I
> wanted to talk through with Kevin what we *should* be doing in
> this situation.
I'm certainly happy to address what impact the SSI patch will h
On Fri, Aug 20, 2010 at 7:34 PM, David Fetter wrote:
> +1 for three-number versions...well, until we really see the light and
> go to two-number versions. 8.3 and 8.4 are different enough that they
> shouldn't even mildly appear the same, for example.
You realize if we did that 9.0 would be vers
OK. Thanks for the explanation. It's probably the case in general, but in
all of my tests (>10), process 2 always aborts. I don't think it is
arbitrary in this example, or could it be?
2010/8/20 Greg Stark
> On Fri, Aug 20, 2010 at 7:38 PM, Joel Jacobson
> wrote:
> > If the locking logic would
On Fri, Aug 20, 2010 at 7:38 PM, Joel Jacobson wrote:
> If the locking logic would be modified to allow process 2 to go through, and
> instead abort process 1, I understand some other scenarios would of course
> be affected, where the situation would be handled in a less optimal way.
Which proces
On Fri, Aug 20, 2010 at 20:52, Tom Lane wrote:
> Magnus Hagander writes:
>> In fact, is the only thing that's wrong here the commit message?
>> Because it's probably trivial to just patch that away.. Hmm, but i
>> guess we'd like to hav ethe actual commit message and not just another
>> fixed one
Magnus Hagander writes:
> In fact, is the only thing that's wrong here the commit message?
> Because it's probably trivial to just patch that away.. Hmm, but i
> guess we'd like to hav ethe actual commit message and not just another
> fixed one..
If I understand Max's statements correctly, there
Joel Jacobson writes:
> I don't understand exactly why this deadlock occurs, but the one thing I
> cannot understand is why process 2 is not allowed to update the same row,
> which it has already updated in the same transaction.
It *is* allowed to, and in fact has already done so. The problem is
On Aug 20, 2010, at 11:47 AM, David Fetter wrote:
>> No idea what you mean by that, but generally it's a bad idea to
>> switch from dotted-integer version numbers and numeric version
>> numbers. See Perl (Quel désastre!).
>
> I'm thinking that after 9.0, the first release of the next major
> vers
On Fri, Aug 20, 2010 at 11:36:55AM -0700, David Wheeler wrote:
> On Aug 20, 2010, at 11:34 AM, David Fetter wrote:
>
> > +1 for three-number versions...well, until we really see the light
> > and go to two-number versions. 8.3 and 8.4 are different enough
> > that they shouldn't even mildly appea
> Another question, Tom referred to a comment in
> src/backend/command/trigger.c.
> My example does not contain any triggers, nor insert commands. Is the
> trigger.c-comment still relevant or is it a misunderstanding?
It's relevant for how the FKs are handled.
--
On Aug 20, 2010, at 11:40 AM, Tom Lane wrote:
> "David E. Wheeler" writes:
>> A while ago, I asked if .0 releases could be versioned with three
>> digits instead of two. That is, it would be "8.4.0" instead of "8.4".
>
> We've been doing that for some time, no? A quick look at the CVS
> histor
"David E. Wheeler" writes:
> A while ago, I asked if .0 releases could be versioned with three
> digits instead of two. That is, it would be "8.4.0" instead of "8.4".
We've been doing that for some time, no? A quick look at the CVS
history shows that 8.0.0 and up were tagged that way.
> This is
In my example,
Process 1:Process 2:
BEGIN;
SELECT pg_backend_pid();
BEGIN;
SELECT
pg_backend_pid();
UPDATE A SET Col1 = 1 WHERE AID = 1;
SELECT * FROM vLo
On Aug 20, 2010, at 11:34 AM, David Fetter wrote:
> +1 for three-number versions...well, until we really see the light and
> go to two-number versions. 8.3 and 8.4 are different enough that they
> shouldn't even mildly appear the same, for example.
No idea what you mean by that, but generally it
On 8/20/10 8:23 AM, Marko Tiikkaja wrote:
> On 2010-08-20 6:19 PM, Kevin Grittner wrote:
>> Marko Tiikkaja wrote:
>>
>>> I think truly serializable transactions still need to SELECT FOR
>>> SHARE here for foreign keys to work, no?
>>
>> That depends on how you look at it. The SSI patch that Dan a
On Fri, Aug 20, 2010 at 11:12:56AM -0700, David Wheeler wrote:
> Hackers,
>
> A while ago, I asked if .0 releases could be versioned with three
> digits instead of two. That is, it would be "8.4.0" instead of
> "8.4". This is to make the format consistent with maintenance
> releases ("8.4.1", etc.
Max Bowsher writes:
> My guess at this point is that there may be a (very old?) version of cvs
> which, when adding a file to a branch, actually misrecorded the file as
> having existed on the branch from the moment it was first added to trunk
> - this would explain this anomaly.
I have no idea w
On 8/20/10 7:18 AM, Tom Lane wrote:
> It does go through without any deadlock, *if* there is no foreign key
> involved. You didn't tell us exactly what the FK relationship is, but
> I suspect the reason for the deadlock is that one process is trying to
> update a row that references some row alrea
I've been poking into bug #5626,
http://archives.postgresql.org/pgsql-bugs/2010-08/msg00291.php
What's basically going on here is:
1. User tried to suppress the public schema from the restore list.
2. Since almost everything in the dump depends on the public schema,
pg_restore skipped over most of
Hackers,
A while ago, I asked if .0 releases could be versioned with three digits
instead of two. That is, it would be "8.4.0" instead of "8.4". This is to make
the format consistent with maintenance releases ("8.4.1", etc.). I thought this
was generally agreed upon, but maybe not, because I ju
On Fri, Aug 20, 2010 at 19:56, Max Bowsher wrote:
> On 20/08/10 18:43, Magnus Hagander wrote:
>> On Fri, Aug 20, 2010 at 19:41, Max Bowsher wrote:
>>> On 20/08/10 18:30, Magnus Hagander wrote:
On Fri, Aug 20, 2010 at 19:28, Tom Lane wrote:
> Max Bowsher writes:
>> The history that
On Fri, Aug 20, 2010 at 19:41, Max Bowsher wrote:
> On 20/08/10 18:30, Magnus Hagander wrote:
>> On Fri, Aug 20, 2010 at 19:28, Tom Lane wrote:
>>> Max Bowsher writes:
The history that cvs2svn is aiming to represent here is this:
>>>
1) At the time of creation of the REL8_4_STABLE bran
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of jue ago 19 23:35:06 -0400 2010:
>> While I don't care for having smgr.c call tablespace.c, moving the call to
>> md.c instead is surely not an improvement :-(. The problem here is that
>> we'd like the tablespace code to be above the sm
On Fri, Aug 20, 2010 at 19:28, Tom Lane wrote:
> Max Bowsher writes:
>> The history that cvs2svn is aiming to represent here is this:
>
>> 1) At the time of creation of the REL8_4_STABLE branch, plperl_opmask.pl
>> did *not* exist.
>
>> 2) Later, it was added to trunk.
>
>> 3) Then, someone retro
Max Bowsher writes:
> The history that cvs2svn is aiming to represent here is this:
> 1) At the time of creation of the REL8_4_STABLE branch, plperl_opmask.pl
> did *not* exist.
> 2) Later, it was added to trunk.
> 3) Then, someone retroactively added the branch tag to the file, marking
> it as
Excerpts from Tom Lane's message of jue ago 19 23:35:06 -0400 2010:
> Robert Haas writes:
> > So I propose moving the TablespaceCreateDbspace() call to mdcreate(),
> > removing the redundant check from smgrcreate(), and deleting that
> > portion of the comment which says this is in the wrong place
Greg Stark wrote:
> Josh Berkus wrote:
>> update session where id = X;
>>update order where orderid = 5;
>> update order where orderid = 5;
>
> So i think this will already deadlock.
>
> A has a exclusive-lock on session and is waiting on order<5>. B
> has an exclusive l
On Thu, Aug 19, 2010 at 11:51 PM, Josh Berkus wrote:
> update session where id = X;
> update order where orderid = 5;
> update order where orderid = 5;
So i think this will already deadlock.
A has a exclusive-lock on session and is waiting on order<5>. B has
an exclusive l
On Fri, 2010-08-20 at 14:47 +0100, Dave Page wrote:
> On Fri, Aug 20, 2010 at 2:36 PM, Robert Haas wrote:
> > On Fri, Aug 20, 2010 at 9:28 AM, Magnus Hagander
> > wrote:
> >> I believe Robert had some comments/questions as well :-)
> >
> > What Magnus means is that I'm a grumpy old developer who
On Fri, 2010-08-20 at 09:36 -0400, Robert Haas wrote:
> On Fri, Aug 20, 2010 at 9:28 AM, Magnus Hagander wrote:
> > I believe Robert had some comments/questions as well :-)
>
> What Magnus means is that I'm a grumpy old developer who complains
> about everything.
+1
JD
--
PostgreSQL.org Major
Hm, in my example, there are no INSERTs in the two conflicting transactions?
The suggestion on adding an ON INSERT trigger would have no effect as far as
I can see.
The comment from trigger.c is also about INSERT, can't see how it affects
us.
I don't understand exactly why this deadlock occurs, bu
On 2010-08-20 6:19 PM, Kevin Grittner wrote:
Marko Tiikkaja wrote:
I think truly serializable transactions still need to SELECT FOR
SHARE here for foreign keys to work, no?
That depends on how you look at it. The SSI patch that Dan and I
have been working on doesn't attempt to change the im
1 - 100 of 145 matches
Mail list logo
