On Thu, Oct 21, 2010 at 2:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The plan for UNION initially involves a couple of SubqueryScan nodes,
which impose an extra cost of cpu_tuple_cost per tuple. Those later
get optimized away, but we don't try to readjust the cost estimates
for that.
Thanks.
On 20/10/10 01:47, Robert Haas wrote:
On Tue, Oct 19, 2010 at 6:14 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Comments?
It might be reasonable to back-patch whatever we decide on into 9.0,
because it is so new, but I would be reluctant to go back further
unless we have some evidence that it's
Robert Haas wrote:
On Wed, Oct 20, 2010 at 5:30 PM, Stephen R. van den Berg s...@cuci.nl wrote:
Ideal would be: put the table-oid inside the header of each page
(either in the official header, or in the special area).
This way even lost blocks can be correlated to the same table.
I'd still
David E. Wheeler da...@kineticode.com writes:
Might I suggest instead a META.json file like PGXN requires? Here's a
simple example:
I don't see what it buys us in this very context. The main thing here to
realize is that I wrote about no code to parse the control file. I don't
think the
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 20.10.2010 18:06, Tatsuo Ishii wrote:
Apart this, I wonder why walsender/walreceiver do not transfer archive
logs as well.
What do you mean?
I'd be pleased if Tatsuo idea have anything to do with this mail:
Tom Lane t...@sss.pgh.pa.us writes:
Peter Eisentraut pete...@gmx.net writes:
1. TCP Wrappers style, leading dot indicates suffix match.
So .example.com matches anything.example.com. Not sure how useful that
would be, but it could be implemented in about 3 lines of code.
I'd lean to #1
Hi there,
I can't make Python Generators to work reliably. According to the
documentation, this should work:
CREATE OR REPLACE FUNCTION foobar()
RETURNS SETOF text AS
$$
for s in ('Hello', 'World'):
plpy.execute('select 1')
yield s
$$
LANGUAGE 'plpythonu';
I get this error
Hi,
Here's an updated patch.
I'm still not too fond of the logic in spi.c, but I can't see a better
way to do this. If someone sees a better way, I'm not going to object.
I also made some changes to the SQL functions now that we have a
different API. The previous code pushed and popped
Itagaki Takahiro itagaki.takah...@gmail.com writes:
On Thu, Oct 21, 2010 at 2:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The plan for UNION initially involves a couple of SubqueryScan nodes,
which impose an extra cost of cpu_tuple_cost per tuple. Â Those later
get optimized away, but we don't
Stephen R. van den Berg s...@cuci.nl writes:
Robert Haas wrote:
and break on-disk compatibility just to make it easier to
If it's inserted in the special area, it will not break any
compatibility.
I'll tell you what I really don't like about this proposal: we discuss
some scheme or other for
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Itagaki Takahiro itagaki.takah...@gmail.com writes:
Why does only hstore have version '9.1'? Any other modules have
'9.1devel'.
It's the only contrib that's not using PGXS but instead directly
includes $(top_builddir)/src/Makefile.global,
...
Jeff Davis pg...@j-davis.com wrote:
Also, it appears to be non-deterministic, to a degree at least,
so you may not observe the problem in the exact way that I do.
The SELECTs only look at the root and the predicate doesn't match.
So each SELECT sets an SIReadLock on block 0 and exits the
Tom Lane t...@sss.pgh.pa.us writes:
... well, that's just a bug in hstore. *All* the contrib modules
should be using PGXS, unless they have a damn good reason not to;
which is not apparent for hstore.
Here's a patch.
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise,
On Oct 21, 2010, at 12:33 AM, Dimitri Fontaine wrote:
I don't see what it buys us in this very context. The main thing here to
realize is that I wrote about no code to parse the control file. I don't
think the extension patch should depend on the JSON-in-core patch.
Now, once we have JSON
On Wed, Oct 20, 2010 at 1:13 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Oct 20, 2010 at 3:47 PM, daveg da...@sonic.net wrote:
On Wed, Oct 20, 2010 at 12:28:25PM -0700, Greg Stark wrote:
On Wed, Oct 20, 2010 at 12:17 PM, Greg Stark gsst...@mit.edu wrote:
I don't think it's a big cost
David E. Wheeler da...@kineticode.com writes:
Sure. The reason to do it, though, is so that extension authors can create
just one metadata file, instead of two (or three, if one must also put such
data into the Makefile).
That's a good idea, but my guess is that the implementation cost of
On Tue, Oct 19, 2010 at 8:30 PM, daveg da...@sonic.net wrote:
On Wed, Oct 20, 2010 at 04:08:37PM +1300, Mark Kirkwood wrote:
On 20/10/10 16:05, Mark Kirkwood wrote:
shmget and friends are hugetlbpage aware, so it seems it should 'just
work'.
Heh - provided you specify
SHM_HUGETLB
Jeff Davis pg...@j-davis.com wrote:
That looks like a reasonable state to me, but I'm not sure exactly
what the design calls for. I am guessing that the real problem is
in PreCommit_CheckForSerializationFailure(), where there are 6
conditions that must be met for an error to be thrown. T2
On Oct 21, 2010, at 8:12 AM, Dimitri Fontaine wrote:
That's a good idea, but my guess is that the implementation cost of
supporting the control format in your perl infrastructure is at least an
order of magnitude lower than the cost for me to support your current
JSON file format, so I lean
David E. Wheeler da...@kineticode.com writes:
Be aware that PGXS sets a $(VERSION) variable already, so you'll need
to use another name, I think, to guard from conflicts. This is in
Makefile.global:
Of course that's not a problem for contribs, and I used EXTVERSION in a
previous version of the
Excerpts from Dimitri Fontaine's message of jue oct 21 12:53:18 -0300 2010:
This part of the problem didn't receive much thoughts yet, and it shows
up. About the rest of the patch have been in my head for months, I
expect less problems there...
Keep on it. You're doing a terrific job.
--
On Thu, Oct 21, 2010 at 11:12 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
David E. Wheeler da...@kineticode.com writes:
Sure. The reason to do it, though, is so that extension authors can create
just one metadata file, instead of two (or three, if one must also put such
data into the
Robert Haas robertmh...@gmail.com writes:
On Wed, Oct 20, 2010 at 10:03 AM, Tom Lane t...@sss.pgh.pa.us wrote:
My point is that anyplace that is relying on the surface typelem,
without drilling down to see what the base type is, is wrong.
So yeah, those lookups are (will be) necessary.
OK.
On Thu, 2010-10-21 at 10:29 -0500, Kevin Grittner wrote:
Basically, when we already have a pivot, but no transaction has yet
committed, we wait to see if TN commits first. If so, we have a
problem; if not, we don't. There's probably some room for improving
performance by cancelling T0 or T1
Tom Lane t...@sss.pgh.pa.us wrote:
regression=# select array[1,2] || 3::myi;
ERROR: operator does not exist: integer[] || myi
In this case, one might expect myi to be automatically downcast to
int so that it could be matched up with the int array, but that's
not happening.
I guess it
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
So we will downcast myia to int[], or at least one might assume
that's what's happening. But actually it's worse than that: the
result of this operation is thought to be myia not int[], because
myia itself
Kevin Grittner wrote:
Tom Lane wrote:
I'm all for doing this client-side.
Well, that makes a big difference. Unless someone can make a
convincing argument for why we should modify the server side to
support this, I think we should just focus on this one client-side
patch.
I'd
Tom Lane t...@sss.pgh.pa.us wrote:
you are confusing an array over a domain type with a domain over
an array type.
Yes I was. Sorry. Argument withdrawn.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
I'm all for doing this client-side.
Uh, why would we do this client-side rather than server-side? If we do
it server-side, all interfaces get it.
1. The API that's being implemented is JDBC-specific.
2. Even if you want to argue that
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
I'm all for doing this client-side.
Uh, why would we do this client-side rather than server-side? If we do
it server-side, all interfaces get it.
1. The API that's being implemented is JDBC-specific.
2. Even
Bruce Momjian br...@momjian.us wrote:
why would we do this client-side rather than server-side?
Because the timeout is supposed to be a limit on the time allowed
for specific Java methods to complete, which might be running a
large number of SQL statements within one invocation, and which may
Kevin Grittner wrote:
Bruce Momjian br...@momjian.us wrote:
why would we do this client-side rather than server-side?
Because the timeout is supposed to be a limit on the time allowed
for specific Java methods to complete, which might be running a
large number of SQL statements within
I just noticed that there doesn't seem to be any good way of finding
out what a postmaster's default value of unix_socket_directory is.
If you try to SHOW it you just get an empty string. We could probably
fix things so that SHOW exposes the actual setting, but (1) there might
be security
On Thu, Oct 21, 2010 at 6:57 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Thanks. It also explains my another question why Merge Append cannot
be used for UNION ALL plans.
Hmm, seems like the example you show ought to work. I wonder if there
was an oversight in that patch...
Huh, that definitely
Excerpts from Jean-Baptiste Quenot's message of jue oct 21 09:20:16 -0300 2010:
I get this error when calling the function:
test=# select foobar();
ERROR: error fetching next item from iterator
I can reproduce this here. The first bug to solve is, I think, getting
a more meaningful error
Tom Lane wrote:
Stephen R. van den Berg s...@cuci.nl writes:
If it's inserted in the special area, it will not break any
compatibility.
I'll tell you what I really don't like about this proposal: we discuss
some scheme or other for taking over the special space in heap pages
at least once a
Robert Haas wrote:
I think the right way to write UPSERT is something
along the lines of:
MERGE INTO Stock t USING (VALUES (10, 1)) s(item_id, balance) ON
s.item_id = t.item_id ...
That led in the right direction, after a bit more fiddling I was finally
able to get something that does
Jeff Davis pg...@j-davis.com wrote:
in this case we do clearly have a problem, because the result is
not equal to the serial execution of the transactions in either
order.
Yeah, you're right. I misread that example -- newbie with the
PERIOD type.
So the question is: at what point is the
On tor, 2010-10-14 at 22:54 -0400, Robert Haas wrote:
and maybe not that bad, but I wonder if there is some preparatory
refactoring that could be done to trim it down a bit. I notice, for
example, that a lot of places that looked at asc/desc, nulls
first/last now look at asc/desc, nulls
Excerpts from Alvaro Herrera's message of jue oct 21 15:32:53 -0300 2010:
Excerpts from Jean-Baptiste Quenot's message of jue oct 21 09:20:16 -0300
2010:
I get this error when calling the function:
test=# select foobar();
ERROR: error fetching next item from iterator
I can
2010/10/21 Tom Lane t...@sss.pgh.pa.us:
I just noticed that there doesn't seem to be any good way of finding
out what a postmaster's default value of unix_socket_directory is.
If you try to SHOW it you just get an empty string. We could probably
fix things so that SHOW exposes the actual
On Thu, Oct 21, 2010 at 2:44 PM, Peter Eisentraut pete...@gmx.net wrote:
On tor, 2010-10-14 at 22:54 -0400, Robert Haas wrote:
and maybe not that bad, but I wonder if there is some preparatory
refactoring that could be done to trim it down a bit. I notice, for
example, that a lot of places
On Thu, Oct 21, 2010 at 08:16:27AM -0700, Mark Wong wrote:
On Tue, Oct 19, 2010 at 8:30 PM, daveg da...@sonic.net wrote:
On Wed, Oct 20, 2010 at 04:08:37PM +1300, Mark Kirkwood wrote:
On 20/10/10 16:05, Mark Kirkwood wrote:
shmget and friends are hugetlbpage aware, so it seems it
Excerpts from Cédric Villemain's message of jue oct 21 16:01:30 -0300 2010:
I agree this is interesting information to get, but wonder how
pg_config can know that and it looks to me that this information as
nothing to do in pg_config
pg_config is all about installation, socket_dir is a
Tom Lane t...@sss.pgh.pa.us writes:
One possible response would be to add an item to what pg_config knows
about, eg pg_config --socketdir. This doesn't answer every possible
use-case either, but it would be helpful for some scenarios.
Thoughts?
Following some links one can find out
On Thu, Oct 21, 2010 at 11:30 AM, Stephen R. van den Berg s...@cuci.nl wrote:
For the recovery information I'd like to reserve:
identifier: 00: table OID
01: table layout
So here's a proposal for something that could maybe be implemented. I
think I'm leaning against this currently
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Cédric Villemain's message of jue oct 21 16:01:30 -0300 2010:
I agree this is interesting information to get, but wonder how
pg_config can know that and it looks to me that this information as
nothing to do in pg_config
2010/10/21 Tom Lane t...@sss.pgh.pa.us:
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Cédric Villemain's message of jue oct 21 16:01:30 -0300 2010:
I agree this is interesting information to get, but wonder how
pg_config can know that and it looks to me that this information
On 10/20/10 6:54 PM, Robert Haas wrote:
I find it impossible to believe that's
a good decision, and IMHO we should be focusing on how to make the
parameters PGC_SIGHUP rather than PGC_POSTMASTER, which would give us
most of the same benefits without throwing away hard-won performance.
I'd be
On Thu, Oct 21, 2010 at 12:10:22PM -0700, David Gould wrote:
On Thu, Oct 21, 2010 at 08:16:27AM -0700, Mark Wong wrote:
On Tue, Oct 19, 2010 at 8:30 PM, daveg da...@sonic.net wrote:
On Wed, Oct 20, 2010 at 04:08:37PM +1300, Mark Kirkwood wrote:
On 20/10/10 16:05, Mark Kirkwood wrote:
Stephen R. van den Berg s...@cuci.nl writes:
Tom Lane wrote:
There are way too many scenarios where you'll have no hope of doing
any such manual recovery anyway.
True. It's all a matter of statistics. Judging by the number of reports
I find by googling net-history, I'd have to conclude
On Thu, Oct 21, 2010 at 4:21 PM, Josh Berkus j...@agliodbs.com wrote:
On 10/20/10 6:54 PM, Robert Haas wrote:
I find it impossible to believe that's
a good decision, and IMHO we should be focusing on how to make the
parameters PGC_SIGHUP rather than PGC_POSTMASTER, which would give us
most of
Peter Eisentraut pete...@gmx.net writes:
We already have TypeName as a structure that contains type and typmod
(and collation, in my patch). We could make that a primnode instead of
a parsenode, and use it in more places, or we could make a new leaner
structure that only contains the numeric
On Thu, Oct 21, 2010 at 4:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
We already have TypeName as a structure that contains type and typmod
(and collation, in my patch). We could make that a primnode instead of
a parsenode, and use it in more places, or
On Oct 21, 2010, at 4:19 PM, Robert Haas wrote:
2010/10/21 Tom Lane t...@sss.pgh.pa.us:
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Cédric Villemain's message of jue oct 21 16:01:30 -0300 2010:
I agree this is interesting information to get, but wonder how
pg_config can
Robert Haas robertmh...@gmail.com writes:
On Thu, Oct 21, 2010 at 4:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
TypeName per se is completely inappropriate for use beyond the first
stage of parsing, because it requires catalog lookups to make any sense
of. I think the post-parsing
I think that that would probably involve a whole lot more notational
busywork than just replacing typmod with something more complicated.
However, we're talking about breaking vast amounts of code in either
case, so maybe making it even vaster isn't a real consideration.
Gods, yes. Please
buildfarm member koi, having recently been rescued from git purgatory,
is failing like this:
configure: using CFLAGS=-O -Kinline
configure: using CPPFLAGS= -I/usr/local/include/libxml2 -I/usr/local/include
configure: using LDFLAGS= -L/usr/local/lib -L/usr/local/lib
preparing build tree...
A.M. age...@themactionfaction.com writes:
On Oct 21, 2010, at 4:19 PM, Robert Haas wrote:
I think adding this to pg_config is sensible. Sure, the user could
have moved the socket directory. But it's a place to start looking.
So why not?
Because pg_config is supposed to return the current
Hi,
A customer was hitting some misbehavior in one of their internal tests and
I tracked it down to plancache not behaving properly with
subtransactions: in particular, a plan is not being marked dead when
the subtransaction on which it is planned rolls back. It was reported
in 8.4, but I can
Excerpts from Tom Lane's message of jue oct 21 17:48:18 -0300 2010:
buildfarm member koi, having recently been rescued from git purgatory,
is failing like this:
configure: using CFLAGS=-O -Kinline
configure: using CPPFLAGS= -I/usr/local/include/libxml2 -I/usr/local/include
configure: using
Greg Stark gsst...@mit.edu writes:
On Thu, Oct 21, 2010 at 6:57 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Thanks. It also explains my another question why Merge Append cannot
be used for UNION ALL plans.
Hmm, seems like the example you show ought to work. I wonder if there
was an oversight in
Tom Lane t...@sss.pgh.pa.us wrote:
Most of the data-loss reports I've seen appeared to come from
people who wouldn't be capable of doing such recovery work even if
better tools were available.
No doubt; but the recovery work often winds up in the hands of
people with more skills than those
Peter Eisentraut wrote:
On ons, 2010-10-13 at 14:32 -0400, Bruce Momjian wrote:
We have a database specification in .pgpass:
hostname:port:database:username:password
What is the purpose of 'database' since username/password combinations
are global, not per database? I would
On Oct 21, 2010, at 2:17 PM, Tom Lane wrote:
The oversight here is that we don't use appendrel planning for
a top-level UNION ALL construct. That didn't use to matter,
because you always got the same stupid Append plan either way.
Now it seems like we ought to have some more intelligence for
Greg Stark wrote:
On Thu, Oct 14, 2010 at 2:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Should we consider moving pg_filedump into our /contrib?
Can't: it's GPL.
I don't particularly see a problem with having GPL'd contrib modules.
It would mean
Fujii Masao wrote:
Hi,
As the result of the discussion, I think that we need the following two
parameters for the case where the standby goes down.
Can we have a parameter that calls a operating system command when a
standby is declared dead, to notify the administrator?
--
Bruce Momjian
Alvaro Herrera alvhe...@alvh.no-ip.org writes:
A customer was hitting some misbehavior in one of their internal tests and
I tracked it down to plancache not behaving properly with
subtransactions: in particular, a plan is not being marked dead when
the subtransaction on which it is planned
Robert Treat wrote:
Howdy folks,
Was wondering if there are any docs on which contrib modules don't work with
pg_upgrade? I seem to remember discussion on this during the 9.0 cycle, but
couldn't find it in the mail archive, and don't see anything in the wiki.
What
brings this up is
On 19/10/10 13:16, Josh Berkus wrote:
Robert asked me to write this up, so here it is.
It is critical that we make replication easier to set up, administrate
and monitor than it currently is. In my conversations with people,
this is more important to our users and the adoption of PostgreSQL
On Thu, Oct 21, 2010 at 5:21 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Most of the data-loss reports I've seen appeared to come from
people who wouldn't be capable of doing such recovery work even if
better tools were available.
No doubt; but
Excerpts from Tom Lane's message of jue oct 21 19:36:07 -0300 2010:
Alvaro Herrera alvhe...@alvh.no-ip.org writes:
A customer was hitting some misbehavior in one of their internal tests and
I tracked it down to plancache not behaving properly with
subtransactions: in particular, a plan is
Jeff Davis pg...@j-davis.com wrote:
When using locks in an unconventional way, it would be helpful to
describe the invalid schedules that you're preventing. Perhaps an
example if you think it would be reasonably simple? Also some
indication of how another process is intended to modify the
Robert Haas wrote:
On Mon, Oct 18, 2010 at 2:29 PM, Jeff Davis pg...@j-davis.com wrote:
A reasonable conversion path might be to offer integer timestamps using
a different type name (e.g. inttimestamp) that always means integer
timestamps. Then, they could convert using ALTER TABLE, then do
On Thu, Oct 21, 2010 at 4:49 PM, Bruce Momjian br...@momjian.us wrote:
One thing we have talked about is converting the page on read-in from
the backend. Since the timestamps are the same size as float or
integer, that might be possible.
Did we have a solution for the problem that
Greg Stark wrote:
On Tue, Oct 19, 2010 at 12:03 PM, Robert Haas robertmh...@gmail.com wrote:
The trick is that it would require us to have two pg_class tables, two
pg_attribute tables, two pg_attrdef tables, etc.: in each case, one
permanent and one temporary. ?I am not sure how complex
Kevin Grittner wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Most of the data-loss reports I've seen appeared to come from
people who wouldn't be capable of doing such recovery work even if
better tools were available.
No doubt; but the recovery work often winds up in the hands of
people with more
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Currently it isn't possible to create temporary tables on read-only
standby servers, and I don't see it listed on the TODO list. Can I add
it?
Not unless you have some credible concept for how it might ever be
implemented. You
Josh Berkus wrote:
Greg,
The way things stand you *always* need archived logs. Even if you have
streaming set up it might try to use archived logs if it falls too far
behind.
Actually, you don't. If you're willing to accept possible
desynchronization and recloning of the standbys,
Excerpts from Tom Lane's message of jue oct 21 19:36:07 -0300 2010:
I'm not immediately sure why plpgsql_subxact_cb is failing to clean up
correctly in this example, but that seems to be where to look.
I think the reason is that one econtext is pushed for function
execution, and another one
Robert Haas wrote:
On Wed, Oct 20, 2010 at 3:40 PM, Greg Stark gsst...@mit.edu wrote:
On Wed, Oct 20, 2010 at 6:29 AM, Robert Haas robertmh...@gmail.com wrote:
Exactly. ?It doesn't take many 3-7% slowdowns to add up to being 50%
or 100% slower, and that sucks. ?In fact, I'm still not
Robert Haas wrote:
On Thu, Oct 21, 2010 at 4:21 PM, Josh Berkus j...@agliodbs.com wrote:
On 10/20/10 6:54 PM, Robert Haas wrote:
I find it impossible to believe that's
a good decision, and IMHO we should be focusing on how to make the
parameters PGC_SIGHUP rather than PGC_POSTMASTER,
On Thu, Oct 21, 2010 at 8:22 PM, Bruce Momjian br...@momjian.us wrote:
Josh Berkus wrote:
Greg,
The way things stand you *always* need archived logs. Even if you have
streaming set up it might try to use archived logs if it falls too far
behind.
Actually, you don't. If you're willing
On Wed, Oct 20, 2010 at 10:56 PM, Josh Kupershmidt schmi...@gmail.com wrote:
It looks like psql's tab completion for the \z and \dg commands in
psql are missing. I couldn't see a reason for this, so attached patch
fixes.
Also, this patch proposes to change psql's \? help text to say that
\dg
Agreed, but as a reality check: when I proposed that wal_keep_segments
= -1 would keep all WAL segments (for use while the file system was
being backed up), I was told administrators shoud compute how much free
disk space they had. Obviously easy of use is not our #1 priority.
Depends.
On Thu, Oct 21, 2010 at 5:46 PM, Josh Berkus j...@agliodbs.com wrote:
Agreed, but as a reality check: when I proposed that wal_keep_segments
= -1 would keep all WAL segments (for use while the file system was
being backed up), I was told administrators shoud compute how much free
disk space
Greg Stark wrote:
On Tue, Oct 19, 2010 at 1:12 PM, Stephen R. van den Berg s...@cuci.nl wrote:
In order to simplify recovery at this point (enormously), it would
have been very helpful (at almost negligible cost), to have the name
of the table, the name of the columns, and the types of the
On Thu, Oct 21, 2010 at 8:52 PM, Greg Stark gsst...@mit.edu wrote:
On Thu, Oct 21, 2010 at 5:46 PM, Josh Berkus j...@agliodbs.com wrote:
Agreed, but as a reality check: when I proposed that wal_keep_segments
= -1 would keep all WAL segments (for use while the file system was
being backed
On Thu, Oct 21, 2010 at 8:45 PM, Robert Haas robertmh...@gmail.com wrote:
Please add this in the usual spot:
https://commitfest.postgresql.org/action/commitfest_view/open
Aye sir, added.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Robert Haas wrote:
However the user-unfriendliness isn't the fact that administrators
need to determine how much disk they're willing to dedicate to
Postgres. The user-unfriendliness is that they then have to specify
this in terms of WAL log files and also have to know that we sometimes
Greg Stark wrote:
On Thu, Oct 21, 2010 at 11:30 AM, Stephen R. van den Berg s...@cuci.nl wrote:
For the recovery information I'd like to reserve:
identifier: 00: table OID
? ? ? ? ? ?01: table layout
So here's a proposal for something that could maybe be implemented. I
think I'm leaning
Bruce Momjian wrote:
Greg Stark wrote:
On Tue, Oct 19, 2010 at 1:12 PM, Stephen R. van den Berg s...@cuci.nl
wrote:
In order to simplify recovery at this point (enormously), it would
have been very helpful (at almost negligible cost), to have the name
of the table, the name of the
Very true. But the lack of a -1 setting for wal_keep_segments means
that if you would like to take a backup without archiving, you must
set wal_keep_segments to a value greater than or equal to the rate at
which you generate WAL segments multiplied by the time it takes you to
run a backup.
Greg Stark wrote:
On Thu, Oct 21, 2010 at 4:49 PM, Bruce Momjian br...@momjian.us wrote:
One thing we have talked about is converting the page on read-in from
the backend. ?Since the timestamps are the same size as float or
integer, that might be possible.
Did we have a solution for the
On Thu, Oct 21, 2010 at 9:09 PM, Josh Berkus j...@agliodbs.com wrote:
Very true. But the lack of a -1 setting for wal_keep_segments means
that if you would like to take a backup without archiving, you must
set wal_keep_segments to a value greater than or equal to the rate at
which you
I think it's pretty well explained in the fine manual.
http://www.postgresql.org/docs/current/static/runtime-config-wal.html#GUC-WAL-KEEP-SEGMENTS
Nope. No relationship to checkpoint_segments is explained there. Try
again?
If checkpoint_segments were a hard limit, then we could let
Bruce Momjian br...@momjian.us writes:
Greg Stark wrote:
It seems to me simpler and more direct to just nail relcache
entries for these objects into memory and manipulate them directly.
They can be constructed from the global catalog tables and then
tweaked to point to the backend local
On Thu, Oct 21, 2010 at 10:03 PM, Josh Berkus j...@agliodbs.com wrote:
I think it's pretty well explained in the fine manual.
http://www.postgresql.org/docs/current/static/runtime-config-wal.html#GUC-WAL-KEEP-SEGMENTS
Nope. No relationship to checkpoint_segments is explained there. Try
Bruce Momjian br...@momjian.us writes:
Greg Stark wrote:
Did we have a solution for the problem that understanding which
columns are timestamps requires having a tuple descriptor and parsing
the every tuple? That seems like it would a) be slow and b) require a
lot of high level code in the
On Fri, Oct 22, 2010 at 1:31 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Of course, you what that means? Yes, another version of the patch, that
will build the control file out of the control.in at build time rather
than install time, and that's back to using EXTVERSION both in the
1 - 100 of 107 matches
Mail list logo
