On Fri, Feb 15, 2013 at 08:24:16PM -0500, Robert Haas wrote:
> On Fri, Feb 15, 2013 at 8:01 PM, Kevin Grittner wrote:
> > There is one odd aspect to pg_dump, but I think the way it is
> > behaving is the best way to handle it, although I invite other
> > opinions. If you load from pg_dump output,
(2013/02/15 1:55), Robert Haas wrote:
> On Tue, Feb 12, 2013 at 10:22 AM, Satoshi Nagayasu wrote:
>> (1) Fix pgstatindex arguments to work same as pgstattuple.
>>
>> As the document describes, pgstattuple accepts 'schema.table'
>> expression and oid of the table, but pgstatindex doesn't.
>> (becau
On Fri, Feb 15, 2013 at 8:01 PM, Kevin Grittner wrote:
> There is one odd aspect to pg_dump, but I think the way it is
> behaving is the best way to handle it, although I invite other
> opinions. If you load from pg_dump output, it will try to
> populated materialized views which were populated o
On Thu, Feb 14, 2013 at 3:39 PM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> Wait, I'm confused. I had a note to myself to come back and review
>> this, but now that I look at it, I didn't think that patch was pending
>> review. Alvaro, Tom, and I all made comments that seems to impinge
>>
On Fri, Feb 15, 2013 at 9:28 PM, Peter Eisentraut wrote:
> On 2/14/13 2:42 PM, Marko Tiikkaja wrote:
>>> I think the reason this doesn't work is that in order to prepare a query
>>> you need to know the parameter types, but you don't know that in Python,
>>> or at least with the way the DB-API wor
On 2/14/13 2:42 PM, Marko Tiikkaja wrote:
>> I think the reason this doesn't work is that in order to prepare a query
>> you need to know the parameter types, but you don't know that in Python,
>> or at least with the way the DB-API works. For example, if you write
>>
>> cur.execute("SELECT * FROM
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 15/02/2013 02:45, Andrew McNamara ha scritto:
>> For my Python DBAPI2 PostgreSQL driver I plan the following optimizations:
>
> I suggest you have a look at my Python ocpgdb driver:
>
> http://code.google.com/p/ocpgdb/
>
Thanks, I did not kn
On Feb 15, 2013, at 9:25 AM, Robert Haas wrote:
> I realize I'm in the minority here, but -1 from me on all of this.
> Should we also rename xml_is_well_formed() to just is_well_formed()?
That would be nice, but I think that ship done sunk.
> string_agg() to agg()?
Would love a different name,
>
> Josh Berkus wrote:
>> Folks,
>>
>> Once again, Google is holding Summer of Code. We need to assess whether
>> we want to participate this year.
>>
>> Questions:
>>
>> - Who wants to mentor for GSOC?
I am open to being a mentor too.
Saludos,
Gilberto Castillo
La Habana, Cuba
---
This messa
On 15.2.2013 16:38, Alvaro Herrera wrote:
> Tomas Vondra escribió:
>
>> On 14.2.2013 20:23, Alvaro Herrera wrote:
>
>>> The problem here is that creating these dummy entries will cause a
>>> difference in autovacuum behavior. Autovacuum will skip processing
>>> databases with no pgstat entry, an
I would love to mentor if anybody would be willing to take a project in it.
Atri
Sent from my iPad
On 15-Feb-2013, at 23:04, Josh Berkus wrote:
> On 02/15/2013 06:03 AM, Atri Sharma wrote:
>> Can't we have something related to machine learning? I was thinking of
>> extending a technique where
On 15 February 2013 16:10, Fujii Masao wrote:
>> I propose the attached patch to fix it.
>
> At least in 9.2, when the archived file is restored into pg_xlog, its xxx.done
> archive status file is created. So we don't need to check InArchiveRecovery
> when deleting old WAL files. Checking whether
On 1/25/13 1:00 AM, Kevin Grittner wrote:
> New patch rebased, fixes issues raised by Thom Brown, and addresses
> some of your points.
This patch doesn't apply anymore, so I just took a superficial look. I
think the intended functionality and the interfaces look pretty good.
Documentation looks c
On Fri, Feb 15, 2013 at 3:12 PM, Pavan Deolasee
wrote:
> (changing subject)
>
> On Thu, Feb 14, 2013 at 11:48 PM, Fujii Masao wrote:
>> On Mon, Feb 11, 2013 at 5:46 PM, Pavan Deolasee
>>> I also noticed that the WAL file switch
>>> happens after archive_timeout seconds irrespective of whether
>>>
On 15.02.2013 19:16, Fujii Masao wrote:
On Sat, Feb 16, 2013 at 2:07 AM, Heikki Linnakangas
wrote:
On 15.02.2013 18:10, Fujii Masao wrote:
At least in 9.2, when the archived file is restored into pg_xlog, its
xxx.done
archive status file is created. So we don't need to check
InArchiveRecover
On 02/15/2013 06:03 AM, Atri Sharma wrote:
> Can't we have something related to machine learning? I was thinking of
> extending a technique where we can fill in some missing values in a data set
> for the user if he wants us to using some standard ml algorithms.
Take a look at MADLib. My sugges
On 15 February 2013 17:07, Heikki Linnakangas wrote:
>> Unfortunately in HEAD, xxx.done file is not created when restoring
>> archived
>> file because of absence of the patch. We need to implement that first.
>
>
> Ah yeah, that thing again..
> (http://www.postgresql.org/message-id/50df5ba7.6070.
On Tue, Feb 12, 2013 at 2:18 PM, David E. Wheeler wrote:
> Hello Hackers,
>
> If you dislike bike-shedding (and who does?), delete this email and the
> ensuing thread right now. You have been warned!
>
> I have been playing with Andrew’s JSON enhancements and really enjoying them.
> I am already
On Sat, Feb 16, 2013 at 2:07 AM, Heikki Linnakangas
wrote:
> On 15.02.2013 18:10, Fujii Masao wrote:
>>
>> On Fri, Feb 15, 2013 at 11:31 PM, Heikki Linnakangas
>> wrote:
- /*
- * Normally we don't delete old XLOG files during recovery to
- * avoid accidentally delet
On Thu, Feb 14, 2013 at 07:21:27PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Agreed. The attached patch modifies pg_check_dir() to report about
> > invisible and lost+found directory entries, and give more helpful
> > messages to the user.
>
> I'm not terribly thrilled with special-casi
On Sun, Dec 30, 2012 at 6:07 AM, Heikki Linnakangas
wrote:
> On 02.10.2012 21:20, Fujii Masao wrote:
>>
>> On Wed, Oct 3, 2012 at 3:11 AM, Simon Riggs wrote:
>>>
>>> but its not high on my radar
>>>
>>> right now unless you can explain why it should be higher.
>>
>>
>> It may not be high, but I'm
On 15.02.2013 18:10, Fujii Masao wrote:
On Fri, Feb 15, 2013 at 11:31 PM, Heikki Linnakangas
wrote:
- /*
- * Normally we don't delete old XLOG files during recovery to
- * avoid accidentally deleting a file that looks stale due to a
- * bug or hardware issue, but in fact contains import
On Fri, Feb 15, 2013 at 11:31 PM, Heikki Linnakangas
wrote:
> On 14.02.2013 17:45, Jehan-Guillaume de Rorthais wrote:
>>
>> I am facing an unexpected behavior on a 9.2.2 cluster that I can
>> reproduce on current HEAD.
>>
>> On a cluster with archive enabled but failing, after a crash of
>> postma
On 15.02.2013 17:12, Simon Riggs wrote:
On 15 February 2013 14:31, Heikki Linnakangas wrote:
- /*
- * Normally we don't delete old XLOG files during recovery to
- * avoid accidentally deleting a file that looks stale due to a
- * bug or hardware issue, but in fact contains important data
Tomas Vondra escribió:
> On 14.2.2013 20:23, Alvaro Herrera wrote:
> > The problem here is that creating these dummy entries will cause a
> > difference in autovacuum behavior. Autovacuum will skip processing
> > databases with no pgstat entry, and the intended reason is that if
> > there's no p
On 15 February 2013 14:31, Heikki Linnakangas wrote:
> On 14.02.2013 17:45, Jehan-Guillaume de Rorthais wrote:
>>
>> I am facing an unexpected behavior on a 9.2.2 cluster that I can
>> reproduce on current HEAD.
>>
>> On a cluster with archive enabled but failing, after a crash of
>> postmaster, t
Hello, Josh.
You wrote:
JB> Folks,
JB> Once again, Google is holding Summer of Code. We need to assess whether
JB> we want to participate this year.
JB> Questions:
JB> - Who wants to mentor for GSOC?
JB> - Who can admin for GSOC? Thom?
JB> - Please suggest project ideas for GSOC
My sugges
Pavan Deolasee writes:
> I noticed you added a pre event for commit/prepare/subcommit. That
> looks good. Is there a case to add it for abort/subabort too ? I
> wonder if we would want to do some cleanup on the foreign servers
> before the transaction is abort-recorded on the main server.
I don't
On 14.02.2013 17:45, Jehan-Guillaume de Rorthais wrote:
I am facing an unexpected behavior on a 9.2.2 cluster that I can
reproduce on current HEAD.
On a cluster with archive enabled but failing, after a crash of
postmaster, the checkpoint occurring before leaving the recovery mode
deletes any ad
Can't we have something related to machine learning? I was thinking of
extending a technique where we can fill in some missing values in a data set
for the user if he wants us to using some standard ml algorithms.
Atri
Sent from my iPad
On 15-Feb-2013, at 19:26, Heikki Linnakangas wrote:
> O
On 15.02.2013 14:29, Sîrbu Nicolae-Cezar wrote:
Hello,
Can you guys send me a link to a where to start page ?
Take a look at the Project Ideas page from last year, and the project
TODO list. See http://www.postgresql.org/developer/summerofcode/#ideas.
One approach is to pick a research pape
On 15.02.2013 13:05, Ants Aasma wrote:
On Wed, Feb 13, 2013 at 10:52 PM, Simon Riggs wrote:
The problem is that we startup Hot Standby before we hit the min
recovery point because that isn't recorded. For me, the thing to do is
to make the min recovery point == end of WAL when state is
DB_IN_PR
Hello,
I'm also interested in this topic.
> > I'm also interested in this topic and work on system-time temporal
> > extension. Here I wrote down design of my solution few months ago
> > https://wiki.postgresql.org/wiki/SQL2011Temporal. The idea is
> > basically the same as in your solution wi
On Fri, Feb 15, 2013 at 2:51 PM, Dimitri Fontaine wrote:
> Alvaro Herrera writes:
> >> - Who wants to mentor for GSOC?
> >
> > I am open to being a mentor.
>
> Me too.
>
I'm ready for mentoring too. And I will encourage students in my university
to apply proposals to PostgreSQL.
--
With bes
Hello,
Can you guys send me a link to a where to start page ?
Thanks,
Sirbu Nicolae-Cezar
On Wed, Feb 13, 2013 at 10:52 PM, Simon Riggs wrote:
> The problem is that we startup Hot Standby before we hit the min
> recovery point because that isn't recorded. For me, the thing to do is
> to make the min recovery point == end of WAL when state is
> DB_IN_PRODUCTION. That way we don't need t
Alvaro Herrera writes:
>> - Who wants to mentor for GSOC?
>
> I am open to being a mentor.
Me too.
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
> On Friday, February 15, 2013 2:03 PM Kyotaro HORIGUCHI wrote:
> Hello,
>
> I've read the discussion held so far and am satisfied that apply
> this patch only for Result node. I applied the patch and found
> that it worked pretty fine for me.
>
> Thank you and I also think that we may send this
Sorry, I omitted to show how we found this issue.
In HA DB cluster cosists of Pacemaker and PostgreSQL, PostgreSQL
is stopped by 'pg_ctl stop -m i' regardless of situation.
On the other hand, PosrgreSQL RA(Rsource Agent) is obliged to
start the master node via hot standby state because of the
res
Hello,
I've read the discussion held so far and am satisfied that apply
this patch only for Result node. I applied the patch and found
that it worked pretty fine for me.
Thank you and I also think that we may send this to committers.
# It makes me fee ill at ease that the roles of us look invert
40 matches
Mail list logo
