Hello all and Heikki personally
Thank you for your answer
I have some new points:
21.01.2013, 10:08 +02:00 от Heikki Linnakangas :
>On 21.01.2013 09:14, Миша Тюрин wrote:
>>Is there any reason why pg_basebackup has limitation in an online backup
>> from the standby: "The backup history fi
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
Robert Haas writes:
> On Thu, Feb 7, 2013 at 6:42 AM, Simon Riggs 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
Tom Dunstan 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 o
Alvaro Herrera writes:
> xid = HeapTupleHeaderGetRawXmax(tuple);
> ! if (((tuple->t_infomask & HEAP_XMAX_IS_MULTI) &&
> ! MultiXactIdIsValid(xid) &&
> ! MultiXactIdPrecedes(xid, cutoff_multi)) ||
> ! ((!(tuple->t_infomask & HEAP_XMAX_IS_MULTI)) &&
>
> -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
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
Tomas Vondra 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 it seemed f
Tomas Vondra writes:
> Tom Lane 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 why it's DEBUG2, but if
Tom Lane wrote:
> Tomas Vondra 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
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. Howev
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
Tomas Vondra 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 lik
Kohei KaiGai 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 the
> begining, b
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))
INSTR_TIME_SET_CURRENT
Jeff Janes escribió:
> On Thu, Feb 7, 2013 at 10:09 AM, Pavan Deolasee
> 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 clos
On 7 February 2013 19:15, Jeff Janes wrote:
> On Thu, Feb 7, 2013 at 10:09 AM, Pavan Deolasee
> 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
Jeff Janes 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 create a pg_clog file c
On 2013-02-07 11:15:46 -0800, Jeff Janes wrote:
> On Thu, Feb 7, 2013 at 10:09 AM, Pavan Deolasee
> 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
On Thu, Feb 7, 2013 at 10:09 AM, Pavan Deolasee
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 2100345903. In fact, many
On 6 February 2013 17:43, Simon Riggs 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.
Waiting for fu
Amit Kapila 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()), then remove result
On Thu, Feb 7, 2013 at 10:48 PM, Jeff Janes wrote:
> On Thu, Feb 7, 2013 at 1:44 AM, Pavan Deolasee
> 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 by index LIMIT 3;
>> index | coun
Jeff Janes escribió:
> On Thu, Feb 7, 2013 at 12:55 AM, Pavan Deolasee
> 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 either current head (a
On Thu, Feb 7, 2013 at 9:32 AM, Jeff Janes wrote:
> On Thu, Feb 7, 2013 at 12:55 AM, Pavan Deolasee
> 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
>> corrupted, I tried to REINDEX the table to s
Peter Eisentraut 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 kwlist.h,
On Thu, Feb 7, 2013 at 12:55 AM, Pavan Deolasee
wrote:
> On Thu, Feb 7, 2013 at 11:09 AM, Jeff Janes 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
Tom Lane 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 kind of change
On Thu, Feb 7, 2013 at 1:44 AM, Pavan Deolasee wrote:
> On Thu, Feb 7, 2013 at 2:25 PM, Pavan Deolasee
> 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
On 2/5/13 3:47 PM, Alvaro Herrera wrote:
> Tom Lane wrote:
>> Alvaro Herrera 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 I d
Dimitri Fontaine writes:
> Robert Haas 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 extensions, by the way.
If you're suggest
Robert Haas 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 upgrade to
> $ 9
On 7 February 2013 16:07, Heikki Linnakangas 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 from, in
> addition to th
(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. Wr
Heikki Linnakangas 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
-Kevin
--
Sent
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
Hello, Tom-san, folks,
From: "Tom Lane"
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 wait a few seconds a
Pavan Deolasee escribió:
> On Thu, Feb 7, 2013 at 2:25 PM, Pavan Deolasee
> 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=# s
Hello all and Heikki personally
Thank you for your answer
I have some new points:
Понедельник, 21 января 2013, 10:08 +02:00 от Heikki Linnakangas
:
>On 21.01.2013 09:14, Миша Тюрин wrote:
>>Is there any reason why pg_basebackup has limitation in an online backup
>> from the standby: "Th
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, ExecR
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 Fuji
On Tue, Feb 5, 2013 at 4:39 AM, Albe Laurenz 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 against the possibility
tha
On Thu, Feb 7, 2013 at 6:42 AM, Simon Riggs 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 would be to have a
On Thu, Feb 7, 2013 at 4:04 AM, Heikki Linnakangas
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 more
> thoroughly,
On 6 February 2013 20:31, Robert Haas wrote:
> On Wed, Feb 6, 2013 at 1:06 PM, Simon Riggs wrote:
>> On 6 February 2013 17:43, Robert Haas wrote:
>>> On Mon, Feb 4, 2013 at 3:32 PM, Simon Riggs wrote:
On 4 February 2013 19:53, Robert Haas wrote:
> This seems pretty close to an accusat
On Thu, Feb 7, 2013 at 8:29 AM, Brendan Jurd wrote:
> On 7 February 2013 08:07, Josh Berkus 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. Current major users are OpenStack,
On Thu, Feb 7, 2013 at 8:20 AM, Daniel Farina wrote:
> On Wed, Feb 6, 2013 at 3:00 PM, Joshua D. Drake
> 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 against it. To me, the prob
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 partic
On 7 February 2013 09:04, Heikki Linnakangas 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 more
> thoroughly, to ma
On Thu, Feb 7, 2013 at 2:25 PM, Pavan Deolasee 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 from foo where index IN
On 07.02.2013 10:41, Simon Riggs wrote:
On 6 February 2013 18:02, Robert Haas 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
conclu
On Thu, Feb 7, 2013 at 11:09 AM, Jeff Janes 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
> 692079e5dcb331..168d3157032879
>
>
On 6 February 2013 18:02, Robert Haas 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.
Why would someone w
On 7 February 2013 05:39, Jeff Janes 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
> 692079e5dcb331..168d3157032879
Please de
On Thu, Feb 7, 2013 at 5:15 PM, Andres Freund wrote:
> On 2013-02-07 03:01:36 -0500, Tom Lane wrote:
> > Andres Freund writes:
> > > What about
> >
> > > 3) Use reltoastidxid if != InvalidOid and manually build the list
> (using
> > > RelationGetIndexList) otherwise?
> >
> > Do we actually need r
On Thu, Feb 7, 2013 at 5:01 PM, Tom Lane wrote:
> Andres Freund 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 cas
On 2013-02-07 03:01:36 -0500, Tom Lane wrote:
> Andres Freund 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
Andres Freund 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 some case
for keepi
58 matches
Mail list logo
