On Thu, Sep 6, 2012 at 3:04 AM, Noah Misch n...@leadboat.com wrote:
On Tue, Sep 04, 2012 at 09:46:58AM -0700, Daniel Farina wrote:
I might try to find the segments leading up to the overflow point and
try xlogdumping them to see what we can see.
That would be helpful to see.
Just to grasp
Pavan Deolasee wrote:
I'm looking at the following code in pg_dump.c
/*
* Start transaction-snapshot mode transaction to dump
* consistent data.
*/
ExecuteSqlStatement(fout, BEGIN);
if (fout-remoteVersion = 90100)
{
if (serializable_deferrable)
On Fri, Sep 07, 2012 at 01:37:57AM -0700, Daniel Farina wrote:
On Thu, Sep 6, 2012 at 3:04 AM, Noah Misch n...@leadboat.com wrote:
On Tue, Sep 04, 2012 at 09:46:58AM -0700, Daniel Farina wrote:
I might try to find the segments leading up to the overflow point and
try xlogdumping them to see
On Thu, Sep 6, 2012 at 1:06 AM, Andrew Dunstan and...@dunslane.net wrote:
On 09/05/2012 06:13 PM, Peter Eisentraut wrote:
On 8/29/12 11:52 PM, Andrew Dunstan wrote:
Why does this need to be tied into the build farm? Someone can surely
set up a script that just runs the docs build at every
On Thursday, September 06, 2012 9:58 PM Josh Berkus wrote:
On 9/6/12 7:06 AM, Amit Kapila wrote:
1.Set up postgresql-9.2beta2 on all hosts.
Did you retest this with 9.2rc1? Beta2 was a while ago
Tested in 9.2rc1, the problem occurs incase I use database and backup of 9.2
On 09/07/2012 09:57 AM, Magnus Hagander wrote:
On Thu, Sep 6, 2012 at 1:06 AM, Andrew Dunstan and...@dunslane.net wrote:
A complete run of this process takes less than 15 minutes. And as I have
pointed out elsewhere that could be reduced substantially by skipping
certain steps. It's as simple
Heikki Linnakangas hlinn...@iki.fi writes:
Would socketpair(2) be simpler?
Attached is a revised version of the patch that uses socketpair(2).
This is definitely a lot less invasive --- the backend side of the
patch, in particular, is far shorter, and there are fewer portability
hazards since
On 9/6/12 8:56 PM, Alvaro Herrera wrote:
Excerpts from Peter Eisentraut's message of jue sep 06 21:33:33 -0300 2012:
I have developed a patch to make the python3 regression test setup a bit
simpler. Currently, we are making mangled copies of
plpython/{expected,sql} to
(Adding -hackers. Did not realize it got dropped)
On Fri, Sep 7, 2012 at 11:25 PM, Gezeala M. Bacuño II geze...@gmail.comwrote:
On Fri, Sep 7, 2012 at 7:17 AM, Pavan Deolasee pavan.deola...@gmail.com
wrote:
On Fri, Sep 7, 2012 at 7:00 PM, Marie Bacuno II geze...@gmail.com
wrote:
adding pgsql-bugs list in case OP posts back.
On Fri, Sep 7, 2012 at 11:29 AM, Pavan Deolasee
pavan.deola...@gmail.com wrote:
(Adding -hackers. Did not realize it got dropped)
On Fri, Sep 7, 2012 at 11:25 PM, Gezeala M. Bacuño II geze...@gmail.com
wrote:
On Fri, Sep 7, 2012 at 7:17 AM,
On Fri, Sep 7, 2012 at 5:49 AM, Noah Misch n...@leadboat.com wrote:
On Fri, Sep 07, 2012 at 01:37:57AM -0700, Daniel Farina wrote:
On Thu, Sep 6, 2012 at 3:04 AM, Noah Misch n...@leadboat.com wrote:
On Tue, Sep 04, 2012 at 09:46:58AM -0700, Daniel Farina wrote:
I might try to find the
Excerpts from Andrew Dunstan's message of vie sep 07 13:50:44 -0300 2012:
There is a filter mechanism used in detecting is a run is needed, and in
modern versions of the client (Release 4.7, one version later than
guaibasaurus is currently using) it lets you have both include and
exclude
On 07.09.2012 10:49, Tom Lane wrote:
Heikki Linnakangashlinn...@iki.fi writes:
Would socketpair(2) be simpler?
Attached is a revised version of the patch that uses socketpair(2).
This is definitely a lot less invasive --- the backend side of the
patch, in particular, is far shorter, and
Heikki Linnakangas hlinn...@iki.fi writes:
It's worth noting that now that libpq constructs the command line to
execute postgres --child= -D datadir, we'll be stuck with that set
of arguments forever, because libpq needs to be able to talk to
different versions. Or at least we'd need to
Heikki Linnakangas hlinn...@iki.fi writes:
On 07.09.2012 10:49, Tom Lane wrote:
I'm a bit tempted though to pull out and apply the portions of the
patch that replace libpq's assorted ad-hoc closesocket() calls with
a centralized pqDropConnection routine. I think that's probably a good
idea
On Thu, Sep 6, 2012 at 12:56 PM, Jeff Davis pg...@j-davis.com wrote:
On Wed, 2012-09-05 at 17:03 -0400, Tom Lane wrote:
In general I think the selling point for such a feature would be no
administrative hassles, and I believe that has to go not only for the
end-user experience but also for the
On Friday, September 07, 2012 11:21:00 PM Merlin Moncure wrote:
On Thu, Sep 6, 2012 at 12:56 PM, Jeff Davis pg...@j-davis.com wrote:
On Wed, 2012-09-05 at 17:03 -0400, Tom Lane wrote:
In general I think the selling point for such a feature would be no
administrative hassles, and I believe
On 9/2/12 7:23 PM, Tom Lane wrote:
4. As coded, the backend assumes the incoming pipe is on its FD 0 and the
outgoing pipe is on its FD 1. This made the command line simple but I'm
having second thoughts about it: if anything inside the backend tries to
read stdin or write stdout, unpleasant
On 09/04/2012 08:51 PM, Andrew Dunstan wrote:
On 09/04/2012 08:37 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Frankly, I have had enough failures of parallel make that I think doing
this would generate a significant number of non-repeatable failures (I
had one just the
Andrew Dunstan and...@dunslane.net writes:
Well, it looks like it's always failing on ecpg, with preproc.h not
being made in the right order. Here is the last bit of a make log
starting from when it starts on ecpg. This is pretty repeatable.
Hmph. I can't reproduce it at all on my Fedora 16
On Wed, Sep 5, 2012 at 10:29 PM, Andrew Dunstan and...@dunslane.net wrote:
On 09/05/2012 10:14 PM, Tom Lane wrote:
The people who would be interested in this are currently using something
like SQLite within a single application program.
Exactly. I think it's worth stating that this has
On 09/07/2012 08:43 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Well, it looks like it's always failing on ecpg, with preproc.h not
being made in the right order. Here is the last bit of a make log
starting from when it starts on ecpg. This is pretty repeatable.
Hmph. I
On 09/07/2012 09:55 PM, Andrew Dunstan wrote:
On 09/07/2012 08:43 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Well, it looks like it's always failing on ecpg, with preproc.h not
being made in the right order. Here is the last bit of a make log
starting from when it starts
On 09/07/2012 10:46 PM, Andrew Dunstan wrote:
On 09/07/2012 09:55 PM, Andrew Dunstan wrote:
On 09/07/2012 08:43 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Well, it looks like it's always failing on ecpg, with preproc.h not
being made in the right order. Here is the last
24 matches
Mail list logo