On 29/12/10 03:35, Peter Eisentraut wrote:
On tis, 2010-12-28 at 00:19 +, Peter Geoghegan wrote:
It's worth noting that officially (i.e. in the docs), we don't even
call CTEs CTEs at any point. We call them WITH queries. I think that
that's a mistake because we call them CTEs everywhere
On Tue, Dec 28, 2010 at 17:43, Guillaume Lelarge guilla...@lelarge.info wrote:
Le 28/12/2010 17:36, Tom Lane a écrit :
Guillaume Lelarge guilla...@lelarge.info writes:
Le 28/12/2010 16:34, Tom Lane a écrit :
1. It'll have to be restricted to superusers, therefore ordinary
users on the slave
On Tue, Dec 28, 2010 at 18:12, Robert Haas robertmh...@gmail.com wrote:
On Dec 28, 2010, at 10:34 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm still wondering what's the actual use-case for exposing this inside
SQL. Those with a legitimate need-to-know can look at the slave
server's config
On 29.12.2010 10:36, Magnus Hagander wrote:
On Tue, Dec 28, 2010 at 18:12, Robert Haasrobertmh...@gmail.com wrote:
Although maybe now that we've made recovery.conf use the GUC lexer we oughta
continue in that vein and expose those parameters as PGC_INTERNAL GUCs rather
than inventing a new
On 29.12.2010 06:54, Robert Haas wrote:
With the patch:
rhaas=# cluster v;
ERROR: views do not support CLUSTER
do not support sounds like a missing feature, rather than a
nonsensical command. How about something like CLUSTER cannot be used on
views
The patch changes a bunch of
On 2010-12-29 09:16, Mark Kirkwood wrote:
On 29/12/10 03:35, Peter Eisentraut wrote:
On tis, 2010-12-28 at 00:19 +, Peter Geoghegan wrote:
It's worth noting that officially (i.e. in the docs), we don't even
call CTEs CTEs at any point. We call them WITH queries. I think that
that's a
On Tue, Dec 28, 2010 at 13:05, Magnus Hagander mag...@hagander.net wrote:
On Mon, Dec 27, 2010 at 22:53, Magnus Hagander mag...@hagander.net wrote:
On Mon, Dec 27, 2010 at 22:42, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
Updated patch, still pending docs,
Would people be interested in putting pg_streamrecv
(http://github.com/mhagander/pg_streamrecv) in bin/ or contrib/ for
9.1? I think it would make sense to do so.
It could/should then also become the default tool for doing
base-backup-over-libpq, assuming me or Heikki (or somebody else)
finishes
On Wed, Dec 29, 2010 at 4:09 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 29.12.2010 06:54, Robert Haas wrote:
With the patch:
rhaas=# cluster v;
ERROR: views do not support CLUSTER
do not support sounds like a missing feature, rather than a nonsensical
command.
On Wed, Dec 29, 2010 at 5:47 AM, Magnus Hagander mag...@hagander.net wrote:
Would people be interested in putting pg_streamrecv
(http://github.com/mhagander/pg_streamrecv) in bin/ or contrib/ for
9.1? I think it would make sense to do so.
It could/should then also become the default tool for
On Wed, Dec 29, 2010 at 4:19 AM, Yeb Havinga yebhavi...@gmail.com wrote:
Also, the terms CTE and CTEScan appear in EXPLAIN output, it would be nice
to have a meaningful hit when looking for the term in the documentation
page, instead of 'Your search for cte returned no hits.'
This is an
Erik Rijkers wrote:
I get some whitespace-warnings, followed by error:
$ git apply
/home/rijkers/download/pgpatches/0091/merge/20101206/merge_204_2010DEC06.patch
/home/rijkers/download/pgpatches/0091/merge/20101206/merge_204_2010DEC06.patch:481:
trailing
whitespace.
Em 29-12-2010 07:47, Magnus Hagander escreveu:
Would people be interested in putting pg_streamrecv
(http://github.com/mhagander/pg_streamrecv) in bin/ or contrib/ for
9.1? I think it would make sense to do so.
+1 but...
It could/should then also become the default tool for doing
I did some basic testing of the latest update here, but quickly hit a
problem that wasn't in the previous version. Attached is the standalone
test script that used to work, but now fails like this:
psql:simple.sql:12: ERROR: the vars in merge action tlist of qual
should only belongs to the
On Mon, Dec 27, 2010 at 3:58 AM, Simon Riggs si...@2ndquadrant.com wrote:
I think the answer is that only the first column comparison is
optimised. Second and subsequent comparisons are not optimised.
What sort of optimization are you referring to here?
--
Robert Haas
EnterpriseDB:
On Tue, Dec 28, 2010 at 5:13 AM, Jie Li jay23j...@gmail.com wrote:
Hi,
Please see the following plan:
postgres=# explain select * from small_table left outer join big_table using
(id);
QUERY PLAN
On Wed, 2010-12-29 at 07:17 -0500, Robert Haas wrote:
Here I have a puzzle, why not choose the small table to build hash table? It
can avoid multiple batches thus save significant I/O cost, isn't it?
Yeah, you'd think. Can you post a full reproducible test case?
It's not a bug, that's
On Wed, Dec 29, 2010 at 13:03, Euler Taveira de Oliveira
eu...@timbira.com wrote:
Em 29-12-2010 07:47, Magnus Hagander escreveu:
Would people be interested in putting pg_streamrecv
(http://github.com/mhagander/pg_streamrecv) in bin/ or contrib/ for
9.1? I think it would make sense to do so.
Excerpts from Robert Haas's message of mié dic 29 09:17:17 -0300 2010:
On Tue, Dec 28, 2010 at 5:13 AM, Jie Li jay23j...@gmail.com wrote:
Hi,
Please see the following plan:
postgres=# explain select * from small_table left outer join big_table using
(id);
On 2010-12-29 2:14 PM, Greg Smith wrote:
MERGE INTO Stock t
USING (VALUES(10,100)) AS s(item_id,balance)
ON s.item_id=t.item_id
WHEN MATCHED THEN UPDATE SET balance=t.balance + s.balance
WHEN NOT MATCHED THEN INSERT VALUES(s.item_id,s.balance)
;
If you can suggest an alternate way to
ALTER TABLE ALTER TYPE always rewrites the table heap and its indexes. In some
cases, we can determine that doing so is unhelpful, and that the conversion
shall always succeed:
CREATE DOMAIN loosedom AS text;
CREATE TABLE t (c varchar(2));
ALTER TABLE t ALTER c TYPE varchar(4);
ALTER TABLE t
On Wed, Dec 29, 2010 at 7:34 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2010-12-29 at 07:17 -0500, Robert Haas wrote:
Here I have a puzzle, why not choose the small table to build hash table?
It
can avoid multiple batches thus save significant I/O cost, isn't it?
Yeah, you'd
On Wed, Dec 29, 2010 at 2:27 AM, Joel Jacobson j...@gluefinance.com wrote:
description of split stuff
So, how different (or not) is this to the directory format that was
coming out of the desire of a parallel pg_dump?
a.
--
Aidan Van Dyk Create like
2010/12/29 Aidan Van Dyk ai...@highrise.ca
On Wed, Dec 29, 2010 at 2:27 AM, Joel Jacobson j...@gluefinance.com
wrote:
description of split stuff
So, how different (or not) is this to the directory format that was
coming out of the desire of a parallel pg_dump?
Not sure what format you
On Wed, Dec 29, 2010 at 5:09 AM, Magnus Hagander mag...@hagander.netwrote:
Ok, here's an updated patch that does both these and includes
documentation and regression test changes. With that, I think we're
good to go.
I've applied this version (with some minor typo-fixes).
Do you think
On Wed, Dec 29, 2010 at 8:31 AM, Joel Jacobson j...@gluefinance.com wrote:
2010/12/29 Aidan Van Dyk ai...@highrise.ca
On Wed, Dec 29, 2010 at 2:27 AM, Joel Jacobson j...@gluefinance.com
wrote:
description of split stuff
So, how different (or not) is this to the directory format that was
On Wed, Dec 29, 2010 at 9:11 AM, Gurjeet Singh singh.gurj...@gmail.com wrote:
On Wed, Dec 29, 2010 at 8:31 AM, Joel Jacobson j...@gluefinance.com wrote:
2010/12/29 Aidan Van Dyk ai...@highrise.ca
On Wed, Dec 29, 2010 at 2:27 AM, Joel Jacobson j...@gluefinance.com
wrote:
description of
On Wed, Dec 29, 2010 at 15:05, Gurjeet Singh singh.gurj...@gmail.com wrote:
On Wed, Dec 29, 2010 at 5:09 AM, Magnus Hagander mag...@hagander.net
wrote:
Ok, here's an updated patch that does both these and includes
documentation and regression test changes. With that, I think we're
good to
On Tue, Dec 28, 2010 at 16:15, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Tue, Dec 28, 2010 at 13:18, Robert Haas robertmh...@gmail.com wrote:
Adding a #define to our headers that you can test for seems like the way to
go.
That's kind of what I was
Robert Haas robertmh...@gmail.com writes:
On Wed, Dec 29, 2010 at 7:34 AM, Simon Riggs si...@2ndquadrant.com wrote:
It's not a bug, that's the way it currently works. We don't need a test
case for that.
Oh, you're right. I missed the fact that it's a left join.
The only thing that struck me
Aidan Van Dyk ai...@highrise.ca writes:
On Wed, Dec 29, 2010 at 9:11 AM, Gurjeet Singh singh.gurj...@gmail.com
wrote:
AFAIK, that applies to parallel dumps of data (may help in --schema-only
dumps too), and what you are trying is for schema.
Right, but one of the things it does is break the
Magnus Hagander mag...@hagander.net writes:
On Tue, Dec 28, 2010 at 16:15, Tom Lane t...@sss.pgh.pa.us wrote:
Also, if you really do need to figure out which PG headers you're
compiling against, looking at catversion.h is the accepted way to do it.
There's no need for yet another symbol.
Tom Lane wrote:
I've been fooling around with creating upgrade-in-place support for the
Fedora/RHEL RPMs. What I want to have is a separate postgresql-upgrade
RPM containing just the minimum possible set of previous-release files,
together with pg_upgrade itself. Experimenting with this
On Wed, Dec 29, 2010 at 16:12, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Tue, Dec 28, 2010 at 16:15, Tom Lane t...@sss.pgh.pa.us wrote:
Also, if you really do need to figure out which PG headers you're
compiling against, looking at catversion.h is the
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
I'm not sure how you arrived at that number, though.
http://git.postgresql.org/gitweb?p=postgresql.git;a=blob;f=src/include/access/slru.h;h=710cca70acd67e03e5f3a255b048a719ae4c4709
The way I read this, each segment is (BLCKSZ *
2010/12/29 Tom Lane t...@sss.pgh.pa.us
I think they're fundamentally different things, because the previously
proposed patch is an extension of the machine-readable archive format,
and has to remain so because of the expectation that people will want
to use parallel restore with it. Joel is
On Dec 29, 2010, at 7:56 AM, Noah Misch n...@leadboat.com wrote:
ALTER TABLE ALTER TYPE always rewrites the table heap and its indexes. In
some
cases, we can determine that doing so is unhelpful, and that the conversion
shall always succeed:
CREATE DOMAIN loosedom AS text;
CREATE TABLE t
Noah Misch n...@leadboat.com writes:
ALTER TABLE ALTER TYPE always rewrites the table heap and its indexes. In
some
cases, we can determine that doing so is unhelpful, and that the conversion
shall always succeed:
I wish to replace table rewrites with table verification scans where
- Original Message -
From: Alvaro Herrera alvhe...@commandprompt.com
To: Robert Haas robertmh...@gmail.com
Cc: Jie Li jay23j...@gmail.com; pgsql-hackers
pgsql-hackers@postgresql.org
Sent: Wednesday, December 29, 2010 8:39 PM
Subject: Re: [HACKERS] small table left outer join big table
Thank you for all your comments.
I think the condition of this optimization is whether the small table can fit
into memory. If not, then it doesn't work since two tables still need to be
written to disk. But if yes, we can save all I/O costs in the hash join
process.
Thanks,
Li Jie
-
- Original Message -
From: Tom Lane t...@sss.pgh.pa.us
To: Robert Haas robertmh...@gmail.com
Cc: Simon Riggs si...@2ndquadrant.com; Jie Li jay23j...@gmail.com;
pgsql-hackers pgsql-hackers@postgresql.org
Sent: Wednesday, December 29, 2010 10:59 PM
Subject: Re: [HACKERS] small table left
Robert Haas robertmh...@gmail.com writes:
On Dec 29, 2010, at 7:56 AM, Noah Misch n...@leadboat.com wrote:
The exemptor shall have this signature:
exemptor_func(
integer, -- source_typmod
integer -- dest_typmod
) RETURNS boolean
The exemptor shall return true iff datumIsEqual(x,
On 29.12.2010 13:17, Robert Haas wrote:
Did you read the whole thread?
Ah, sorry:
I've had to change some of the heap_open(rv) calls to
relation_open(rv) to avoid having the former throw the wrong error
message before the latter kicks in. I think there might be stylistic
objections to that,
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Hmm, I believe the idea of heap_open is to check that the relation is
backed by a heap that you can read with heap_beginscan+heap_next. At the
moment that includes normal tables, sequences and toast tables. Foreign
tables would
On Wed, Dec 29, 2010 at 11:47:53AM +0100, Magnus Hagander wrote:
Would people be interested in putting pg_streamrecv
(http://github.com/mhagander/pg_streamrecv) in bin/ or contrib/ for
9.1? I think it would make sense to do so.
+1 for bin/
Cheers,
David.
--
David Fetter da...@fetter.org
On Wed, Dec 29, 2010 at 11:16:23AM -0500, Tom Lane wrote:
Noah Misch n...@leadboat.com writes:
ALTER TABLE ALTER TYPE always rewrites the table heap and its indexes. In
some
cases, we can determine that doing so is unhelpful, and that the conversion
shall always succeed:
I wish to
On 26.12.2010 21:40, Kevin Grittner wrote:
To recap, I've had an open question on the Serializable Wiki page[1]
since January about how we should handle long-running transactions.
The algorithm published by Cahill et al requires keeping some
transaction information in memory for all committed
David Fetter da...@fetter.org writes:
On Wed, Dec 29, 2010 at 11:47:53AM +0100, Magnus Hagander wrote:
Would people be interested in putting pg_streamrecv
(http://github.com/mhagander/pg_streamrecv) in bin/ or contrib/ for
9.1? I think it would make sense to do so.
+1 for bin/
Is it really
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
Looking at the predicate lock splitting, it occurs to me that
it's possible for a non-serializable transaction to be canceled if
it needs to split a predicate lock held by a concurrent
serializable transaction, and you run out of
On Dec 29, 2010, at 12:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Hmm, I believe the idea of heap_open is to check that the relation is
backed by a heap that you can read with heap_beginscan+heap_next. At the
moment that includes
On Dec 29, 2010, at 1:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Is it really stable enough for bin/? My impression of the state of
affairs is that there is nothing whatsoever about replication that
is really stable yet.
Well, that's not stopping us from shipping a core feature called
Bruce Momjian wrote:
Yes, that was my calculus too. I realized that we create session ids by
merging the process id and backend start time, so I went ahead and added
the postmaster start time epoch to the postmaster.pid file. While there
is no way to pass back the postmaster start time from
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
Any chance of upgrading the lock to a relation lock, or killing
the serializable transaction instead?
Absolutely. Good suggestion. Thanks!
I pushed a TODO SSI comment at the appropriate point with my ideas
on how best to fix this. I
On Dec 29, 2010, at 11:16 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I really really dislike the notion of a verification scan: it's
basically work that is going to be useless if it fails.
I think it has potential in cases like text to xml. In that case it'll either
work or fail, with no
On Dec 29, 2010, at 10:14 AM, Magnus Hagander mag...@hagander.net wrote:
We can be held responsible for the packaging decisions if they use
*our* make install commands, imho.
Yep.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Robert Haas robertmh...@gmail.com writes:
On Dec 29, 2010, at 11:16 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I really really dislike the notion of a verification scan: it's
basically work that is going to be useless if it fails.
I think it has potential in cases like text to xml. In that case
Excerpts from Magnus Hagander's message of mié dic 29 11:40:34 -0300 2010:
On Wed, Dec 29, 2010 at 15:05, Gurjeet Singh singh.gurj...@gmail.com wrote:
Any specific reason NOREPLICATION_P and REPLICATION_P use the _P suffix?
Um, I just copied it off a similar entry elsewhere. I saw no
On Wed, Dec 29, 2010 at 1:42 PM, Robert Haas robertmh...@gmail.com wrote:
On Dec 29, 2010, at 1:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Is it really stable enough for bin/? My impression of the state of
affairs is that there is nothing whatsoever about replication that
is really stable
On Tue, Dec 28, 2010 at 11:07:59PM +, Peter Geoghegan wrote:
On 28 December 2010 20:07, Peter Eisentraut pete...@gmx.net wrote:
The phrase common table expression does not appear anywhere in the SQL
standard. The standard uses the grammar symbol with clause.
I think we're losing sight
Robert Haas robertmh...@gmail.com writes:
The existing comments mention that callers must check that the return
value is not a view, if they care. So if there is currently a single
coherent definition for what heap_open is supposed to do, it's clearly
NOT the one Heikki proposes. My guess is
Excerpts from Tom Lane's message of mié dic 29 16:29:45 -0300 2010:
In practice I think it would make sense if heap_open accepts all
relation types on which you can potentially do either a heapscan or
indexscan (offhand those should be the same set of relkinds, I think;
so this is the same in
Oleg Bartunov wrote:
Hi there,
it's clear we need versions, probably, major.minor would be enough. The
problem
I see is how to keep .so in sync with .sql ? Should we store .sql in database
?
Also, we need permissions for extension, since we have open/closed
extensions.
Don't
Excerpts from Kevin Grittner's message of mié dic 29 12:20:20 -0300 2010:
http://git.postgresql.org/gitweb?p=postgresql.git;a=blob;f=src/include/access/slru.h;h=710cca70acd67e03e5f3a255b048a719ae4c4709
The way I read this, each segment is (BLCKSZ *
SLRU_PAGES_PER_SEGMENT) long, which is
On Dec 29, 2010, at 12:00 PM, Bruce Momjian wrote:
Don't people normally define the version number in the Makefile and pass
the version string into the C code and perhaps a psql variable?
There is no standard pattern AFAIK. A best practice would be welcome here.
David
--
Sent via
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Tom Lane's message of mié dic 29 16:29:45 -0300 2010:
In practice I think it would make sense if heap_open accepts all
relation types on which you can potentially do either a heapscan or
indexscan (offhand those should be the
Tom Lane wrote:
Jeff Janes jeff.ja...@gmail.com writes:
Of course if you do a full table scan because their are no better
options, then it scans sequentially. But you have to scan the pages
in *some* order, and it is hard to see how something other than
sequential would be systematically
Vaibhav Kaushal wrote:
On Fri, 2010-12-10 at 18:07 -0800, Josh Berkus wrote:
On 12/10/10 5:06 PM, Daniel Loureiro wrote:
An quicksort method in
sequential disk its just awful to be thinking in a non SSD world, but
its possible in an SSD.
So, code it. Shouldn't be hard to write a
Alvaro Herrera alvhe...@commandprompt.com wrote:
If these limitations become a problem, you can always change them.
A couple of zeroes at the start of the pg_clog filenames aren't
going to bother anyone, I don't think. Not so sure about your new
proposed design's space usage.
I guess
Bruce Momjian br...@momjian.us writes:
Oleg Bartunov wrote:
it's clear we need versions, probably, major.minor would be enough. The
problem
I see is how to keep .so in sync with .sql ? Should we store .sql in
database ?
Don't people normally define the version number in the Makefile and
Josh Berkus j...@agliodbs.com writes:
On 12/27/10 7:35 PM, Josh Berkus wrote:
On 12/27/10 1:45 PM, Peter Eisentraut wrote:
I'm unable to produce any really exciting release notes for alpha3. I
have produced a draft here:
http://wiki.postgresql.org/wiki/Alpha_release_notes_draft Please edit
Joel Jacobson j...@gluefinance.com writes:
Solution: I propose a new option to pg_dump, --split, which dumps each
object to a separate file in a user friendly directory structure:
Please have a look at getddl:
https://github.com/dimitri/getddl
Regards,
--
Dimitri Fontaine
Bruce Momjian wrote:
Vaibhav Kaushal wrote:
On Fri, 2010-12-10 at 18:07 -0800, Josh Berkus wrote:
On 12/10/10 5:06 PM, Daniel Loureiro wrote:
An quicksort method in
sequential disk its just awful to be thinking in a non SSD world, but
its possible in an SSD.
So, code it.
On Dec 29, 2010, at 12:23 PM, Tom Lane wrote:
We had a long discussion upthread of what version numbers to keep where.
IMHO the Makefile is about the *least* useful place to put a version
number; the more so if you want more than one. What we seem to need is
a version number in the .sql file
Kevin Grittner kevin.gritt...@wicourts.gov wrote:
if a serializable transaction which is not flagged as read only
remains open long enough for over a billion other transactions to
commit
Maybe a clarification and example would be useful. We're talking
about going through a billion
On Wed, 2010-12-29 at 09:59 -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Dec 29, 2010 at 7:34 AM, Simon Riggs si...@2ndquadrant.com wrote:
It's not a bug, that's the way it currently works. We don't need a test
case for that.
Oh, you're right. I missed the
On Wed, Dec 29, 2010 at 3:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Tom Lane's message of mié dic 29 16:29:45 -0300 2010:
In practice I think it would make sense if heap_open accepts all
relation types on which you can potentially
Magnus Hagander mag...@hagander.net writes:
On Tue, Dec 28, 2010 at 18:12, Robert Haas robertmh...@gmail.com wrote:
Although maybe now that we've made recovery.conf use the GUC lexer we
oughta continue in that vein and expose those parameters as
PGC_INTERNAL GUCs rather than inventing a new
On Wed, Dec 29, 2010 at 3:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Oleg Bartunov wrote:
it's clear we need versions, probably, major.minor would be enough. The
problem
I see is how to keep .so in sync with .sql ? Should we store .sql in
database ?
On Tue, Dec 28, 2010 at 07:09:14AM -0500, Robert Haas wrote:
On Tue, Dec 28, 2010 at 12:45 AM, David Fetter da...@fetter.org wrote:
I don't see how people can be relying on links to 9.1-to-be's
documentation.
Well, it's always handy when the filenames are the same across
versions. Ever
Magnus Hagander mag...@hagander.net writes:
Would people be interested in putting pg_streamrecv
(http://github.com/mhagander/pg_streamrecv) in bin/ or contrib/ for
9.1? I think it would make sense to do so.
+1 for having that in core, only available for the roles WITH
REPLICATION I suppose?
On Dec 29, 2010, at 1:27 PM, Robert Haas wrote:
I think there are really two tasks here:
1. Identify whether a newer set of SQL definitions than the one
installed is available. If so, the extension is a candidate for an
upgrade.
2. Identify whether the installed version of the SQL
On Wed, Dec 29, 2010 at 4:09 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 29.12.2010 06:54, Robert Haas wrote:
With the patch:
rhaas=# cluster v;
ERROR: views do not support CLUSTER
do not support sounds like a missing feature, rather than a nonsensical
command.
Robert Haas robertmh...@gmail.com writes:
On Wed, Dec 29, 2010 at 3:23 PM, Tom Lane t...@sss.pgh.pa.us wrote:
We had a long discussion upthread of what version numbers to keep where.
IMHO the Makefile is about the *least* useful place to put a version
number; the more so if you want more than
On Wed, Dec 29, 2010 at 04:53:47PM -0500, Robert Haas wrote:
On Wed, Dec 29, 2010 at 4:09 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 29.12.2010 06:54, Robert Haas wrote:
With the patch:
rhaas=# cluster v;
ERROR: views do not support CLUSTER
do not
Howdy,
I am hoping someone can help me better understand what the minimum recovery
ending location of pg_controldata represents with regards to 9.0 hot
standbys. When I look at any of our 8.4 (or lower) installs this number is
almost always somewhere in the past of the xlog timeline (presuming
On 30.12.2010 00:19, Robert Treat wrote:
Howdy,
I am hoping someone can help me better understand what the minimum recovery
ending location of pg_controldata represents with regards to 9.0 hot
standbys. When I look at any of our 8.4 (or lower) installs this number is
almost always somewhere in
On Wed, Dec 29, 2010 at 10:56:39AM -0500, Robert Haas wrote:
On Dec 29, 2010, at 7:56 AM, Noah Misch n...@leadboat.com wrote:
Having thought on it
more, though, it actually seems best to attempt the verification scan
*every*
time. In most ineligible conversions, an inequality will
Attached is a small patch to avoid putting an opaque structure into
the slru.h file and using it in an external function call where
external callers must always specify NULL.
-Kevin
*** a/src/backend/access/transam/clog.c
--- b/src/backend/access/transam/clog.c
***
*** 445,451
Well, but that's not 7%, thats 7x! And the theorem says 'greater or equal'
so this is actually the minimum - you can get a much bigger difference
with lower probability. So you can easily get an estimate that is a few
orders off.
FWIW, based on query performance, estimates which are up to 5X
On Wed, Dec 29, 2010 at 3:34 PM, Bruce Momjian br...@momjian.us wrote:
Bruce Momjian wrote:
Vaibhav Kaushal wrote:
On Fri, 2010-12-10 at 18:07 -0800, Josh Berkus wrote:
On 12/10/10 5:06 PM, Daniel Loureiro wrote:
An quicksort method in
sequential disk its just awful to be
On Wed, Dec 29, 2010 at 11:16:23AM -0500, Tom Lane wrote:
Noah Misch n...@leadboat.com writes:
ALTER TABLE ALTER TYPE always rewrites the table heap and its indexes. In
some
cases, we can determine that doing so is unhelpful, and that the conversion
shall always succeed:
I wish to
(2010/12/27 17:53), Simon Riggs wrote:
On Fri, 2010-12-24 at 11:53 +0900, KaiGai Kohei wrote:
The attached patch is the modular version of SE-PostgreSQL.
Looks interesting.
Couple of thoughts...
Docs don't mention row-level security. If we don't have it, I think we
should say that clearly.
On Wed, Dec 29, 2010 at 02:01:28PM -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Dec 29, 2010, at 11:16 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I really really dislike the notion of a verification scan: it's
basically work that is going to be useless if it fails.
I
We have been seeing these warnings recently whenever a standby is
brought up (typically to check it is ok). Sometimes they are coupled
with corrupted indexes which require a REINDEX to fix. Initially I
thought these uninitialized pages were due to primary crashes or
hardware issues, however
On Thu, 2010-12-30 at 09:26 +0900, KaiGai Kohei wrote:
What happens if someone alters the configuration so that the sepgsql
plugin is no longer installed. Does the hidden data become visible?
Yes. If sepgsql plugin is uninstalled, the hidden data become visible.
But no matter. Since only
(2010/12/30 9:34), Simon Riggs wrote:
On Thu, 2010-12-30 at 09:26 +0900, KaiGai Kohei wrote:
What happens if someone alters the configuration so that the sepgsql
plugin is no longer installed. Does the hidden data become visible?
Yes. If sepgsql plugin is uninstalled, the hidden data become
Marko Tiikkaja wrote:
As far as I can tell, this should work. I played around with the
patch and the problem seems to be the VALUES:
INTO Stock t
USING (SELECT 30, 2000) AS s(item_id,balance)
ON s.item_id=t.item_id
WHEN MATCHED THEN UPDATE SET balance=t.balance + s.balance
WHEN NOT
On 2010-12-30 4:39 AM +0200, Greg Smith wrote:
And that got me back again to concurrent testing.
Moving onto next two problems...the basic MERGE feature seems to have
stepped backwards a bit too. I'm now seeing these quite often:
ERROR: duplicate key value violates unique constraint
On Wed, Dec 29, 2010 at 3:58 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2010-12-29 at 09:59 -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Dec 29, 2010 at 7:34 AM, Simon Riggs si...@2ndquadrant.com
wrote:
It's not a bug, that's the way it currently
On Wed, Dec 29, 2010 at 6:46 PM, Noah Misch n...@leadboat.com wrote:
I think this scenario will be more common than you might think. Tables
don't contain random data; they contain data that the DBA thinks is valid.
The situation where the data is mostly as you expect but with a few kooky
1 - 100 of 107 matches
Mail list logo
