On Fri, Feb 8, 2013 at 2:23 AM, Magnus Hagander wrote:
> On Fri, Feb 8, 2013 at 1:32 AM, Josh Berkus wrote:
>> This is a few too many steps, and certainly appears completely broken to
>> any newcomer.
>
> I agree it's way too many step. Several of those can certainly be made
> more efficient now
>
>
>> Also, the log says "checkpoints are occurring too frequently (0
>> seconds apart)". But that looks wrong too. Checkpoints are really
>> happening at 30 seconds apart and not 0 as the log message claims.
>
> I noticed that as well, and I think it might be a regression. I'll
> run a bisec
Dean Rasheed writes:
> [ alter-rule-rename_complete.v2.patch ]
Committed with assorted editorialization. Aside from cosmetic issues,
the main changes were:
* use RangeVarGetRelidExtended with a callback to perform the lookup
and locking of the target relation. This is a new API that the origin
Amit kapila writes:
>> if (!is_projection_capable_plan(result_plan) &&
>> compare_tlist_exprs(sub_tlist, result_plan->targetlist) )
> Sorry, the check I suggested in last mail should be as below:
> if (!is_projection_capable_plan(result_plan) &&
> !compare_tlist_exprs(sub_tlist, result_plan->t
Saturday, February 09, 2013 6:56 AM Amit kapila wrote:
>Friday, February 08, 2013 11:06 PM Tom Lane wrote:
> >Amit Kapila writes:
>>> On Friday, February 08, 2013 12:00 AM Tom Lane wrote:
>>> As per my understanding, currently in code wherever Result node can be
>>> avoided,
>> Hm. Really there'
Friday, February 08, 2013 11:06 PM Tom Lane wrote:
> Amit Kapila writes:
>> On Friday, February 08, 2013 12:00 AM Tom Lane wrote:
>> As per my understanding, currently in code wherever Result node can be
>> avoided,
>> it calls function is_projection_capable_plan(), so we can even enhance
>> is_p
Alexander Korotkov writes:
> On Sat, Nov 3, 2012 at 4:23 AM, Noah Misch wrote:
>> ... At internal pages, gist_point_consistent() should implement
>> "point <@ box" with an algorithm near-equivalent to box_overlap(). (As an
>> optional deviation, it may use exact comparisons despite box_overlap(
Peter Eisentraut writes:
> On 2/8/13 12:21 PM, Tom Lane wrote:
>> Over in Fedora-land they're trying to institute support for ARM64,
>> which among other things means autoconf 2.69 or later:
>> http://lists.fedoraproject.org/pipermail/devel/2013-February/178273.html
> What they actually mean is t
Jeff Janes escribió:
> commit 381d4b70a9854a7b5b9f12d828a0824f8564f1e7 introduced some
> compiler warnings:
>
> assert.c:26: warning: no previous prototype for 'ExceptionalCondition'
> elog.c: In function 'pg_re_throw':
> elog.c:1628: warning: implicit declaration of function 'ExceptionalCondition
Kohei KaiGai wrote:
> I'll adjust contrib/sepgsql portion to fit materialized-view with
> matter of existing view.
OK. In case it is of any use to you as a starting point, attached
is what I originally had, which seems to be similar to what you
describe as your preference. I'll revert everythi
commit 381d4b70a9854a7b5b9f12d828a0824f8564f1e7 introduced some
compiler warnings:
assert.c:26: warning: no previous prototype for 'ExceptionalCondition'
elog.c: In function 'pg_re_throw':
elog.c:1628: warning: implicit declaration of function 'ExceptionalCondition'
elog.c:1630: warning: 'noreturn
On Fri, Feb 8, 2013 at 1:43 PM, Phil Sorber wrote:
> On Fri, Feb 8, 2013 at 10:20 AM, Peter Eisentraut wrote:
>> On 2/8/13 5:23 AM, Magnus Hagander wrote:
>>> But do you have any actual proof that the problem is in "we
>>> loose reviewers because we're relying on email"?
>>
>> Here is one: Me.
>>
Jeff Janes escribió:
> On Fri, Feb 8, 2013 at 2:23 AM, Magnus Hagander wrote:
> > On Fri, Feb 8, 2013 at 1:32 AM, Josh Berkus wrote:
> >>
> >> 8. Send it to pgsql-hackers
> >> 8.a. this requires you to be subscribed to pgsql-hackers.
> >
> > No, it does not. It will get caught in the moderation q
On Fri, Feb 8, 2013 at 2:23 AM, Magnus Hagander wrote:
> On Fri, Feb 8, 2013 at 1:32 AM, Josh Berkus wrote:
>>
>> 8. Send it to pgsql-hackers
>> 8.a. this requires you to be subscribed to pgsql-hackers.
>
> No, it does not. It will get caught in the moderation queue and get
> slightly delayed if
On Fri, Feb 8, 2013 at 7:20 AM, Peter Eisentraut wrote:
> On 2/8/13 5:23 AM, Magnus Hagander wrote:
>> But do you have any actual proof that the problem is in "we
>> loose reviewers because we're relying on email"?
>
> Here is one: Me.
>
> Just yesterday I downloaded a piece of software that was p
On Fri, Feb 8, 2013 at 10:20 AM, Peter Eisentraut wrote:
> On 2/8/13 5:23 AM, Magnus Hagander wrote:
>> But do you have any actual proof that the problem is in "we
>> loose reviewers because we're relying on email"?
>
> Here is one: Me.
>
> Just yesterday I downloaded a piece of software that was
I thought this might be of interest...
http://blog.documentfoundation.org/2013/02/07/the-document-foundation-announces-libreoffice-4-0/
[...]
Improved code contribution thanks to Gerrit: a web based code review
system, facilitating the task for projects using Git version control
system (althoug
Hello,
I'd like to submit the following patch that extends backup.sgml with a bit of
practical but important information.
Project: postgresql
Patch filename: backup.sgml-cmd-v001.patch
The patch extends backup.sgml and adds practical information on custom format
backups approach. Basically, we
On 2/8/13 12:21 PM, Tom Lane wrote:
> Over in Fedora-land they're trying to institute support for ARM64,
> which among other things means autoconf 2.69 or later:
> http://lists.fedoraproject.org/pipermail/devel/2013-February/178273.html
>
> We are behind the curve.
What they actually mean is that
Peter Eisentraut writes:
> On 2/8/13 10:58 AM, Tom Lane wrote:
>> ... I don't object to people using their
>> tools-of-choice to perform reviewing, but we need some way of making
>> sure that the reviews get archived.
> Gerrit sends me an email every times something happens, so I think this
> is
On 2/8/13 10:58 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> I suggest, build it and they will come, or not. Let people push their
>> patches into Gerrit and attach the reviews to the commit fest items. If
>> reviewers then want to use that, it's their choice. We'll see how it goes.
>
> I
Andrew Dunstan wrote:
>
> On 02/08/2013 12:21 PM, Tom Lane wrote:
> >Over in Fedora-land they're trying to institute support for ARM64,
> >which among other things means autoconf 2.69 or later:
> >http://lists.fedoraproject.org/pipermail/devel/2013-February/178273.html
>
> Is there any good reaso
On 02/08/2013 10:09 AM, Tom Lane wrote:
Adrian Klaver writes:
I am not sure I am following. Are we talking two different cases here?
What I was pointing out was that the non-superuser case seems to be
broken almost completely, whereas the superuser case is only broken
if the object owner has
Adrian Klaver writes:
> I am not sure I am following. Are we talking two different cases here?
What I was pointing out was that the non-superuser case seems to be
broken almost completely, whereas the superuser case is only broken
if the object owner has given away some grant options and those ha
On Fri, Feb 8, 2013 at 12:46 PM, Fujii Masao wrote:
> No maybe. But I think that all the client commands should follow the
> same rule. Otherwise a user would get confused when specifying
> options.
I would consider the rest of the apps using it as a consensus. I will
make sure it aligns in behav
On Wed, Feb 6, 2013 at 7:26 AM, Miroslav Šimulčík
wrote:
>> Alternately, you might be able to use a custom GUC from a rather smaller
>> PL/PgSQL function. At transaction start, issue:
>>
>> set_config('myapp.trigger_time', '', 't');
>
>
> This is problem with using custom GUC - clearing variab
That would seem to be the implication. JDBC wouldn't really know anything
about hstore.
Dave Cramer
dave.cramer(at)credativ(dot)ca
http://www.credativ.ca
On Fri, Feb 8, 2013 at 12:51 PM, Andrew Dunstan wrote:
>
> On 02/08/2013 12:41 PM, Kris Jurka wrote:
>
>>
>> On Fri, 8 Feb 2013, Dave Crame
>> I don't see the model as broken either. Just the tooling, which is why
>> I'm looking at tooling. As in, I'm looking for better tooling in order
>
> Yet you are suggesting tooling that requires a change in the model?
Well, my fantasy is a version of Gerrit which accepts email from
-hackers
On Fri, Feb 8, 2013 at 6:53 PM, Robert Haas wrote:
> On Fri, Feb 8, 2013 at 11:09 AM, Kevin Grittner wrote:
>> Magnus Hagander wrote:
>>
>>> if there is any other committer who [wants to receive emails from
>>> the packagers list], let me know and I will add you there as well.
>>
>> Hi Magnus,
>
On Fri, Feb 8, 2013 at 11:09 AM, Kevin Grittner wrote:
> Magnus Hagander wrote:
>
>> if there is any other committer who [wants to receive emails from
>> the packagers list], let me know and I will add you there as well.
>
> Hi Magnus,
>
> Please add me.
>
> Thanks,
>
> -Kevin
Ditto.
--
Robert
On 02/08/2013 09:09 AM, Tom Lane wrote:
Adrian Klaver writes:
On 02/08/2013 08:14 AM, Tom Lane wrote:
Of course, postgres has other options besides that, of which "DROP OWNED
BY ak02" is probably the most appropriate here. Or if you really want
to get rid of just that grant, SET ROLE TO akret
On 02/08/2013 12:41 PM, Kris Jurka wrote:
On Fri, 8 Feb 2013, Dave Cramer wrote:
Would this be an postgresql specific escape sequence ? I don't think the
spec allows for this does it ?
Yes, this would be a postgresql jdbc driver specific escape. The spec
doesn't have a concept of private e
On Thu, Feb 7, 2013 at 2:14 AM, Phil Sorber wrote:
> On Wed, Feb 6, 2013 at 11:36 AM, Fujii Masao wrote:
>> On Thu, Feb 7, 2013 at 1:15 AM, Phil Sorber wrote:
>>> On Wed, Feb 6, 2013 at 11:11 AM, Fujii Masao wrote:
On Thu, Feb 7, 2013 at 12:05 AM, Phil Sorber wrote:
> On Tue, Feb 5, 2
On Fri, 8 Feb 2013, Dave Cramer wrote:
> Would this be an postgresql specific escape sequence ? I don't think the
> spec allows for this does it ?
>
Yes, this would be a postgresql jdbc driver specific escape. The spec
doesn't have a concept of private escape sequences, but that doesn't see
Hi all
I've got suspicious behavior for transaction cooked with deferrable trigger.
if trigger has update on row of his target table we get infinite "recursion"
without limitation of stack depth.
trigger -> update -> trigger -> update -> ... ... -- infinite pending list :)
- Misha
On 02/08/2013 07:58 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> I suggest, build it and they will come, or not. Let people push their
>> patches into Gerrit and attach the reviews to the commit fest items. If
>> reviewers then want to use that, it's their choice. We'll see how it goes.
>
Amit Kapila writes:
> On Friday, February 08, 2013 12:00 AM Tom Lane wrote:
> As per my understanding, currently in code wherever Result node can be
> avoided,
> it calls function is_projection_capable_plan(), so we can even enhance
> is_projection_capable_plan()
> so that it can also verify the
On 02/08/2013 12:21 PM, Tom Lane wrote:
Over in Fedora-land they're trying to institute support for ARM64,
which among other things means autoconf 2.69 or later:
http://lists.fedoraproject.org/pipermail/devel/2013-February/178273.html
We are behind the curve.
Is the
Over in Fedora-land they're trying to institute support for ARM64,
which among other things means autoconf 2.69 or later:
http://lists.fedoraproject.org/pipermail/devel/2013-February/178273.html
We are behind the curve.
regards, tom lane
--
Sent via pgsql-hackers mailin
Adrian Klaver writes:
> On 02/08/2013 08:14 AM, Tom Lane wrote:
>> Of course, postgres has other options besides that, of which "DROP OWNED
>> BY ak02" is probably the most appropriate here. Or if you really want
>> to get rid of just that grant, SET ROLE TO akretschmer01 and revoke.
> The DROP
On Thu, Feb 7, 2013 at 8:38 PM, Alvaro Herrera wrote:
> 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 li
On Fri, Feb 8, 2013 at 2:37 AM, Pavan Deolasee wrote:
> I was looking at the vacuum/visibility bug that Jeff Janes reported
> and brought up the server with the data directory he has shared. With
> his configuration,
>
> 3092 2013-02-08 02:30:31.327 PST:LOG: checkpoints are occurring too
>
On Fri, Feb 8, 2013 at 7:37 PM, Pavan Deolasee wrote:
> I wonder if this is all expected. The database is getting ZERO
> activity. There are no connections open at this time. The checkpoints
> are happening at every 30 seconds and new WAL files are being created,
> AFAIK because the old ones are g
On Fri, Feb 8, 2013 at 11:43 AM, Kris Jurka wrote:
>
>
> On Wed, 6 Feb 2013, Seamus Abshere wrote:
>
> > I personally don't know of any way around the conflict except changing
> > JDBC or hstore, and I don't think JDBC is gonna change.
> >
>
> I think changing JDBC is the way to go. Currently JD
On Wed, 6 Feb 2013, Seamus Abshere wrote:
> I personally don't know of any way around the conflict except changing
> JDBC or hstore, and I don't think JDBC is gonna change.
>
I think changing JDBC is the way to go. Currently JDBC supports escape
sequences for cross database portability and
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> How would this go with PostgreSQL? You can use the bug form on the web
> site, but you can't attach any code, so the bug will just linger and
> ultimately put more burden on a core contributor to deal with the
> minutiae of developing, testin
Magnus Hagander wrote:
> if there is any other committer who [wants to receive emails from
> the packagers list], let me know and I will add you there as well.
Hi Magnus,
Please add me.
Thanks,
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On 02/08/2013 02:37 AM, Pavan Deolasee wrote:
I wonder if this is all expected. The database is getting ZERO
activity. There are no connections open at this time. The checkpoints
are happening at every 30 seconds and new WAL files are being created,
AFAIK because the old ones are getting archiv
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> The problem with doing it in-house is that the folks who can work on it
> and maintain it will be taking time away from developing PostgreSQL.
Not sure that using Gerrit solves this. Someone will need to install it,
maintain it, document, an
Peter Eisentraut writes:
> I suggest, build it and they will come, or not. Let people push their
> patches into Gerrit and attach the reviews to the commit fest items. If
> reviewers then want to use that, it's their choice. We'll see how it goes.
I might be misunderstanding what you're sugges
Tom Lane escribió:
> Alvaro Herrera writes:
> > xid = HeapTupleHeaderGetRawXmax(tuple);
> > ! if (((tuple->t_infomask & HEAP_XMAX_IS_MULTI) &&
> > !MultiXactIdIsValid(xid) &&
> > !MultiXactIdPrecedes(xid, cutoff_multi)) ||
> > ! ((!(tuple->t_infomask & HEAP_
On Fri, Feb 8, 2013 at 4:20 PM, Peter Eisentraut wrote:
> On 2/8/13 5:23 AM, Magnus Hagander wrote:
>> But do you have any actual proof that the problem is in "we
>> loose reviewers because we're relying on email"?
>
> Here is one: Me.
>
> Just yesterday I downloaded a piece of software that was p
Marti Raudsepp writes:
> The 9.2.3 release notes say:
> * Fix pg_upgrade's -O/-o options (Bruce Momjian)
> You got it the wrong way around, he was the one who introduced the bug! ;)
Sorry about that. The release notes are made based on commit-log
entries. In this case we had
Author: Bruce Mom
On 2/8/13 5:23 AM, Magnus Hagander wrote:
> But do you have any actual proof that the problem is in "we
> loose reviewers because we're relying on email"?
Here is one: Me.
Just yesterday I downloaded a piece of software that was previously
unknown to me from GitHub and found a bug. Within 15 min
On 2/6/13 4:07 PM, Josh Berkus wrote:
> I think one of them has, now: Gerrit. http://code.google.com/p/gerrit/
I find Gerrit pretty useful, and I would support trying it out.
I suggest, build it and they will come, or not. Let people push their
patches into Gerrit and attach the reviews to the
Pavan Deolasee escribió:
> I'm trying to reason how this bug explains what we saw. In the test,
> we'd left with duplicate tuples. If I just take index 219 in the table
> as an example, that tuple had three duplicates. The tuple with CTID
> (150, 126) had the index pointer and the rest two were da
Tom Lane wrote:
>> 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 of type mood bu
2013/2/7 Kevin Grittner :
> 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 o
merlin,
I appreciate your perspective and wish that JDBC didn't present this
problem. Still, with the rapidly growing adoption of both Postgres and
JVM-based languages (thanks Heroku!) - plus the special power of hstore
- I think it would be a shame if such a small accommodation could not be
merlin,
Yes, you're correct, my phrasing was bad: all I meant was that it was a
conflict, not a bug in Postgres or hstore.
I personally don't know of any way around the conflict except changing
JDBC or hstore, and I don't think JDBC is gonna change.
Deciding not to accommodate JDBC on the P
On Friday, February 08, 2013 12:00 AM Tom Lane wrote:
> 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 (wit
On Wed, 2013-01-23 at 12:36 -0500, Phil Sorber wrote:
> I get the following error when I try to compile just a specific binary
> in src/bin/scripts:
>
> gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
> -Wdeclaration-after-statement -Wendif-labels
> -Wmissing-format-attribute -Wformat-security
On Fri, Feb 8, 2013 at 6:49 AM, Etsuro Fujita
wrote:
> I found a comment typo. Please find attached a patch.
Applied, thanks.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
I was looking at the vacuum/visibility bug that Jeff Janes reported
and brought up the server with the data directory he has shared. With
his configuration,
# - Checkpoints -
checkpoint_segments = 1 # in logfile segments, min 1, 16MB each
checkpoint_timeout = 30s# range 30s-1h
# - Ar
On Fri, Feb 8, 2013 at 1:32 AM, Josh Berkus wrote:
> 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 extensi
On 8 February 2013 09:43, Marti Raudsepp wrote:
> No big deal, it was just one space, but I wanted to voice my
> disagreement with how Postgres committers don't retain original patch
> authorship information.
I agree its very important to get that right.
It's important for the PostgreSQL projec
Hi,
The 9.2.3 release notes say:
* Fix pg_upgrade's -O/-o options (Bruce Momjian)
You got it the wrong way around, he was the one who introduced the bug! ;)
I originally found, debugged and provided the fix:
http://www.postgresql.org/message-id/cabrt9rby1urtmy-dfldgbpcp+zqu36m_+bld4wfwugohg-m...
On Fri, Feb 8, 2013 at 10:08 AM, Alvaro Herrera
wrote:
> 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 l
68 matches
Mail list logo
