Robert Haas writes:
> On Tue, Oct 25, 2011 at 9:06 PM, Tom Lane 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 to the point of using
>> syscache
On Tue, Oct 25, 2011 at 9:06 PM, Tom Lane 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 has not yet sent
On Tue, Oct 25, 2011 at 9:03 PM, Magnus Hagander wrote:
> On Tue, Oct 25, 2011 at 13:54, Fujii Masao wrote:
>> On Tue, Oct 25, 2011 at 7:19 PM, Magnus Hagander wrote:
>>> I don't think we should necessarily give up completely. But doing a
>>> pg_basebackup way *first* seems reasonable - because
>
> 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
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, ma
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 targ
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.
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 near
Alvaro Herrera 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 reasonable ... part
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.
> 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
On Mon, Oct 24, 2011 at 20:52, Erik Rijkers 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 were
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 lexe
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 Tue, October 25, 2011 19:49, Kerem Kat wrote:
> On Mon, Oct 24, 2011 at 20:52, Erik Rijkers 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
> tests f
On Mon, Oct 24, 2011 at 3:05 PM, Alexander Korotkov wrote:
> 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 we could handle
2011/7/16 MauMau :
> 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.
>
> I'm s
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 dic
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
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
> permu
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 session).
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.
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 contain
On Tue, Oct 25, 2011 at 2:33 AM, Fujii Masao wrote:
> On Tue, Oct 25, 2011 at 2:41 AM, Gurjeet Singh
> 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
> :
> >>
On Tue, Oct 25, 2011 at 3:08 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> 2011/10/25 Shigeru Hanada :
>>> 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.
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,
elim
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 full_page_writes=on
On Tue, Oct 25, 2011 at 12:39 PM, Florian Pflug 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 did a seek wit
* 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 s
>> 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 i
On Tue, Oct 25, 2011 at 14:08, Tom Lane wrote:
> Magnus Hagander writes:
>> 2011/10/25 Shigeru Hanada :
>>> 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. jo
Magnus Hagander writes:
> 2011/10/25 Shigeru Hanada :
>> 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
On Tue, Oct 25, 2011 at 13:54, Fujii Masao wrote:
> On Tue, Oct 25, 2011 at 7:19 PM, Magnus Hagander 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
On Tue, Oct 25, 2011 at 7:19 PM, Magnus Hagander 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 mean we shouldn't
On Tue, Oct 25, 2011 at 00:00, Alexander Korotkov wrote:
> On Tue, Oct 25, 2011 at 1:46 AM, Kevin Grittner
> wrote:
>>
>> Alexander Korotkov wrote:
>>
>> > Coundn't be predicate locking implementation in SSI be used for
>> > in-database cache invalidation.
>>
>> It would not necessarily be limit
On Oct25, 2011, at 11:13 , Simon Riggs wrote:
> On Tue, Oct 25, 2011 at 8:03 AM, Simon Riggs 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 cau
On Tue, Oct 25, 2011 at 10:50, Fujii Masao wrote:
> On Tue, Oct 25, 2011 at 3:44 PM, Heikki Linnakangas
> wrote:
> +
> + Again connect to the database as a superuser, and execute
> +pg_stop_backup. This terminates the backup mode, but
> does not
> + perform a switch
2011/10/25 Shigeru Hanada :
> 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 code itself, but I wonde
On Tue, Oct 25, 2011 at 8:03 AM, Simon Riggs 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 that whole pages
On Tue, Oct 25, 2011 at 3:44 PM, Heikki Linnakangas
wrote:
+
+ Again connect to the database as a superuser, and execute
+pg_stop_backup. This terminates the backup mode, but
does not
+ perform a switch to the next WAL segment, create a backup history
file a
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 Mon, Oct 24, 2011 at 7:13 AM, Florian Pflug 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 said that,
wh
42 matches
Mail list logo
