Andres Freund and...@2ndquadrant.com writes:
What about
3) Use reltoastidxid if != InvalidOid and manually build the list (using
RelationGetIndexList) otherwise?
Do we actually need reltoastidxid at all? I always thought having that
field was a case of premature optimization. There might be
On 2013-02-07 03:01:36 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
What about
3) Use reltoastidxid if != InvalidOid and manually build the list (using
RelationGetIndexList) otherwise?
Do we actually need reltoastidxid at all? I always thought having that
field
On Thu, Feb 7, 2013 at 5:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andres Freund and...@2ndquadrant.com writes:
What about
3) Use reltoastidxid if != InvalidOid and manually build the list (using
RelationGetIndexList) otherwise?
Do we actually need reltoastidxid at all? I always
On Thu, Feb 7, 2013 at 5:15 PM, Andres Freund and...@2ndquadrant.comwrote:
On 2013-02-07 03:01:36 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
What about
3) Use reltoastidxid if != InvalidOid and manually build the list
(using
RelationGetIndexList) otherwise?
On 7 February 2013 05:39, Jeff Janes jeff.ja...@gmail.com wrote:
While stress testing Pavan's 2nd pass vacuum visibility patch, I realized
that vacuum/visibility was busted. But it wasn't his patch that busted it.
As far as I can tell, the bad commit was in the range
On 6 February 2013 18:02, Robert Haas robertmh...@gmail.com wrote:
So I would ask this question: why would someone want to turn off
fast-promote mode, assuming for the sake of argument that it isn't
buggy?
You can write a question many ways, and lead people towards a
conclusion as a result.
On Thu, Feb 7, 2013 at 11:09 AM, Jeff Janes jeff.ja...@gmail.com wrote:
While stress testing Pavan's 2nd pass vacuum visibility patch, I realized
that vacuum/visibility was busted. But it wasn't his patch that busted it.
As far as I can tell, the bad commit was in the range
On 07.02.2013 10:41, Simon Riggs wrote:
On 6 February 2013 18:02, Robert Haasrobertmh...@gmail.com wrote:
So I would ask this question: why would someone want to turn off
fast-promote mode, assuming for the sake of argument that it isn't
buggy?
You can write a question many ways, and lead
On Thu, Feb 7, 2013 at 2:25 PM, Pavan Deolasee pavan.deola...@gmail.com wrote:
Will look more into it, but thought this might be useful for others to
spot the problem.
And here is some more forensic info about one of the pages having
duplicate tuples.
jjanes=# select *, xmin, xmax, ctid
On 7 February 2013 09:04, Heikki Linnakangas hlinnakan...@vmware.com wrote:
It makes me uncomfortable that we're adding switches to pg_ctl promote just
because we're worried there might be bugs in our code. If we don't trust the
code as it is, it needs more testing. We can analyze the code
Thanks for your introduction. It made me almost clear.
From selinux perspective, it does not switch user's privilege even when
query scans underlying tables because it has no ownership concept.
The current implementation does not make a problem because all the
MV refresh shall be done in a
On Thu, Feb 7, 2013 at 8:20 AM, Daniel Farina dan...@heroku.com wrote:
On Wed, Feb 6, 2013 at 3:00 PM, Joshua D. Drake j...@commandprompt.com
wrote:
On 02/06/2013 01:53 PM, Tom Lane wrote:
... if it's going to try to coerce us out of our email-centric habits,
then I for one am very much
On Thu, Feb 7, 2013 at 8:29 AM, Brendan Jurd dire...@gmail.com wrote:
On 7 February 2013 08:07, Josh Berkus j...@agliodbs.com wrote:
The existing Gerrit community would be keen to have the PostgreSQL
project as a major user, though, and would theoretically help with
modification needs.
On 6 February 2013 20:31, Robert Haas robertmh...@gmail.com wrote:
On Wed, Feb 6, 2013 at 1:06 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 6 February 2013 17:43, Robert Haas robertmh...@gmail.com wrote:
On Mon, Feb 4, 2013 at 3:32 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 4 February
On Thu, Feb 7, 2013 at 4:04 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
It makes me uncomfortable that we're adding switches to pg_ctl promote just
because we're worried there might be bugs in our code. If we don't trust the
code as it is, it needs more testing. We can analyze the
On Thu, Feb 7, 2013 at 6:42 AM, Simon Riggs si...@2ndquadrant.com wrote:
IMO the way to resolve that conflict is with a behaviour parameter to
allow people to choose, rather than be forced to wait a year because
some people still run an old version of an add-on package. A good way
to do that
On Tue, Feb 5, 2013 at 4:39 AM, Albe Laurenz laurenz.a...@wien.gv.at wrote:
I guess it's too late for something like that to go into 9.3.
Should I add it to the next commitfest?
Bug fixes can go in pretty much whenever, but adding it to the next
CommitFest is a good way of backstopping it
Through the work on the patch [1], I had a question about the psql \copy
command. We are permitted 1) but not permitted 2):
1) \copy foo from stdin ;
2) \copy foo from stdin;
Is this intentional? I think it would be better to allow for 2). Attached is a
patch.
Thanks,
Best regards,
Etsuro
On Friday, December 14, 2012 5:11 PM Heikki Linnakangas wrote:
On 12.11.2012 12:07, Kyotaro HORIGUCHI wrote:
Hello, This is new version of identity projection patch.
Reverted projectionInfo and ExecBuildProjectionInfo. Identity
projection is recognized directly in ExecGroup, ExecResult,
Hello all and Heikki personally
Thank you for your answer
I have some new points:
Понедельник, 21 января 2013, 10:08 +02:00 от Heikki Linnakangas
hlinnakan...@vmware.com:
On 21.01.2013 09:14, Миша Тюрин wrote:
Is there any reason why pg_basebackup has limitation in an online backup
Pavan Deolasee escribió:
On Thu, Feb 7, 2013 at 2:25 PM, Pavan Deolasee pavan.deola...@gmail.com
wrote:
Will look more into it, but thought this might be useful for others to
spot the problem.
And here is some more forensic info about one of the pages having
duplicate tuples.
Hello, Tom-san, folks,
From: Tom Lane t...@sss.pgh.pa.us
I think if we want to make it bulletproof we'd have to do what the
OP suggested and switch to SIGKILL. I'm not enamored of that for the
reasons I mentioned --- but one idea that might dodge the disadvantages
is to have the postmaster
Alvaro Herrera escribió:
Hm, if the foreign key patch is to blame, this sounds like these tuples
had a different set of XMAX hint bits and a different Xmax, and they
were clobbered by something like vacuum or page pruning.
Hm, I think heap_freeze_tuple is busted, yes.
--
Álvaro Herrera
Heikki Linnakangas hlinnakan...@vmware.com wrote:
On 07.02.2013 10:41, Simon Riggs wrote:
Why would someone want to turn off safe-promote mode, assuming it was
fast enough?
Because faster is nicer, even if the slow mode would be fast enough.
http://www.youtube.com/watch?v=H3R-rtWPyJY
(this is unrelated to the other discussion about this patch)
On 29.01.2013 02:07, Simon Riggs wrote:
Fast promote mode skips checkpoint at end of recovery.
pg_ctl promote -m fast will skip the checkpoint at end of recovery so that we
can achieve very fast failover when the apply delay is low.
On 7 February 2013 16:07, Heikki Linnakangas hlinnakan...@vmware.com wrote:
It just occurred to me that it would be really nice if the end-of-recovery
record, and the timeline-switching shutdown checkpoint record too for that
matter, would include the previous timeline's ID that we forked
Robert Haas robertmh...@gmail.com writes:
$ Right now there is one and only one release in
$ the field that contains hstore 1.1. If we go ahead and prohibit = as
$ an operator name now, we're going to require everyone who is on 9.1
$ and uses hstore and wants to get to 9.3 to either (a) first
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Robert Haas robertmh...@gmail.com writes:
I don't know what to add to that.
There's no technical reason that I'm aware of for hstore 1.1 not to
support all our maintained releases at the same time. That's exactly how
we do it with non-core
On 2/5/13 3:47 PM, Alvaro Herrera wrote:
Tom Lane wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
The
approach in the second patch is to turn these into extern const RmgrId
instead, and use a second inclusion of rmgrlist.h in rmgr.c that assigns
them the values as consts.
... but
On Thu, Feb 7, 2013 at 1:44 AM, Pavan Deolasee pavan.deola...@gmail.com wrote:
On Thu, Feb 7, 2013 at 2:25 PM, Pavan Deolasee pavan.deola...@gmail.com
wrote:
Will look more into it, but thought this might be useful for others to
spot the problem.
And here is some more forensic info about
Tom Lane t...@sss.pgh.pa.us writes:
If you're suggesting that we should back-patch hstore 1.1 into 9.1,
there might not be a technical reason why we couldn't do it, but there
are certainly project-policy reasons. Removing operators, or indeed
changing any SQL interface at all, is exactly the
On Thu, Feb 7, 2013 at 12:55 AM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
On Thu, Feb 7, 2013 at 11:09 AM, Jeff Janes jeff.ja...@gmail.com wrote:
While stress testing Pavan's 2nd pass vacuum visibility patch, I realized
that vacuum/visibility was busted. But it wasn't his patch that
Peter Eisentraut pete...@gmx.net writes:
On 2/5/13 3:47 PM, Alvaro Herrera wrote:
Patch attached.
This has broken cpluspluscheck:
./src/include/access/rmgrlist.h:28:8: error: expected constructor,
destructor, or type conversion before '(' token
cpluspluscheck has an explicit exclusion for
On Thu, Feb 7, 2013 at 9:32 AM, Jeff Janes jeff.ja...@gmail.com wrote:
On Thu, Feb 7, 2013 at 12:55 AM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
Index scans do not return any duplicates and you need to force a seq
scan to see them. Assuming that the page level VM bit might be
Jeff Janes escribió:
On Thu, Feb 7, 2013 at 12:55 AM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
I don't see the assertion failure myself. If I do REINDEX INDEX it
gives a duplicate key violation, and if I do REINDEX TABLE or REINDEX
DATABASE I get claimed success.
This is using
On Thu, Feb 7, 2013 at 10:48 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Thu, Feb 7, 2013 at 1:44 AM, Pavan Deolasee pavan.deola...@gmail.com
wrote:
jjanes=# select *, xmin, xmax, ctid from foo where index IN (select
index from foo group by index having count(*) 1 ORDER by index)
ORDER
Amit Kapila amit.kap...@huawei.com writes:
There can be 2 ways to remove result node
a. Remove the Result plan node in case it is not required - This is same as
currently it does for SubqueryScan.
We can check if the result plan is trivial (with logic similar to
trivial_subqueryscan()),
On 6 February 2013 17:43, Simon Riggs si...@2ndquadrant.com wrote:
Here's what I think should be done:
1. Remove the check that prev checkpoint record exists.
Agreed
Done
2. Always do fast promotion if in standby mode. Remove the pg_ctl option.
Disagreed, other viewpoints welcome.
On Thu, Feb 7, 2013 at 10:09 AM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
Right. I don't have the database handy at this moment, but earlier in
the day I ran some queries against it and found that most of the
duplicates which are not accessible via indexes have xmin very close
to
On 2013-02-07 11:15:46 -0800, Jeff Janes wrote:
On Thu, Feb 7, 2013 at 10:09 AM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
Right. I don't have the database handy at this moment, but earlier in
the day I ran some queries against it and found that most of the
duplicates which are not
Jeff Janes jeff.ja...@gmail.com writes:
Does anyone have suggestions on how to hack the system to make it
fast-forward the current transaction id?
What I've generally done is to stop the server then use pg_resetxlog
to put the XID counter where I want it. I believe you'll need to
manually
On 7 February 2013 19:15, Jeff Janes jeff.ja...@gmail.com wrote:
On Thu, Feb 7, 2013 at 10:09 AM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
Right. I don't have the database handy at this moment, but earlier in
the day I ran some queries against it and found that most of the
duplicates
Jeff Janes escribió:
On Thu, Feb 7, 2013 at 10:09 AM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
Right. I don't have the database handy at this moment, but earlier in
the day I ran some queries against it and found that most of the
duplicates which are not accessible via indexes have
Hi,
it seems there's a issue in instrument.c that may have significant
performance impact for some plans when running explain analyze with
TIMING OFF.
There's this piece of code in InstrStartNode:
if (instr-need_timer INSTR_TIME_IS_ZERO(instr-starttime))
Kohei KaiGai kai...@kaigai.gr.jp wrote:
So, I'd like to review two options.
1) we uses db_table object class for materialized-views for
a while, until selinux-side become ready. Probably, v9.3 will
use db_table class then switched at v9.4.
2) we uses db_materialized_view object class from
Tomas Vondra t...@fuzzy.cz writes:
There's this piece of code in InstrStartNode:
if (instr-need_timer INSTR_TIME_IS_ZERO(instr-starttime))
INSTR_TIME_SET_CURRENT(instr-starttime);
else
elog(DEBUG2, InstrStartNode called twice in a row);
but it should actually be
Folks,
First, thanks for the serious discussion of this.
There are obvious tooling gaps (aren't there always?), but I don't
really see the model as broken, and I don't think I've been around
pgsql-hackers exclusively or extensively enough to have developed
Stockholm syndrome.
I don't see
On 7.2.2013 01:10, Tom Lane wrote:
The attached patch fixes these things, but not the buggy penalty
function, because we ought to try to verify that these changes are
enough to prevent creation of an incorrect index. I can't reproduce any
misbehavior anymore with this patch applied. However,
Tom Lane t...@sss.pgh.pa.us wrote:
Tomas Vondra tv(at)fuzzy(dot)cz writes:
There's this piece of code in InstrStartNode:
if (instr-need_timer INSTR_TIME_IS_ZERO(instr-starttime))
INSTR_TIME_SET_CURRENT(instr-starttime);
else
elog(DEBUG2, InstrStartNode called twice
Tomas Vondra t...@fuzzy.cz writes:
Tom Lane t...@sss.pgh.pa.us wrote:
A bigger question is why this is elog(DEBUG2) and not elog(ERROR).
Had it been the latter, we'd have noticed the mistake immediately.
The current choice might be masking any caller-logic errors that
exist, too.
Not sure
Tomas Vondra t...@fuzzy.cz writes:
I can't reproduce any of the issues anymore - I've tested both 9.2 and
9.3 branches (both containing the already commited fixes). And not only
that the issues seem to be gone, but I'm actually getting significantly
better performance.
Cool. I noticed that
Alvaro Herrera escribió:
Alvaro Herrera escribió:
Hm, if the foreign key patch is to blame, this sounds like these tuples
had a different set of XMAX hint bits and a different Xmax, and they
were clobbered by something like vacuum or page pruning.
Hm, I think heap_freeze_tuple is
-Original Message-
From: pgsql-jdbc-ow...@postgresql.org
[mailto:pgsql-jdbc-ow...@postgresql.org] On Behalf Of Marc G. Fournier
I'm trying to use enum's in a database, but the java guys are telling me that
they are having problems with inserts ...
reading from the database isn't a
Alvaro Herrera alvhe...@2ndquadrant.com writes:
xid = HeapTupleHeaderGetRawXmax(tuple);
! if (((tuple-t_infomask HEAP_XMAX_IS_MULTI)
! MultiXactIdIsValid(xid)
! MultiXactIdPrecedes(xid, cutoff_multi)) ||
! ((!(tuple-t_infomask
Tom Dunstan pg...@tomd.cc writes:
... That works ok, but when attempting to use a prepared statement:
ps = con.prepareStatement(insert into enumcast values (?));
ps.setString(1, meh);
ps.executeUpdate();
we get a
org.postgresql.util.PSQLException: ERROR: column current_mood is
Robert Haas robertmh...@gmail.com writes:
On Thu, Feb 7, 2013 at 6:42 AM, Simon Riggs si...@2ndquadrant.com wrote:
IMO the way to resolve that conflict is with a behaviour parameter to
allow people to choose, rather than be forced to wait a year because
some people still run an old version of
I found a comment typo. Please find attached a patch.
Best regards,
Etsuro Fujita
comment_typo.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hello all and Heikki personally
Thank you for your answer
I have some new points:
21.01.2013, 10:08 +02:00 от Heikki Linnakangas hlinnakan...@vmware.com:
On 21.01.2013 09:14, Миша Тюрин wrote:
Is there any reason why pg_basebackup has limitation in an online backup
from the standby: The
58 matches
Mail list logo
