Kevin Grittner wrote:
> > What if there is an index on the "ishighlander" row?
> > Then an index scan would find only one candidate to examine,
> > and the other rows would not even be touched by the execution plan.
>
> I assume you're talking about this line of your function:
>
> SELECT coun
On May 7, 2009, at 12:32 PM, Tom Lane wrote:
Or we could try to make the user-visible locale names
platform-independent in the first place, a la David's not-silly-at-all
suggestion.
Actually, what I was thinking of was using a platform-independent
locale infrastructure: the inconsistency in
On Thu, 2009-05-07 at 22:47 +0100, Greg Stark wrote:
> On Thu, May 7, 2009 at 6:13 PM, Simon Riggs wrote:
> > Apologies Michael, I see that my mail did remove you. That was a
> > unconscious error; I was particularly interested in your comments
> > regarding my assessment of the algorithmic compl
Tom Lane wrote:
> 2. There seem to be some corner cases where creating a table in the new
> database will not create a toast table even though there was one in the
> previous instance. (I'm not 100% convinced that this can happen if we
> create and then drop dropped columns, for instance ... but I
On Win32, ShmemVariableCache needs PGDLLIMPORT for linkage of
pg_migrator.so. Patch attached and applied.
Tested by Hiroshi Saito.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be yo
All,
Here's a thank you note from one of our users.
--Josh Berkus
Original Message
Subject: congratulations on 8.4 beta
Date: Thu, 07 May 2009 17:59:58 -0700
From: Stan
To: j...@postgresql.org
This humble user is perpetually grateful to the PG team past and
present, both fo
Greg Smith writes:
> On Thu, 7 May 2009, Aidan Van Dyk wrote:
> You are correct here. Right now, pgbench is guaranteed to be running
> against a search_path with only one entry in it. If someone runs the new
> version against a configuration with something like:
> search_path='a,b,c,d,e,f,g,h
On Thu, 7 May 2009, Aidan Van Dyk wrote:
But by dropping the search_path, you're necessarily changing the catalog
comparisons and lookups anyways, because your now taking a "random"
search path to follow (which could have multiple entries in it) instead
of one guaranteed to be a single, useable
On Thu, May 7, 2009 at 11:08 PM, Kevin Grittner
wrote:
> I would assume that SELECT shown above would either resolve to a
> table scan, in which case you would have to have an SIREAD lock at the
> table level
That sounds like we're back to the MSSQL/Sybase way of doing things
where you have to un
Per discussion among pgsql-core and pgsql-packagers, we're going to
freeze 8.4beta2 at this time next week in preparation for releasing
it during PGCon. Let's try to get some of the open items cleaned up
before then ...
http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items
Greg Stark wrote:
> If I do something like "SELECT count(*) FROM tab WHERE
> complex_function(a,b) = 5"
>
> And then you "INSERT INTO tab (a,b) VALUES (1,2)". How would you
> store any record of the fact that there's a serialization failure
> iff complex_function(1,2)=5 in any way that lets yo
"Joshua D. Drake" writes:
> --- a/contrib/pgbench/pgbench.c
> +++ b/contrib/pgbench/pgbench.c
> @@ -357,8 +357,6 @@ doConnect(void)
> return NULL;
> }
>
> - executeStatement(conn, "SET search_path = public");
> -
> return conn;
> }
Applied along with chang
Greg Stark wrote:
> However on subsequent messages you attempted to re-add him but got
> his email address wrong. I assume everyone else got a bounce like I
> got?
Some of my emails are getting through; some not. I haven't figured
out why. I'm calling it "best effort" for now, and will send
On Thu, May 7, 2009 at 6:13 PM, Simon Riggs wrote:
> Apologies Michael, I see that my mail did remove you. That was a
> unconscious error; I was particularly interested in your comments
> regarding my assessment of the algorithmic complexity of the new theory
> and existing serialization technique
Simon Riggs wrote:
> Do we need full locking of everything we might
> touch, or tracking of what we have touched?
> If you need the "might touch" then you either need to implement
> locking that will effect everybody (which ain't ever gonna fly round
> here), or you implement a scheme that is
On Thu, May 7, 2009 at 6:31 PM, Simon Riggs wrote:
> Each user must compare against work performed by all other users. O(N).
>
> There are N users, so O(N^2).
i think this logic only works if you must scan every item for every
other user every time. If you have data structures like binary trees
o
Bernd Helmle writes:
> --On 7. Mai 2009 15:32:01 -0400 Tom Lane wrote:
>> I think the part that goes "en_US" or whatever is actually
>> quite well standardized (except for good ol' Windows, but we could
>> provide a mapping from the Unix-style names to Windows names).
> I like this idea, but i c
--On 7. Mai 2009 15:32:01 -0400 Tom Lane wrote:
I think the part that goes "en_US" or whatever is actually
quite well standardized (except for good ol' Windows, but we could
provide a mapping from the Unix-style names to Windows names).
I like this idea, but i could imagine that this is pre
On Thu, 2009-05-07 at 15:10 -0500, Kevin Grittner wrote:
> The assertion that
> there is some need for each session to wade through something for
> every other session seems baseless to me. I'm wondering what I might
> be missing.
That's Greg's point. Do we need full locking of everything we mig
Simon Riggs wrote:
> On Thu, 2009-05-07 at 12:39 -0500, Kevin Grittner wrote:
>> Simon Riggs wrote:
>>
>> > Each user must compare against work performed by all other users.
>> > O(N).
>> >
>> > There are N users, so O(N^2).
>>
>> Why does that apply here and not in the update conflict detec
On Thu, 2009-05-07 at 12:39 -0500, Kevin Grittner wrote:
> Simon Riggs wrote:
>
> > Each user must compare against work performed by all other users.
> O(N).
> >
> > There are N users, so O(N^2).
>
> Why does that apply here and not in the update conflict detection?
I think the shoe is on t
Magnus Hagander writes:
> Alvaro Herrera wrote:
>> (For text dumps, the only solution would be for the user to edit the
>> dump manually; perhaps provide a pg_dump switch to avoid dumping
>> locale config?).
> We have a pg_dump switch that sets the encoding. Perhaps we could have a
> pg_dump swit
Heikki Linnakangas writes:
> I just bumped into this:
[ scratches head ... ] It seems to be reordering the two joins,
which it's not supposed to do. Will look.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to y
I just bumped into this:
postgres=# CREATE TABLE atable (id int4);
CREATE TABLE
postgres=# CREATE TABLE btable (id int4);
CREATE TABLE
postgres=# INSERT INTO atable VALUES (1),(2),(3);
INSERT 0 3
postgres=# INSERT INTO btable VALUES (1),(2),(3),(1);
INSERT 0 4
postgres=# SELECT * FROM atable WHE
Alvaro Herrera wrote:
> Tom Lane wrote:
>
>> Actually, there's another issue that comes to mind here: since we are
>> relying on platform-dependent locale names, including those in the dump
>> is going to pose a severe problem for porting dumps across platforms
>> (where "different platform" could
Tom Lane wrote:
> Actually, there's another issue that comes to mind here: since we are
> relying on platform-dependent locale names, including those in the dump
> is going to pose a severe problem for porting dumps across platforms
> (where "different platform" could even mean "different libc rel
On May 7, 2009, at 10:18 AM, Tom Lane wrote:
Actually, there's another issue that comes to mind here: since we are
relying on platform-dependent locale names, including those in the
dump
is going to pose a severe problem for porting dumps across platforms
(where "different platform" could eve
Simon Riggs wrote:
On Thu, 2009-05-07 at 18:57 +0300, Heikki Linnakangas wrote:
I don't see any user error here.
Just observing that the error occurs because we rely on a file being
there when we haven't even documented that it needs to be there for it
to work. File deletion with %r from the a
Simon Riggs wrote:
> Each user must compare against work performed by all other users.
O(N).
>
> There are N users, so O(N^2).
Why does that apply here and not in the update conflict detection?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On Thu, 2009-05-07 at 10:56 -0500, Kevin Grittner wrote:
> > It's clear that any new-theory solution will cost significantly more
> > as the number of users increases, at least O(N^2), whereas simply
> > waiting is only O(N), AFAICS.
>
> I'm not following your reasoning on the O(N^2). Could you
On Thu, 2009-05-07 at 18:57 +0300, Heikki Linnakangas wrote:
> I don't see any user error here.
Just observing that the error occurs because we rely on a file being
there when we haven't even documented that it needs to be there for it
to work. File deletion with %r from the archive would not hav
I wrote:
> 1. pg_dumpall dumps CREATE DATABASE commands that include the source
> database's encoding, lc_collate, and lc_ctype settings ... but if
> dumping from a pre-8.4 server it just omits the lc_ settings. This
> is flat-out wrong (independently of pg_migrator). The correct behavior
> when
On Thu, 2009-05-07 at 11:15 -0500, Kevin Grittner wrote:
> Please keep Michael Cahill copied on this thread, per his request.
>
> I just noticed the omission on a few messages and will forward them to
> him.
Apologies Michael, I see that my mail did remove you. That was a
unconscious error; I
"Joshua D. Drake" writes:
> On Thu, 2009-05-07 at 12:58 -0400, Aidan Van Dyk wrote:
>> True enough... What about making the prefix be configurable, so by
>> default, it could be "pgbench_", it could be set to "" (to force it to
>> use old pgbench names) or set to "something." to get it to use a
>>
On Thu, 2009-05-07 at 09:53 -0700, Joshua D. Drake wrote:
> On Thu, 2009-05-07 at 12:47 -0400, Tom Lane wrote:
>
> > Well, pgbench has been coded this way since forever and we've only seen
> > this one report of trouble. Still, I can't object very hard to renaming
> > the tables to pgbench_accou
* Joshua D. Drake [090507 13:02]:
> On Thu, 2009-05-07 at 12:58 -0400, Aidan Van Dyk wrote:
>
> > True enough... What about making the prefix be configurable, so by
> > default, it could be "pgbench_", it could be set to "" (to force it to
> > use old pgbench names) or set to "something." to get
On Thu, 2009-05-07 at 12:58 -0400, Aidan Van Dyk wrote:
> True enough... What about making the prefix be configurable, so by
> default, it could be "pgbench_", it could be set to "" (to force it to
> use old pgbench names) or set to "something." to get it to use a
> different schema (noting that t
* Tom Lane [090507 12:53]:
> Aidan Van Dyk writes:
> > ... couldn't we just
> > make "new" pgbench refer to tables as . where is
> > "public"?
>
> I'd prefer not to do that because it changes the amount of parsing work
> demanded by the benchmark. Maybe not by enough to matter ... or maybe
> i
On Thu, 2009-05-07 at 12:47 -0400, Tom Lane wrote:
> Well, pgbench has been coded this way since forever and we've only seen
> this one report of trouble. Still, I can't object very hard to renaming
> the tables to pgbench_accounts etc --- it's a trivial change and the
> only thing it could break
Aidan Van Dyk writes:
> ... couldn't we just
> make "new" pgbench refer to tables as . where is
> "public"?
I'd prefer not to do that because it changes the amount of parsing work
demanded by the benchmark. Maybe not by enough to matter ... or maybe
it does. Adjusting the length of the identif
Simon Riggs writes:
> On Thu, 2009-05-07 at 11:14 -0400, Robert Haas wrote:
>>> We should check they are the correct tables before we just drop them.
>>> Perhaps check for the comment "Tables for pgbench application. Not
>>> production data" on the tables, which would be nice to add anyway.
>>
>>
* Robert Haas [090507 11:15]:
> I bet it would be just as good and a lot simpler to do what someone
> suggested upthread, namely s/^/pgbench_/
That has the "legacy compatibility" problem...
But seeing as "legacy" has a:
SET search_path TO public;
And uses plain in it's queries/create
Alvaro Herrera writes:
> Tom Lane wrote:
>> 2. There seem to be some corner cases where creating a table in the new
>> database will not create a toast table even though there was one in the
>> previous instance.
> Hmm, what about toast reloptions? They are not a problem now of course, but
> cou
Tom Lane wrote:
> 2. There seem to be some corner cases where creating a table in the new
> database will not create a toast table even though there was one in the
> previous instance. (I'm not 100% convinced that this can happen if we
> create and then drop dropped columns, for instance ... but
Please keep Michael Cahill copied on this thread, per his request.
I just noticed the omission on a few messages and will forward them to
him.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/
I was just talking to Bruce about his results from testing pg_migrator,
and we realized there are a couple of changes that we need to slip into
the core code before 8.4 goes final.
1. pg_dumpall dumps CREATE DATABASE commands that include the source
database's encoding, lc_collate, and lc_ctype se
Simon Riggs wrote:
> It wouldn't be 692 lines of code
Agreed. The original implementation was in an MVCC database which
already supported full serializability using strict 2 phase locking
and used page level locks. Both of these made the implementation
simpler than it would be in PostgreSQL.
Simon Riggs wrote:
On Thu, 2009-05-07 at 17:54 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
A more useful thing might be to do an xlog switch before we do the
shutdown checkpoint at end of recovery. That gives the same sequence of
actions without modifying the existing sequence of activi
On Thu, 2009-05-07 at 11:14 -0400, Robert Haas wrote:
> > We should check they are the correct tables before we just drop them.
> > Perhaps check for the comment "Tables for pgbench application. Not
> > production data" on the tables, which would be nice to add anyway.
>
> I bet it would be just
"Albe Laurenz" wrote:
> What if there is an index on the "ishighlander" row?
> Then an index scan would find only one candidate to examine,
> and the other rows would not even be touched by the execution plan.
I assume you're talking about this line of your function:
SELECT count(*) INTO
On Thu, May 7, 2009 at 10:12 AM, Simon Riggs wrote:
>
> On Wed, 2009-05-06 at 15:18 -0400, Tom Lane wrote:
>> "Dickson S. Guedes" writes:
>> > Em Qua, 2009-05-06 s 09:37 -0400, Tom Lane escreveu:
>> >> Seems like the right policy for that is "run pgbench in its own
>> >> database".
>>
>> > A text
On Thu, 2009-05-07 at 17:54 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Thu, 2009-05-07 at 12:15 +0300, Heikki Linnakangas wrote:
> >
> >> Yeah, I think you're right. If you omit pg_xlog from the base backup,
> >> as we recommend in the manual, and clear the old files from the
>
Simon Riggs wrote:
On Thu, 2009-05-07 at 12:15 +0300, Heikki Linnakangas wrote:
Yeah, I think you're right. If you omit pg_xlog from the base backup,
as we recommend in the manual, and clear the old files from the
archive too, then you won't have the old history file around.
...
A more useful
Kevin Grittner wrote:
> > Where does T1 select rows that were modified by T0? It selects only
> > one row, the one it modified itself, right?
>
> You have to select it to know whether to count it, right?
We are getting closer.
So an SIREAD lock is taken for every row that is examined during
the
Heikki Linnakangas wrote:
> Simon Riggs wrote:
>> It wouldn't be 692 lines of code and even if it were the impact of
>> that code would be such that it would need to be optional, since it
>> would differ in definition from an existing SQL Standard isolation
>> mode and it would have additional pe
"Albe Laurenz" wrote:
> Kevin Grittner wrote:
>> I do think you misunderstood. If there are two concurrent
>> executions and each reads one row, there will be an SIREAD lock for
>> each of those rows. As an example, let's say that one of them (T0)
>> updates its row and does its count, finds
Kevin Grittner wrote:
> > maybe I misunderstood something.
> >
> > Consider a function
> > "makehighlander(personid integer) RETURNS void"
> > defined like this:
> >
> >SELECT ishighlander INTO b FROM scots WHERE id=personid;
> >IF b THEN
> > RETURN; /* no need to do anything */
> >
On Wed, 2009-05-06 at 15:18 -0400, Tom Lane wrote:
> "Dickson S. Guedes" writes:
> > Em Qua, 2009-05-06 s 09:37 -0400, Tom Lane escreveu:
> >> Seems like the right policy for that is "run pgbench in its own
> >> database".
>
> > A text warning about this could be shown at start of pgbench if th
Gregory Stark wrote:
> "Albe Laurenz" writes:
>
>> So I think one would have to add intention locks for rows
>> considered in the WHERE clause to guarantee true serializability.
>
> Does the paper explain how to deal with rows "considered" in the
> WHERE clause which don't yet exist? Ie, "SELE
"Albe Laurenz" wrote:
> maybe I misunderstood something.
>
> Consider a function
> "makehighlander(personid integer) RETURNS void"
> defined like this:
>
>SELECT ishighlander INTO b FROM scots WHERE id=personid;
>IF b THEN
> RETURN; /* no need to do anything */
>END IF;
>
On Wed, May 6, 2009 at 9:04 AM, Dawid Kuroczko wrote:
> On Wed, May 6, 2009 at 7:22 AM, Asko Oja wrote:
>> It was just yesterday when i wondering why we don't have this feature (i was
>> trying to use it and it wasn't there :).
>> The group of people who think it's unsafe should not use the featu
higepon writes:
> But I don't understand this case.
> select * from emp where emp_no > 1;
> Is Bitmap Scan is faster than Index Scan in this case ?
Yes, very probably, if a lot of tuples are being retrieved. A bitmap
scan will fetch the tuples from the heap in a more or less optimal
fashion
Greg Stark wrote:
> > So I think one would have to add intention locks for rows considered
> > in the WHERE clause to guarantee true serializability.
>
> Does the paper explain how to deal with rows "considered" in the WHERE clause
> which don't yet exist? Ie, "SELECT count(*) WHERE foo" needs to
On Thu, 2009-05-07 at 12:15 +0300, Heikki Linnakangas wrote:
> Yeah, I think you're right. If you omit pg_xlog from the base backup,
> as we recommend in the manual, and clear the old files from the
> archive too, then you won't have the old history file around.
Sorry about this, but I don't agr
On Thu, 2009-05-07 at 15:26 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > It wouldn't be 692 lines of code and even if it were the impact of that
> > code would be such that it would need to be optional, since it would
> > differ in definition from an existing SQL Standard isolation mo
Simon Riggs wrote:
It wouldn't be 692 lines of code and even if it were the impact of that
code would be such that it would need to be optional, since it would
differ in definition from an existing SQL Standard isolation mode and it
would have additional performance implications.
I thought it w
Em Qui, 2009-05-07 às 10:11 +0300, Peter Eisentraut escreveu:
> On Thursday 07 May 2009 05:23:41 Dickson S. Guedes wrote:
> > This is a WIP patch (for the TODO item in the subject) that I'm putting
> > in the Commit Fest queue for 8.5.
>
> How about you just put the values in a variable and use th
On Tue, 2009-05-05 at 10:50 -0500, Kevin Grittner wrote:
> "This paper describes a modification to the concurrency control
> algorithm of a database management system that automatically detects
> and prevents snapshot isolation anomalies at runtime for arbitrary
> applications, thus providing ser
Michael Meskes wrote:
On Fri, May 01, 2009 at 03:49:47PM +0300, Heikki Linnakangas wrote:
ECPG constructs internal struct names for VARCHAR fields using the field
name and line number it's defined on. In a contrived example, though,
that's not unique. Consider the following example:
...
That
Hi Tom, hi all,
On 05/06/2009 11:43 PM, Tom Lane wrote:
Andres Freund writes:
As this is my first patch to PG I am happy with most sort of feedback.
Please add your patch to the commit-fest queue here:
http://wiki.postgresql.org/wiki/CommitFestInProgress
Will do so, after this email has arri
"Albe Laurenz" writes:
> So I think one would have to add intention locks for rows considered
> in the WHERE clause to guarantee true serializability.
Does the paper explain how to deal with rows "considered" in the WHERE clause
which don't yet exist? Ie, "SELECT count(*) WHERE foo" needs to tak
On Fri, May 01, 2009 at 03:49:47PM +0300, Heikki Linnakangas wrote:
> ECPG constructs internal struct names for VARCHAR fields using the field
> name and line number it's defined on. In a contrived example, though,
> that's not unique. Consider the following example:
> ...
> That hardly happens
Kevin Grittner wrote:
> While discussing potential changes to PostgreSQL documentation of
> transaction isolation levels, Emmanuel Cecchet pointed out an
> intriguing new paper[1] on a new algorithm to provide true
> serializable behavior in a MVCC based database, with no additional
> blocking; alt
On Wed, May 6, 2009 at 3:45 AM, Tom Lane wrote:
> Robert Haas writes:
>> 1. Why should it do nothing if the object already exists (as opposed
>> to any other alternative)?
>
>> Answer: Because that's what "CREATE IF NOT EXISTS" means when
>> interpreted as English.
>
> The argument was not about
On Thursday 07 May 2009 05:23:41 Dickson S. Guedes wrote:
> This is a WIP patch (for the TODO item in the subject) that I'm putting
> in the Commit Fest queue for 8.5.
How about you just put the values in a variable and use the existing facility
to put those variables in the prompt?
--
Sent via
75 matches
Mail list logo
