Robert Haas robertmh...@gmail.com 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.
While I don't care for having smgr.c call
On Aug 19, 2010, at 3:24 PM, Tom Lane wrote:
Steven Schlansker ste...@trumpet.io writes:
I'm not at all experienced with character encodings so I could
be totally off base, but isn't it wrong to ever call isspace(0x85),
whatever the result may be, given that the actual character is 0xCF85?
On Aug 19, 2010, at 2:35 PM, Tom Lane wrote:
Steven Schlansker ste...@trumpet.io writes:
I'm having a rather annoying problem - a particular string is causing the
Postgres COPY functionality to lose a byte, causing data corruption in
backups and transferred data.
I was able to reproduce
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Aug 19, 2010 at 08:36:09PM +0300, Heikki Linnakangas wrote:
[...]
Hmm, will need to think about a suitable API for that. The nice thing would
be that we could implement it using pselect() where available. (And
reliable - the Linux
On 8/19/10 3:51 PM, Josh Berkus wrote:
Kevin,
This one is for you:
Two sessions, in transaction:
Process A Process B
update session where id = X;
update order where orderid = 5;
update order where orderid = 5;
update order
On 20 August 2010 09:39, Josh Berkus j...@agliodbs.com wrote:
On 8/19/10 3:51 PM, Josh Berkus wrote:
Kevin,
This one is for you:
Two sessions, in transaction:
Process A Process B
update session where id = X;
update order where orderid = 5;
update order
On 2010-08-20 11:39 AM +0300, Josh Berkus wrote:
On 8/19/10 3:51 PM, Josh Berkus wrote:
Two sessions, in transaction:
Process A Process B
update session where id = X;
update order where orderid = 5;
update order where orderid = 5;
On Fri, Aug 20, 2010 at 01:01, Quan Zongliang quanzongli...@gmail.com wrote:
Because Windows's CreateService has serial start-type:
SERVICE_AUTO_START
SERVICE_BOOT_START
SERVICE_DEMAND_START
SERVICE_DISABLED
SERVICE_SYSTEM_START
Although all of them are not useful for pg service.
I think
Hey all,
Accordingly to the documentation of libpq, SQLSTATE code field is not
localizable, and
is always present.. But it seems, in some cases it isn't. E.g.
/* the main code */
PGresult* res = Pg::PQexec(conn, select 1);
Oid id = PQparamtype(res, 1);
/* the notice receiver */
void
On Fri, Aug 20, 2010 at 09:49, Max Bowsher m...@f2s.com wrote:
On 19/08/10 10:35, Magnus Hagander wrote:
On Thu, Aug 19, 2010 at 07:00, Michael Haggerty mhag...@alum.mit.edu wrote:
Magnus Hagander wrote:
Is there some way to make cvs2git work this way, and just not bother
even trying to
This code-pattern appears many times in pgstatfuncs.c:
Datum
pg_stat_get_blocks_fetched(PG_FUNCTION_ARGS)
{
Oid relid = PG_GETARG_OID(0);
int64 result;
PgStat_StatTabEntry *tabentry;
if ((tabentry = pgstat_fetch_stat_tabentry(relid))
On Fri, Aug 20, 2010 at 13:50, Max Bowsher m...@f2s.com wrote:
On 20/08/10 12:02, Magnus Hagander wrote:
On Fri, Aug 20, 2010 at 09:49, Max Bowsher m...@f2s.com wrote:
On 19/08/10 10:35, Magnus Hagander wrote:
On Thu, Aug 19, 2010 at 07:00, Michael Haggerty mhag...@alum.mit.edu
wrote:
On 20 August 2010 12:46, Magnus Hagander mag...@hagander.net wrote:
This code-pattern appears many times in pgstatfuncs.c:
Datum
pg_stat_get_blocks_fetched(PG_FUNCTION_ARGS)
{
Oid relid = PG_GETARG_OID(0);
int64 result;
PgStat_StatTabEntry
Josh Berkus wrote:
Two sessions, in transaction:
Process AProcess B
update session where id = X;
update order where orderid = 5;
update order where orderid = 5;
update order where orderid = 5;
... deadlock error.
Johto on IRC pointed out I left
On Fri, Aug 20, 2010 at 3:43 AM, Robert Haas robertmh...@gmail.com wrote:
A related, interesting question is whether there's any purpose to the
smgr layer at all. Would we accept a patch that implemented an
alternative smgr layer, perhaps on a per-tablespace basis?
I definitely want to keep
Attached is a patch that adds columns to pg_stat_*_tables for number
of [auto]vacuum and [auto]analyze runs on a table, completing the
current one that just had the last time these ran. It's particularly
useful to see how much autovac is doing on the tables, but I included
the counts of regular
On 20/08/10 15:45, Greg Stark wrote:
On Fri, Aug 20, 2010 at 3:43 AM, Robert Haasrobertmh...@gmail.com wrote:
A related, interesting question is whether there's any purpose to the
smgr layer at all. Would we accept a patch that implemented an
alternative smgr layer, perhaps on a
On Fri, Aug 20, 2010 at 14:11, Max Bowsher m...@f2s.com wrote:
On 20/08/10 12:55, Magnus Hagander wrote:
On Fri, Aug 20, 2010 at 13:50, Max Bowsher m...@f2s.com wrote:
I have run cvs2git on the pgsql module of your CVS locally (is that the
right thing to convert?) if you'd like to compare
Magnus Hagander mag...@hagander.net writes:
This code-pattern appears many times in pgstatfuncs.c:
Datum
pg_stat_get_blocks_fetched(PG_FUNCTION_ARGS)
{
Oid relid = PG_GETARG_OID(0);
int64 result;
PgStat_StatTabEntry *tabentry;
if
On 19/08/10 20:59, Tom Lane wrote:
Offhand I'd suggest something like
SetSleepInterrupt() -- called by signal handlers, writes pipe
ClearSleepInterrupt() -- called by sleep-and-do-something loops, clears pipe
pg_usleep() itself remains the same, but it is now guaranteed to return
On Fri, Aug 20, 2010 at 15:10, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
This code-pattern appears many times in pgstatfuncs.c:
Datum
pg_stat_get_blocks_fetched(PG_FUNCTION_ARGS)
{
Oid relid = PG_GETARG_OID(0);
int64
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Hmm, we have pg_usleep() calls in some fairly low-level functions, like
mdunlink() and s_lock(). If someone has called SetSleepInterrupt(), we
don't want those pg_usleep()s to return immediately. And pg_usleep() is
used in some
Magnus Hagander mag...@hagander.net writes:
I see your answer as no, not really any reason, but also not worth
changing, which is fine by me :-)
Yeah, that's a fair summary. If it had been coded the other way
to start with, I'd also say it wasn't worth changing, at least
not until such time as
On Thu, Aug 19, 2010 at 11:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
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 smgr code, not below.
Calling
On Fri, Aug 20, 2010 at 15:04, Magnus Hagander mag...@hagander.net wrote:
On Fri, Aug 20, 2010 at 14:11, Max Bowsher m...@f2s.com wrote:
On 20/08/10 12:55, Magnus Hagander wrote:
On Fri, Aug 20, 2010 at 13:50, Max Bowsher m...@f2s.com wrote:
I have run cvs2git on the pgsql module of your CVS
On Fri, Aug 20, 2010 at 8:45 AM, Greg Stark gsst...@mit.edu wrote:
On Fri, Aug 20, 2010 at 3:43 AM, Robert Haas robertmh...@gmail.com wrote:
A related, interesting question is whether there's any purpose to the
smgr layer at all. Would we accept a patch that implemented an
alternative smgr
On Fri, Aug 20, 2010 at 15:27, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
I see your answer as no, not really any reason, but also not worth
changing, which is fine by me :-)
Yeah, that's a fair summary. If it had been coded the other way
to start with,
Robert Haas robertmh...@gmail.com writes:
... Perhaps tablespace.c shouldn't assume
anything about the underlying filesystem representation and that
knowledge should be moved somewhere under src/backend/storage, but I
don't see how it makes sense for the smgr layer to include assumptions
I wrote:
I don't see how SSI can be modified to generate some other form of
serialization failure here, but I'm always open to suggestions.
Actually, after thinking about it a bit more, the UPDATE statements
*do* read the rows before writing, so a naive implementation would
see write skew in
On Fri, Aug 20, 2010 at 9:28 AM, Magnus Hagander mag...@hagander.net 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 stuff like this:
(Magnus and pghackers, I've included you in this email, since it appears to
be PostgreSQL bug. The example below is general, and not specific to Glue
Finance database model. Feel free to share it with anyone.)
I've just tried to replicate the deadlock in 8.4.4 and 9.0b4.
Same problem in both
On Fri, Aug 20, 2010 at 2:36 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Aug 20, 2010 at 9:28 AM, Magnus Hagander mag...@hagander.net 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.
Magnus Hagander mag...@hagander.net writes:
Attached is a patch that adds columns to pg_stat_*_tables for number
of [auto]vacuum and [auto]analyze runs on a table, completing the
current one that just had the last time these ran. It's particularly
useful to see how much autovac is doing on the
On 20/08/10 16:30, Robert Haas wrote:
I really like the idea of trying to use network-based storage in some
way. Gigabit Ethernet is a big I/O channel.
NFS?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list
On Fri, Aug 20, 2010 at 9:51 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 20/08/10 16:30, Robert Haas wrote:
I really like the idea of trying to use network-based storage in some
way. Gigabit Ethernet is a big I/O channel.
NFS?
I don't particularly trust NFS to be
On 20/08/10 16:24, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
Hmm, we have pg_usleep() calls in some fairly low-level functions, like
mdunlink() and s_lock(). If someone has called SetSleepInterrupt(), we
don't want those pg_usleep()s to return immediately.
Joel Jacobson j...@gluefinance.com writes:
a) both processes have been granted a RowExclusiveLock on table B. How can
both be granted a RowExclusiveLock on the same table? Since the table only
contains one row, it must be a lock on the same row, which should be
impossible, right?
This
On 20/08/10 17:01, Robert Haas wrote:
On Fri, Aug 20, 2010 at 9:51 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 20/08/10 16:30, Robert Haas wrote:
I really like the idea of trying to use network-based storage in some
way. Gigabit Ethernet is a big I/O channel.
NFS?
[ It's way past time to change the thread title ]
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 20/08/10 16:24, Tom Lane wrote:
You keep on proposing solutions that only work for walsender :-(.
Well yes, the other places where we use pg_usleep() are not really a
problem
Tom Lane t...@sss.pgh.pa.us wrote:
You didn't tell us exactly what the FK relationship is
The original post has an attachment with a self-contained example,
starting with table creation.
I suspect the reason for the deadlock is that one process is
trying to update a row that references
On Fri, Aug 20, 2010 at 10:20 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 20/08/10 17:01, Robert Haas wrote:
On Fri, Aug 20, 2010 at 9:51 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 20/08/10 16:30, Robert Haas wrote:
I really like the idea
2010/8/19 KaiGai Kohei kai...@ak.jp.nec.com:
(2010/08/20 11:45), Robert Haas wrote:
2010/8/19 KaiGai Koheikai...@ak.jp.nec.com:
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
On 20/08/10 12:55, Magnus Hagander wrote:
On Fri, Aug 20, 2010 at 13:50, Max Bowsher m...@f2s.com wrote:
I have run cvs2git on the pgsql module of your CVS locally (is that the
right thing to convert?) if you'd like to compare notes on specific
parts of the conversion.
Correct, that's the
On 19/08/10 10:35, Magnus Hagander wrote:
On Thu, Aug 19, 2010 at 07:00, Michael Haggerty mhag...@alum.mit.edu wrote:
Magnus Hagander wrote:
Is there some way to make cvs2git work this way, and just not bother
even trying to create merge commits, or is that fundamentally
impossible and we
On 20/08/10 12:02, Magnus Hagander wrote:
On Fri, Aug 20, 2010 at 09:49, Max Bowsher m...@f2s.com wrote:
On 19/08/10 10:35, Magnus Hagander wrote:
On Thu, Aug 19, 2010 at 07:00, Michael Haggerty mhag...@alum.mit.edu
wrote:
Magnus Hagander wrote:
Is there some way to make cvs2git work this
Dmitriy Igrishin escreveu:
/* NOT presents - NULL. Why not 0 ? */
const char* sqlstate = Pg::PQresultErrorField(res, PG_DIAG_SQLSTATE);
That's because the protocol doesn't set error field when the command
succeeded. IMHO it's an oversight (the documentation is correct but the code
is
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi 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 implementation
Kevin Grittner kevin.gritt...@wicourts.gov writes:
The surprising thing is that a particular row is (using the
identifiers from the attachment):
Process 2 updates a particular row without blocking.
Process 1 updates the same row, which blocks.
Process 2 updates the same row again (with
On 2010-08-20 6:19 PM, Kevin Grittner wrote:
Marko Tiikkajamarko.tiikk...@cs.helsinki.fi 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
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,
On Fri, 2010-08-20 at 09:36 -0400, Robert Haas wrote:
On Fri, Aug 20, 2010 at 9:28 AM, Magnus Hagander mag...@hagander.net 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
--
On Fri, 2010-08-20 at 14:47 +0100, Dave Page wrote:
On Fri, Aug 20, 2010 at 2:36 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Aug 20, 2010 at 9:28 AM, Magnus Hagander mag...@hagander.net
wrote:
I believe Robert had some comments/questions as well :-)
What Magnus means is that
On Thu, Aug 19, 2010 at 11:51 PM, Josh Berkus j...@agliodbs.com 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 sessionX and is waiting on order5. B has
Greg Stark gsst...@mit.edu wrote:
Josh Berkus j...@agliodbs.com 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 sessionX and is waiting on order5. B
Excerpts from Tom Lane's message of jue ago 19 23:35:06 -0400 2010:
Robert Haas robertmh...@gmail.com 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
Max Bowsher m...@f2s.com 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
On Fri, Aug 20, 2010 at 19:28, Tom Lane t...@sss.pgh.pa.us wrote:
Max Bowsher m...@f2s.com 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)
Alvaro Herrera alvhe...@commandprompt.com 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
On Fri, Aug 20, 2010 at 19:41, Max Bowsher m...@f2s.com wrote:
On 20/08/10 18:30, Magnus Hagander wrote:
On Fri, Aug 20, 2010 at 19:28, Tom Lane t...@sss.pgh.pa.us wrote:
Max Bowsher m...@f2s.com writes:
The history that cvs2svn is aiming to represent here is this:
1) At the time of creation
On Fri, Aug 20, 2010 at 19:56, Max Bowsher m...@f2s.com wrote:
On 20/08/10 18:43, Magnus Hagander wrote:
On Fri, Aug 20, 2010 at 19:41, Max Bowsher m...@f2s.com wrote:
On 20/08/10 18:30, Magnus Hagander wrote:
On Fri, Aug 20, 2010 at 19:28, Tom Lane t...@sss.pgh.pa.us wrote:
Max Bowsher
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 just
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
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 already
Max Bowsher m...@f2s.com 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
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.). I
On 8/20/10 8:23 AM, Marko Tiikkaja wrote:
On 2010-08-20 6:19 PM, Kevin Grittner wrote:
Marko Tiikkajamarko.tiikk...@cs.helsinki.fi 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
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's
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
David E. Wheeler da...@kineticode.com 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
On Aug 20, 2010, at 11:40 AM, Tom Lane wrote:
David E. Wheeler da...@kineticode.com 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
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 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 appear the
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
version
Joel Jacobson j...@gluefinance.com 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
Magnus Hagander mag...@hagander.net 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
On Fri, Aug 20, 2010 at 20:52, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net 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
On Fri, Aug 20, 2010 at 7:38 PM, Joel Jacobson j...@gluefinance.com 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
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 gsst...@mit.edu
On Fri, Aug 20, 2010 at 7:38 PM, Joel Jacobson j...@gluefinance.com
On Fri, Aug 20, 2010 at 7:34 PM, David Fetter da...@fetter.org 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
Josh Berkus j...@agliodbs.com 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
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
On Fri, Aug 20, 2010 at 7:42 PM, David E. Wheeler da...@kineticode.com 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.
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 three integers
Joel Jacobson j...@gluefinance.com 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
David E. Wheeler da...@kineticode.com 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
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 adopting
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 referencing
+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
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
20.Ağu.2010 tarihinde 21:47 saatinde, David Fetter da...@fetter.org
ş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
On Fri, Aug 20, 2010 at 21:22, Max Bowsher m...@f2s.com wrote:
On 20/08/10 19:54, Magnus Hagander wrote:
On Fri, Aug 20, 2010 at 20:52, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
In fact, is the only thing that's wrong here the commit message?
Because it's
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 t...@sss.pgh.pa.us ş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
Tatsuo Ishii is...@sraoss.co.jp 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:
Steven Schlansker ste...@trumpet.io 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
* 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 t...@sss.pgh.pa.us şunları
yazdı:
.0 is for releases, not betas. I see no need for an extra number in
beta
Josh Berkus j...@agliodbs.com 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,
David E. Wheeler da...@kineticode.com 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
On Fri, Aug 20, 2010 at 7:57 PM, Joel Jacobson j...@gluefinance.com 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
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.
20.Ağu.2010 tarihinde 23:03 saatinde, Josh Berkus j...@agliodbs.com
ş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
1 - 100 of 146 matches
Mail list logo
