On Tue, Oct 25, 2011 at 2:41 AM, Gurjeet Singh singh.gurj...@gmail.com wrote:
On Mon, Oct 24, 2011 at 1:08 PM, Alvaro Herrera alvhe...@commandprompt.com
wrote:
Excerpts from Gurjeet Singh's message of lun oct 24 13:55:44 -0300 2011:
Starting from line 89 of terminal1.txt we see this
Hello,
my experience is that as soon as index only scans are available they are used -
sometimes just because of the simple logic that a user thinks it is faster.
Even when the index is so ridiculously long just to have all info in the
index...
Regards
Wolfgang Wilhelm
On 25.10.2011 08:12, Fujii Masao wrote:
On Tue, Oct 25, 2011 at 12:24 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 24.10.2011 15:29, Fujii Masao wrote:
+listitem
+para
+ Copy the pg_control file from the cluster directory to the global
+ sub-directory of the
On Mon, Oct 24, 2011 at 7:13 AM, Florian Pflug f...@phlo.org wrote:
I think Simon's theory that we're starting recovery from the wrong place,
i.e. should start with an earlier WAL location, is probably correct. The
question is, why?
Err, that's not what I said and I don't mean that. Having
Hi.
I would like to ask you which sources are responsible for execute queries in
PostgreSQL?
( i would like to run a simple query and debug it execution on PostgreSql
server for understanding how PostgeSql does query processing internally)
regards,
Vadym
On Tue, Oct 25, 2011 at 3:44 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
+para
+ Again connect to the database as a superuser, and execute
+functionpg_stop_backup/. This terminates the backup mode, but
does not
+ perform a switch to the next WAL segment, create
On Tue, Oct 25, 2011 at 8:03 AM, Simon Riggs si...@2ndquadrant.com wrote:
We are starting recovery at the right place but we are initialising
the clog and subtrans incorrectly. Precisely, the oldestActiveXid is
being derived later than it should be, which can cause problems if
this then means
2011/10/25 Shigeru Hanada shigeru.han...@gmail.com:
I'd like to propose pgsql_fdw, FDW for external PostgreSQL server, as a
contrib module. I think that this module would be the basis of further
SQL/MED development for core, e.g. join-push-down and ANALYZE support.
I have not looked at the
On Tue, Oct 25, 2011 at 10:50, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Oct 25, 2011 at 3:44 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
+para
+ Again connect to the database as a superuser, and execute
+functionpg_stop_backup/. This terminates the backup
On Oct25, 2011, at 11:13 , Simon Riggs wrote:
On Tue, Oct 25, 2011 at 8:03 AM, Simon Riggs si...@2ndquadrant.com wrote:
We are starting recovery at the right place but we are initialising
the clog and subtrans incorrectly. Precisely, the oldestActiveXid is
being derived later than it should
On Tue, Oct 25, 2011 at 00:00, Alexander Korotkov aekorot...@gmail.com wrote:
On Tue, Oct 25, 2011 at 1:46 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Alexander Korotkov aekorot...@gmail.com wrote:
Coundn't be predicate locking implementation in SSI be used for
in-database cache
On Tue, Oct 25, 2011 at 7:19 PM, Magnus Hagander mag...@hagander.net wrote:
I don't think we should necessarily give up completely. But doing a
pg_basebackup way *first* seems reasonable - because it's going to be
the easiest one to get right, given that we have more control there.
Doesn't
On Tue, Oct 25, 2011 at 13:54, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Oct 25, 2011 at 7:19 PM, Magnus Hagander mag...@hagander.net wrote:
I don't think we should necessarily give up completely. But doing a
pg_basebackup way *first* seems reasonable - because it's going to be
the
Magnus Hagander mag...@hagander.net writes:
2011/10/25 Shigeru Hanada shigeru.han...@gmail.com:
I'd like to propose pgsql_fdw, FDW for external PostgreSQL server, as a
contrib module. I think that this module would be the basis of further
SQL/MED development for core, e.g. join-push-down and
On Tue, Oct 25, 2011 at 14:08, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
2011/10/25 Shigeru Hanada shigeru.han...@gmail.com:
I'd like to propose pgsql_fdw, FDW for external PostgreSQL server, as a
contrib module. I think that this module would be the basis
ATM I'm not sure it's even a good idea to push pgsql_fdw into contrib.
Once we do that its release schedule will get locked to core's ---
wouldn't it be better to keep flexibility for now, while it's in such
active development?
I would be happy to keep it outside, and integrate it in the
* Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
Right now, file_fdw is the only FDW module that we have in the core,
Erm, guess I'm a bit confused why we've got that in core while not
putting pgsql_fdw in core. This all gets back to previous discussions
around 'recommended' contrib modules (which
On Tue, Oct 25, 2011 at 12:39 PM, Florian Pflug f...@phlo.org wrote:
What I don't understand is how this affects the CLOG. How does oldestActiveXID
factor into CLOG initialization?
It is an entirely different error.
Chris' clog error was caused by a file read error. The file was
opened, we
On 11-10-25 02:44 AM, Heikki Linnakangas wrote:
With pg_basebackup, we have a fighting chance of getting this right,
because we have more control over how the backup is made. For example,
we can co-operate with the buffer manager to avoid torn-pages,
eliminating the need for
On 25.10.2011 15:56, Steve Singer wrote:
On 11-10-25 02:44 AM, Heikki Linnakangas wrote:
With pg_basebackup, we have a fighting chance of getting this right,
because we have more control over how the backup is made. For example,
we can co-operate with the buffer manager to avoid torn-pages,
On Tue, Oct 25, 2011 at 3:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
2011/10/25 Shigeru Hanada shigeru.han...@gmail.com:
I'd like to propose pgsql_fdw, FDW for external PostgreSQL server, as a
contrib module. I think that this module would be the
On Tue, Oct 25, 2011 at 2:33 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Oct 25, 2011 at 2:41 AM, Gurjeet Singh singh.gurj...@gmail.com
wrote:
On Mon, Oct 24, 2011 at 1:08 PM, Alvaro Herrera
alvhe...@commandprompt.com
wrote:
Excerpts from Gurjeet Singh's message of lun oct 24
I am currently using the prefix search feature in text search. I find
that the prefix characters are treated the same as a normal lexeme and
passed through stemming and stopword dictionaries. This seems like a bug
to me.
db=# select to_tsquery('english', 's:*');
NOTICE: text-search query
On Oct25, 2011, at 17:26 , Sushant Sinha wrote:
I am currently using the prefix search feature in text search. I find
that the prefix characters are treated the same as a normal lexeme and
passed through stemming and stopword dictionaries. This seems like a bug
to me.
Hm, I don't think so. If
This patch adds a -n option to isolationtester. With this option,
instead of running the tests, it prints the permutations that would be
run. This is very useful for generating test specs which need to remove
permutations that are not valid (because they would run a command on a
blocked
Excerpts from Alvaro Herrera's message of mar oct 25 13:32:31 -0300 2011:
This patch adds a -n option to isolationtester. With this option,
instead of running the tests, it prints the permutations that would be
run. This is very useful for generating test specs which need to remove
On Mon, 2011-10-24 at 13:15 +0300, Heikki Linnakangas wrote:
Hmm, I don't think that's safe. After Oid wraparound, a range type oid
might get reused for some other range type, and the cache would return
stale values. Extremely unlikely to happen by accident, but could be
exploited by an
On Tue, 2011-10-25 at 18:05 +0200, Florian Pflug wrote:
On Oct25, 2011, at 17:26 , Sushant Sinha wrote:
I am currently using the prefix search feature in text search. I find
that the prefix characters are treated the same as a normal lexeme and
passed through stemming and stopword
2011/7/16 MauMau maumau...@gmail.com:
Hello,
The attached file is a revised patch which reflects all review comments by
Magnus in:
http://archives.postgresql.org/pgsql-hackers/2011-07/msg00839.php
I made sure the previous tests (both custom and default PostgreSQL event
source) succeeded.
On Mon, Oct 24, 2011 at 3:05 PM, Alexander Korotkov aekorot...@gmail.comwrote:
If we allow user to specify own gist_penalty function, then such function
should deal with:
1) GiST-specific data structures such as GISTENTRY.
2) Decomposing ranges using range_deserialize.
3) Inifinities, which
On Tue, October 25, 2011 19:49, Kerem Kat wrote:
On Mon, Oct 24, 2011 at 20:52, Erik Rijkers e...@xs4all.nl wrote:
On Wed, October 19, 2011 15:01, Kerem Kat wrote:
Adding CORRESPONDING to Set Operations
I have corrected the ordering of the targetlists of subqueries. And
added 12 regression
I've looked into the cause of bug #6268,
http://archives.postgresql.org/pgsql-bugs/2011-10/msg00223.php
It's fairly simple: we're firing RI triggers in the wrong order.
What's happening is that we update the tuple and queue RI_FKey_check_upd
and RI_FKey_cascade_upd events for the update action,
On Oct25, 2011, at 18:47 , Sushant Sinha wrote:
On Tue, 2011-10-25 at 18:05 +0200, Florian Pflug wrote:
On Oct25, 2011, at 17:26 , Sushant Sinha wrote:
I am currently using the prefix search feature in text search. I find
that the prefix characters are treated the same as a normal lexeme and
On Mon, Oct 24, 2011 at 20:52, Erik Rijkers e...@xs4all.nl wrote:
On Wed, October 19, 2011 15:01, Kerem Kat wrote:
Adding CORRESPONDING to Set Operations
Initial patch, filename: corresponding_clause_v2.patch
I had a quick look at the behaviour of this patch.
Btw, the examples in your email
Chris, can you rearrange the backup so you copy the pg_control file as
the first act after the pg_start_backup?
I tried this and it doesn't seem to make any difference. I also tried the
patch and I can no longer reproduce the subtrans error, however instead it
now it starts up, but never gets
Excerpts from Tom Lane's message of mar oct 25 14:57:43 -0300 2011:
I'm not sure if this is something we can back-patch --- I don't see any
dependencies in our own code on what names RI triggers have, but I'm
afraid there is client-side code out there that knows it.
Yeah, sounds possible.
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Tom Lane's message of mar oct 25 14:57:43 -0300 2011:
... Or maybe we could
back-patch a change in creation order and rely on that usually working.
Given the lack of prior complaints that might be good enough.
The latter looks
On Tue, 2011-10-25 at 19:27 +0200, Florian Pflug wrote:
Assume, for example, that the postgres mailing list archive search used
tsearch (which I think it does, but I'm not sure). It'd then probably make
sense to add postgres to the list of stopwords, because it's bound to
appear in nearly
On Oct20, 2011, at 05:07 , Dan Ports wrote:
On Thu, Oct 20, 2011 at 02:02:09AM +0200, Florian Pflug wrote:
I've patched the ports for openjade, iso8879 and docbook-dsssl,
and added a new port for docbook-sgml-4.2. These patches are sitting
in the macports trac now, waiting to be applied.
I believe I have reproduced the behavior described by Andrew Hammond in
http://archives.postgresql.org/pgsql-general/2011-10/msg00928.php
This is using the regression database:
1. In session 1, do
set default_statistics_target TO 1;
analyze tenk1;
(We need the large stats
Instead of simply aborting a spec that specifies running commands on
blocked sessions (what we call an invalid permutation), it seems more
useful to report the problem, cleanup the sessions, and continue with
the next permutation.
This, in conjunction with the dry-run patch I submitted earlier,
That isn't a Hot Standby problem, a recovery problem nor is it certain
its a PostgreSQL problem.
Do you have any theories on this that I could help investigate? It happens
even when using pg_basebackup and it persists until another sync is
performed, so the files must be in some state that
On Tue, Oct 25, 2011 at 9:03 PM, Magnus Hagander mag...@hagander.net wrote:
On Tue, Oct 25, 2011 at 13:54, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Oct 25, 2011 at 7:19 PM, Magnus Hagander mag...@hagander.net wrote:
I don't think we should necessarily give up completely. But doing a
On Tue, Oct 25, 2011 at 9:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
What has happened here is that the second ANALYZE has marked itself
committed in pg_clog and no longer running in the ProcArray, so VACUUM
feels entitled to remove toast tuples that the ANALYZE deleted. However,
the ANALYZE
Robert Haas robertmh...@gmail.com writes:
On Tue, Oct 25, 2011 at 9:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Ordinarily, sending out sinval messages post-commit is okay because we
don't release locks until after that, and we suppose that our locks
prevent any other transactions from getting
45 matches
Mail list logo