I will provide a patch which can exeute pg_start/stop_backup
including to solve above comment and conditions in next stage.
Then please review.
done.
* Procedure
1. Call pg_start_backup('x') on the standby.
2. Take a backup of the data dir.
3. Call pg_stop_backup() on the standby.
4. Copy
2011/8/5 Jun Ishiduka ishizuka@po.ntts.co.jp:
I will provide a patch which can exeute pg_start/stop_backup
including to solve above comment and conditions in next stage.
Then please review.
done.
great !
* Procedure
1. Call pg_start_backup('x') on the standby.
2. Take a backup of
On Thu, Aug 4, 2011 at 10:24 PM, Josh Kupershmidt schmi...@gmail.com wrote:
A few existing backslash commands, such as \dn and maybe \db, don't
exactly follow this precedent. Not sure if we want to bother adjusting
the existing commands to be consistent in this regard. Defining
typical usage
On Thu, Aug 4, 2011 at 11:07 PM, Bruce Momjian br...@momjian.us wrote:
Simon Riggs wrote:
On Thu, Aug 4, 2011 at 10:46 PM, Bruce Momjian br...@momjian.us wrote:
Right. ?I brought up SELECT INTO because you could make the argument
that INSERT ... SELECT is not a utility command like the
On 08/04/2011 11:23 PM, Alex Hunsaker wrote:
On Thu, Aug 4, 2011 at 19:40, Andrew Dunstanand...@dunslane.net wrote:
Let's slow down a bit. Nobody that we know of has encountered the problem
Tom's referring to, over all the years plperlu has been available. The
changes you're proposing have
I think that the first sentence, in the following comment within
GetSnapshotData(), is not quite right, because at the time this is
executed, we already hold ProcArrayLock, which is the only lock that
gets grabbed here:
/*
* If we're in recovery then snapshot data comes from a
I wrote:
Ahh ... you know what, never mind about stack traces, let's just see if
the attached patch doesn't fix it.
On reflection, that patch would only fix the issue for pg_class, and
that's not the only catalog that gets consulted during relcache reloads.
I think we'd better do it as
On Thu, Aug 4, 2011 at 4:49 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
Can we please commit a fix for this problem?
Done.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On Fri, Jul 29, 2011 at 10:09 AM, Robert Haas robertmh...@gmail.com wrote:
2011/7/29 Shigeru Hanada shigeru.han...@gmail.com:
Here is a rebased version of per-column FDW options patch. I've
proposed this patch in last CF, but it was marked as returned with
feedback. So I would like to
On 5 August 2011 17:12, Robert Haas robertmh...@gmail.com wrote:
On Thu, Aug 4, 2011 at 4:49 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
Can we please commit a fix for this problem?
Done.
Thanks Robert.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7
BTW, what is the current status of this patch?
The status of contrib/sepgsql part is unclear for me, although we agreed that
syscache is suitable mechanism for security labels.
Thanks,
2011/7/22 Kohei KaiGai kai...@kaigai.gr.jp:
2011/7/22 Yeb Havinga yebhavi...@gmail.com:
On 2011-07-22 11:55,
Now, apart from the Flex warning, there are just 3 warnings left. They
all look like this:
repl_gram.y:106:30: warning: implicit conversion from enumeration type
'enum ReplNodeTag' to different enumeration type 'NodeTag' (aka 'enum
NodeTag') [-Wconversion]
Peter Geoghegan pe...@2ndquadrant.com writes:
Now, apart from the Flex warning, there are just 3 warnings left. They
all look like this:
repl_gram.y:106:30: warning: implicit conversion from enumeration type
'enum ReplNodeTag' to different enumeration type 'NodeTag' (aka 'enum
NodeTag')
On Fri, Aug 5, 2011 at 2:36 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
BTW, what is the current status of this patch?
I think it's waiting for me to get around to reviewing it. Sorry,
been busy :-(
The status of contrib/sepgsql part is unclear for me, although we agreed that
syscache is
On Thu, 2011-08-04 at 18:07 -0400, Bruce Momjian wrote:
I am confused how generating WAL traffic that is larger than the heap
file we are fsync'ing can possibly be slower. Are you just throwing out
an idea to try to make me prove it?
That's worded in a slightly confusing way, but here is the
On tor, 2011-08-04 at 16:15 -0400, Alvaro Herrera wrote:
Have you considered just cataloging NOT NULL constraints as CHECK
constraints and teaching the reverse parser to convert x CHECK (x IS
NOT NULL) to x NOT NULL.
Hmm, no, I admit I haven't. The current approach was suggested very
On Fri, Aug 05, 2011 at 12:10:31PM -0400, Tom Lane wrote:
I wrote:
Ahh ... you know what, never mind about stack traces, let's just see if
the attached patch doesn't fix it.
On reflection, that patch would only fix the issue for pg_class, and
that's not the only catalog that gets
daveg da...@sonic.net writes:
Should this be applied in addition to the earlier patch, or to replace it?
Apply it instead of the earlier one.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Peter Eisentraut pete...@gmx.net writes:
On tor, 2011-08-04 at 16:15 -0400, Alvaro Herrera wrote:
Yeah, perhaps you're right. The main reason they were considered
separately is that we wanted to have them to be optimized via
pg_attribute.attnotnull, but my patch does away with the need for
Excerpts from Tom Lane's message of vie ago 05 21:23:41 -0400 2011:
Peter Eisentraut pete...@gmx.net writes:
On tor, 2011-08-04 at 16:15 -0400, Alvaro Herrera wrote:
Yeah, perhaps you're right. The main reason they were considered
separately is that we wanted to have them to be optimized
Jeff Davis wrote:
On Thu, 2011-08-04 at 18:07 -0400, Bruce Momjian wrote:
I am confused how generating WAL traffic that is larger than the heap
file we are fsync'ing can possibly be slower. Are you just throwing out
an idea to try to make me prove it?
That's worded in a slightly
However, for small operations it's a net loss - you avoid writing a WAL
record, but you have to fsync() the heap instead. If you only modify a few
rows, the extra fsync (or fsyncs if there are indexes too) is more expensive
than writing the WAL.
We'd need a heuristic to decide whether to
2011/8/5 Robert Haas robertmh...@gmail.com:
On Fri, Aug 5, 2011 at 2:36 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
BTW, what is the current status of this patch?
I think it's waiting for me to get around to reviewing it. Sorry,
been busy :-(
Thanks for your efforts.
The status of
23 matches
Mail list logo
