On Thu, 11 Feb 2010, Tom Lane wrote:
Oleg Bartunov o...@sai.msu.su writes:
This is very disgraceful from my point of view and reflects real problem
in scheduling of CF. The patch was submitted Nov 23 2009, discussed and
reworked Nov 25. Long holidays in December-January, probably are reason
On Thu, 11 Feb 2010, Robert Haas wrote:
2010/2/11 Oleg Bartunov o...@sai.msu.su:
This is very disgraceful from my point of view and reflects real problem
in scheduling of CF. The patch was submitted Nov 23 2009, discussed and
reworked Nov 25. Long holidays in December-January, probably are
2010/2/10 daveg da...@sonic.net:
On Tue, Feb 09, 2010 at 09:34:10AM -0500, Andrew Chernow wrote:
Tollef Fog Heen wrote:
(please Cc me on replies, I am not subscribed)
Hi,
libpq currently does not use TCP keepalives. This is a problem in our
case where we have some clients waiting for
On Mon, 2010-02-08 at 04:33 +, Tom Lane wrote:
We still have to retain all code that copes with finding
HEAP_MOVED_OFF and HEAP_MOVED_IN flag bits on existing tuples. This
can't be removed as long as we want to support in-place update from
pre-9.0 databases.
This doesn't seem to be a
On Wed, 2010-02-10 at 13:16 +0200, Heikki Linnakangas wrote:
If they want to implement the warm standby using the (new) built-in
logic to keep retrying restore_command, they would set
standby_mode='on'. standby_mode='on' doesn't imply streaming replication.
The docs say If this parameter is
On Wed, 2010-02-10 at 09:32 +0200, Heikki Linnakangas wrote:
Fujii Masao wrote:
As I pointed out previously, the standby might restore a partially-filled
WAL file that is being archived by the primary, and cause a FATAL error.
And this happened in my box when I was testing the SR.
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Right now, log_error_verbosity displays the source code error location
in this format:
LOCATION: parserOpenTable, parse_relation.c:858
I think it would be clearer to add '()' next to the function
On Thursday 11 February 2010 11:10:32 Simon Riggs wrote:
On Mon, 2010-02-08 at 04:33 +, Tom Lane wrote:
We still have to retain all code that copes with finding
HEAP_MOVED_OFF and HEAP_MOVED_IN flag bits on existing tuples. This
can't be removed as long as we want to support in-place
On Sun, 2010-02-07 at 21:33 -0500, Tom Lane wrote:
Another issue is that it's not clear what happens in a Hot Standby
slave --- it doesn't look like Simon put any interlocking in this
area to protect slave queries against having the page disappear
from under them. The odds of an actual
Hi Robert,
On Tue, Feb 9, 2010 at 17:43, Robert Haas robertmh...@gmail.com wrote:
On Tue, Feb 9, 2010 at 7:08 AM, Jeroen Vermeulen j...@xs4all.nl wrote:
= Projected-cost threshold =
If a prepared statement takes parameters, and the generic plan has a high
projected cost, re-plan each
Hi,
Boszormenyi Zoltan írta:
Greg Smith írta:
4) Investigate and be explicit about the potential breakage here both
for libpq clients and at least one additional driver too. If I saw a
demonstration that this didn't break the JDBC driver, for example, I'd
feel a lot better about the
Simon Riggs wrote:
The docs say If this parameter is on, the streaming replication is
enabled. So who is wrong?
The docs.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Simon Riggs wrote:
On Wed, 2010-02-10 at 09:32 +0200, Heikki Linnakangas wrote:
Hmm, so after running restore_command, check the file size and if it's
too short, treat it the same as if restore_command returned non-zero?
And it will be retried on the next iteration. Works for me, though OTOH
2010/2/11 Bart Samwel b...@samwel.tk:
Hi Robert,
On Tue, Feb 9, 2010 at 17:43, Robert Haas robertmh...@gmail.com wrote:
On Tue, Feb 9, 2010 at 7:08 AM, Jeroen Vermeulen j...@xs4all.nl wrote:
= Projected-cost threshold =
If a prepared statement takes parameters, and the generic plan has
On Thu, 2010-02-11 at 14:22 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Wed, 2010-02-10 at 09:32 +0200, Heikki Linnakangas wrote:
Hmm, so after running restore_command, check the file size and if it's
too short, treat it the same as if restore_command returned non-zero?
And it
On Thu, Feb 11, 2010 at 13:25, Pavel Stehule pavel.steh...@gmail.comwrote:
2010/2/11 Bart Samwel b...@samwel.tk:
Perhaps this could be based on a (configurable?) ratio of observed
planning
time and projected execution time. I mean, if planning it the first time
took 30 ms and projected
On Thu, Feb 11, 2010 at 7:39 AM, Bart Samwel b...@samwel.tk wrote:
On Thu, Feb 11, 2010 at 13:25, Pavel Stehule pavel.steh...@gmail.com
wrote:
2010/2/11 Bart Samwel b...@samwel.tk:
Perhaps this could be based on a (configurable?) ratio of observed
planning
time and projected execution
Simon Riggs wrote:
On Thu, 2010-02-11 at 14:22 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Wed, 2010-02-10 at 09:32 +0200, Heikki Linnakangas wrote:
Hmm, so after running restore_command, check the file size and if it's
too short, treat it the same as if restore_command returned
Andres Freund wrote:
On Thursday 11 February 2010 11:10:32 Simon Riggs wrote:
On Mon, 2010-02-08 at 04:33 +, Tom Lane wrote:
We still have to retain all code that copes with finding
HEAP_MOVED_OFF and HEAP_MOVED_IN flag bits on existing tuples. This
can't be removed as long as we want to
On Thu, Feb 11, 2010 at 13:41, Robert Haas robertmh...@gmail.com wrote:
On Thu, Feb 11, 2010 at 7:39 AM, Bart Samwel b...@samwel.tk wrote:
Anyhow, I have no clue how much time the planner takes. Can anybody
provide
any statistics in that regard?
It depends a great deal on the query, which
On Thu, Feb 11, 2010 at 3:38 AM, Oleg Bartunov o...@sai.msu.su wrote:
Robert, please accept my public apology, if you feel I offense you. There
are
nothing against you. Your contribution is very important and I really don't
understand why on the Earth you're not paid ! I remember discussion to
On Thu, Feb 11, 2010 at 7:48 AM, Bart Samwel b...@samwel.tk wrote:
On Thu, Feb 11, 2010 at 13:41, Robert Haas robertmh...@gmail.com wrote:
On Thu, Feb 11, 2010 at 7:39 AM, Bart Samwel b...@samwel.tk wrote:
Anyhow, I have no clue how much time the planner takes. Can anybody
provide
any
On Thu, 2010-02-11 at 14:44 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Thu, 2010-02-11 at 14:22 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Wed, 2010-02-10 at 09:32 +0200, Heikki Linnakangas wrote:
Hmm, so after running restore_command, check the file size and if
On Thu, Feb 11, 2010 at 3:00 AM, Oleg Bartunov o...@sai.msu.su wrote:
version I saw hadn't any documentation whatever. It's not committable
on documentation grounds alone, even if everybody was satisfied about
the code.
well, there is enough documentation to review patch.
Where is there any
Hi there,
I've been working on a patch to add hostname support to pg_hba.conf. It's
not ready for public display yet, but I would just like to run a couple of
issues / discussion points past everybody.
ISSUE #1: Performance / caching
At present, I've simply not added caching. The reasoning for
On Thu, 2010-02-11 at 14:53 +0200, Heikki Linnakangas wrote:
Andres Freund wrote:
On Thursday 11 February 2010 11:10:32 Simon Riggs wrote:
We should remove the moved in/off flag bits and make it a part of the
upgrade process to ensure the absence of those states.
Essentially requiring a
Simon Riggs wrote:
If you were running pg_standby as the restore_command then this error
wouldn't happen. So you need to explain why running pg_standby cannot
solve your problem and why we must fix it by replicating code that has
previously existed elsewhere.
pg_standby cannot be used with
Bart Samwel wrote:
Perhaps this could be based on a (configurable?) ratio of observed
planning time and projected execution time. I mean, if planning it the
first time took 30 ms and projected execution time is 1 ms, then by
all means NEVER re-plan.
IMHO looking at ms is bad for this 'possible
ISTM that the default behavior should be keep alives disabled, as it is
now, and those wanting it can just set it in their apps:
setsockopt(PQsocket(conn), SOL_SOCKET, SO_KEEPALIVE, ...)
I disagree. I have clients who have problems with leftover client connections
due to server host failures.
Simon Riggs si...@2ndquadrant.com writes:
If you were running pg_standby as the restore_command then this error
wouldn't happen. So you need to explain why running pg_standby cannot
solve your problem and why we must fix it by replicating code that has
previously existed elsewhere.
Let me
On 2010-02-11 03:44 +0200, I wrote:
I'm going to have to disappoint a bunch of people and give up. :-(
Btw. would it make sense to apply the WITH-on-top-of-DML part of this
patch? At least to me, this seems useful because you can write a
RECURSIVE SELECT and then use UPDATE .. FROM or DELETE ..
On Thu, 2010-02-11 at 15:28 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
If you were running pg_standby as the restore_command then this error
wouldn't happen. So you need to explain why running pg_standby cannot
solve your problem and why we must fix it by replicating code that has
On Thu, 2010-02-11 at 14:41 +0100, Dimitri Fontaine wrote:
Simon Riggs si...@2ndquadrant.com writes:
If you were running pg_standby as the restore_command then this error
wouldn't happen. So you need to explain why running pg_standby cannot
solve your problem and why we must fix it by
Simon Riggs wrote:
One question then: how do we ensure that the archive does not grow too
big? pg_standby cleans down the archive using %R. That function appears
to not exist anymore.
You can still use %R. Of course, plain 'cp' won't know what to do with
it, so a script will then be required.
* Heikki Linnakangas heikki.linnakan...@enterprisedb.com [100211 08:29]:
To suppport a restore_command that does the sleeping itself, like
pg_standby, would require a major rearchitecting of the retry logic. And
I don't see why that'd desirable anyway. It's easier for the admin to
set up
On Thu, 2010-02-11 at 15:55 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
One question then: how do we ensure that the archive does not grow too
big? pg_standby cleans down the archive using %R. That function appears
to not exist anymore.
You can still use %R. Of course, plain
Aidan Van Dyk wrote:
But colour me confused, I'm still not understanding why this is any
different that with normal PITR recovery.
So even with a plain cp in your recovery command instead of a
sleep+copy (a la pg_standby, or PITR tools, or all the home-grown
solutions out thery), I'm not
Simon Riggs wrote:
Might it not be simpler to add a parameter onto pg_standby?
We send %s to tell pg_standby the standby_mode of the server which is
calling it so it can decide how to act in each case.
That would work too, but it doesn't seem any simpler to me. On the contrary.
--
Heikki
Robert Haas robertmh...@gmail.com writes:
It seems that you're sort of frustrated with the system and the need
to go through a process before committing a patch;
I've been handling arround here for years (since 2005 or before) and I
think there always was a process. The only change is it's
On Sun, 2010-02-07 at 21:33 -0500, Tom Lane wrote:
That last problem is easy to fix, but I'm not at all sure what to do
about the scan interlock problem. Thoughts?
AFAICS the problem doesn't exist in normal running.
_bt_page_recyclable() tests against RecentXmin, which includes the xmins
of
On Thu, 2010-02-11 at 16:22 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
Might it not be simpler to add a parameter onto pg_standby?
We send %s to tell pg_standby the standby_mode of the server which is
calling it so it can decide how to act in each case.
That would work too, but
Dear Folks;
A very serious bug was reported on pg_lesslog. So far, I found it's
a bug in pg_compresslog. Please do not use pg_compresslog and
pg_decompresslog until improved version is uploaded.
I strongly advise to take base backup of your database.
I apologize for inconvenience. I'll
* Heikki Linnakangas heikki.linnakan...@enterprisedb.com [100211 09:17]:
If the file is just being copied to the archive when restore_command
('cp', say) is launched, it will copy a half file. That's not a problem
for PITR, because PITR will end at the end of valid WAL anyway, but
returning a
On Thu, Feb 11, 2010 at 1:18 PM, Robert Haas robertmh...@gmail.com wrote:
In my understanding
this was always enough to submit code. User's documentation is depend on
discussion and review and can be added later
before releasing beta.
Several people have said this lately, but it doesn't
Heikki Linnakangas wrote:
Simon Riggs wrote:
Might it not be simpler to add a parameter onto pg_standby?
We send %s to tell pg_standby the standby_mode of the server which is
calling it so it can decide how to act in each case.
That would work too, but it doesn't seem any simpler to
On Thu, 11 Feb 2010, Robert Haas wrote:
On Thu, Feb 11, 2010 at 3:00 AM, Oleg Bartunov o...@sai.msu.su wrote:
version I saw hadn't any documentation whatever. It's not committable
on documentation grounds alone, even if everybody was satisfied about
the code.
well, there is enough
On Wed, Feb 10, 2010 at 01:12:31PM -0300, Alvaro Herrera wrote:
What happened to this patch? Was it abandoned in favor of server-side
tracing?
I think it was abandoned but I don't remember seeing any patch/suggestion to
improve server-side tracing. This might come from server-side tracing
Simon Riggs wrote:
On Thu, 2010-02-11 at 16:22 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
Might it not be simpler to add a parameter onto pg_standby?
We send %s to tell pg_standby the standby_mode of the server which is
calling it so it can decide how to act in each case.
That would
On Thu, 11 Feb 2010, Greg Stark wrote:
On Thu, Feb 11, 2010 at 1:18 PM, Robert Haas robertmh...@gmail.com wrote:
In my understanding
this was always enough to submit code. User's documentation is depend on
discussion and review and can be added later
before releasing beta.
Several people
Bart Samwel b...@samwel.tk wrote:
I've been working on a patch to add hostname support to
pg_hba.conf.
At present, I've simply not added caching.
Perhaps you could just recommend using nscd (or similar).
There was a suggestion on the TODO list on the wiki, which
basically said that
Simon Riggs escreveu:
It would mean that pg_standby would act appropriately according to the
setting of standby_mode. So you wouldn't need multiple examples of use,
it would all just work whatever the setting of standby_mode. Nice simple
entry in the docs.
+1. I like the %s idea. IMHO fixing
On 02/11/2010 08:13 AM, Bart Samwel wrote:
ISSUE #1: Performance / caching
At present, I've simply not added caching. The reasoning for this is
as follows:
(a) getaddrinfo doesn't tell us about expiry, so when do you refresh?
(b) If you put the cache in the postmaster, it will not work for
On Thu, Feb 11, 2010 at 8:46 AM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
On 2010-02-11 03:44 +0200, I wrote:
I'm going to have to disappoint a bunch of people and give up. :-(
Btw. would it make sense to apply the WITH-on-top-of-DML part of this
patch? At least to me, this seems
Simon Riggs si...@2ndquadrant.com writes:
This would only happen if a VACUUM FULL had been run on the pre-9.0
database and it had failed part way through.
If that were true, you might have an argument, but it isn't. VACUUM
FULL was never very careful about getting rid of all MOVED_xxx bits.
Hello,
When developing pl/perlu functions common definitions and methods are often
stored in external .pm modules. During deployment the modules should be
installed somewhere in @INC to be reachable by the perl interpreter. However,
installing the modules to a location outside of the PG
Ühel kenal päeval, K, 2010-02-10 kell 21:17, kirjutas Tom Lane:
Robert Haas robertmh...@gmail.com writes:
On Wed, Feb 10, 2010 at 3:30 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
If this doesn't fit in 24x80 maybe we need to find a more compact way to
display things.
+1. I
]] daveg
| I disagree. I have clients who have problems with leftover client connections
| due to server host failures. They do not write apps in C. For a non-default
| change to be effective we would need to have all the client drivers, eg JDBC,
| psycopg, DBD-DBI, and the apps like psql make
On Thu, Feb 11, 2010 at 2:15 AM, Tollef Fog Heen
tollef.fog.h...@collabora.co.uk wrote:
]] daveg
| I disagree. I have clients who have problems with leftover client
connections
| due to server host failures. They do not write apps in C. For a non-default
| change to be effective we would
Robert Haas robertmh...@gmail.com writes:
On Thu, Feb 11, 2010 at 7:48 AM, Bart Samwel b...@samwel.tk wrote:
Because that's the
underlying assumption of the ratio criterion -- that re-planning with
filled-in parameters takes about as much time as the initial planning run
took.
We only want
On Thu, Feb 11, 2010 at 2:30 AM, Priit Laes pl...@plaes.org wrote:
Also:
Hmm. That implies that you didn't look at the command that you typed
but you did look at its output. I'm not going to say no one does
that (who am I to judge?) but it seems kind of strange to me.
Yes, strange but I
Euler Taveira de Oliveira escribió:
Tom Lane escreveu:
I'm still quite dubious about the usefulness, but I could live with this
if someone explains to me how the printout is going to stay within 24x80
given the inevitable growth in number of configure options ...
AFAICS, we have 40
Bart Samwel b...@samwel.tk writes:
I've been working on a patch to add hostname support to pg_hba.conf.
Have you read the previous discussions about that?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Alexey Klyukin wrote:
Hello,
When developing pl/perlu functions common definitions and methods are often
stored in external .pm modules. During deployment the modules should be
installed somewhere in @INC to be reachable by the perl interpreter. However,
installing the modules to a
Simon Riggs si...@2ndquadrant.com writes:
You still have to perform a backup of the database prior to upgrade and
that also must scan the whole database, so the overall time to upgrade
will still vary according to database size. So I don't see any overall
benefit, just risk, and I cited a
Robert Haas robertmh...@gmail.com wrote:
I've sometimes wondered why keepalives aren't the default for all
TCP connections. They seem like they're usually a Good Thing
(TM), but I wonder if we can think of any situations where someone
might not want them?
I think it's insane not to use
Dear Folks;
A very serious bug was reported on pg_lesslog. So far, I found it's
a bug in pg_compresslog. Please do not use pg_compresslog and
pg_decompresslog until improved version is uploaded.
I strongly advise to take base backup of your database.
I apologize for inconvenience. I'll
From the Slony-I docs (http://www.slony.info/documentation/faq.html) :
Supposing you experience some sort of network outage, the connection
between slon and database may fail, and the slon may figure this out
long before the PostgreSQL instance it was connected to does. The
result is that there
Robert Haas wrote:
On Thu, Feb 11, 2010 at 2:15 AM, Tollef Fog Heen
tollef.fog.h...@collabora.co.uk wrote:
]] daveg
| I disagree. I have clients who have problems with leftover client connections
| due to server host failures. They do not write apps in C. For a non-default
| change to be
2010/2/11 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
On Thu, Feb 11, 2010 at 7:48 AM, Bart Samwel b...@samwel.tk wrote:
Because that's the
underlying assumption of the ratio criterion -- that re-planning with
filled-in parameters takes about as much time as the
On Feb 11, 2010, at 6:24 PM, Andrew Dunstan wrote:
Alexey Klyukin wrote:
Hello,
When developing pl/perlu functions common definitions and methods are often
stored in external .pm modules. During deployment the modules should be
installed somewhere in @INC to be reachable by the perl
On Thu, 11 Feb 2010, Oleg Bartunov wrote:
On Thu, 11 Feb 2010, Tom Lane wrote:
My own feeling about it is that I much preferred the original proposal
of a contrib module with little or no change to core code. I don't want
to be changing core code for this at this late hour. If it were only
Kevin Grittner kevin.gritt...@wicourts.gov writes:
those people who create 2000 lightly used connections to the
database might feel differently.
Yeah I still run against installation using the infamous PHP pconnect()
function. You certainly don't want to add some load there, but that
could urge
Aidan Van Dyk wrote:
* Heikki Linnakangas heikki.linnakan...@enterprisedb.com [100211 09:17]:
If the file is just being copied to the archive when restore_command
('cp', say) is launched, it will copy a half file. That's not a problem
for PITR, because PITR will end at the end of valid WAL
Alexey Klyukin wrote:
On Feb 11, 2010, at 6:24 PM, Andrew Dunstan wrote:
Alexey Klyukin wrote:
Hello,
When developing pl/perlu functions common definitions and methods are often
stored in external .pm modules. During deployment the modules should be
installed somewhere in @INC to
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
The solution is to write the query in an unambiguous way:
SELECT $1::date + 1;
which is good practice, anyway. If it's not obvious to the type
inference system, it's probably not obvious to you, and will probably
surprise you ;)
That
Also, more importantly (from
http://www.slony.info/documentation/slonyadmin.html):
A WAN outage (or flakiness of the WAN in general) can leave database
connections zombied, and typical TCP/IP behaviour will allow those
connections to persist, preventing a slon restart for around two
hours.
On Thu, 11 Feb 2010, Andrew Chernow wrote:
Although, I think Dave's comments have made me change my mind about this
patch. Looks like it serves a good purpose. That said, there is no
guarentee the driver will implement the new feature ... JDBC seems to
lack the ability to get the
On Thu, 2010-02-11 at 23:39 +0900, Koichi Suzuki wrote:
Dear Folks;
A very serious bug was reported on pg_lesslog. So far, I found it's
a bug in pg_compresslog. Please do not use pg_compresslog and
pg_decompresslog until improved version is uploaded.
I strongly advise to take base
On Thu, 11 Feb 2010 10:53:22 -0500, Robert Haas robertmh...@gmail.com
wrote:
On Thu, Feb 11, 2010 at 8:46 AM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
On 2010-02-11 03:44 +0200, I wrote:
I'm going to have to disappoint a bunch of people and give up. :-(
Btw. would it make sense to
Aidan Van Dyk wrote:
* Heikki Linnakangas heikki.linnakan...@enterprisedb.com [100211 09:17]:
Yeah, if you're careful about that, then this change isn't required. But
pg_standby protects against that, so I think it'd be reasonable to have
the same level of protection built-in. It's not a lot
* Heikki Linnakangas heikki.linnakan...@enterprisedb.com [100211 12:04]:
But it can be a problem - without the last WAL (or at least enough of
it) the master switched and archived, you have no guarantee of having
being consistent again (I'm thinking specifically of recovering from a
fresh
On Thu, 11 Feb 2010 19:28:28 +0200, I wrote:
On Thu, 11 Feb 2010 10:53:22 -0500, Robert Haas robertmh...@gmail.com
wrote:
On Thu, Feb 11, 2010 at 8:46 AM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
On 2010-02-11 03:44 +0200, I wrote:
I'm going to have to disappoint a bunch of people
On Feb 11, 2010, at 7:07 PM, Andrew Dunstan wrote:
Alexey Klyukin wrote:
On Feb 11, 2010, at 6:24 PM, Andrew Dunstan wrote:
Alexey Klyukin wrote:
Hello,
When developing pl/perlu functions common definitions and methods are
often stored in external .pm modules. During
Joshua D. Drake wrote:
On Thu, 2010-02-11 at 23:39 +0900, Koichi Suzuki wrote:
Dear Folks;
A very serious bug was reported on pg_lesslog. So far, I found it's
a bug in pg_compresslog. Please do not use pg_compresslog and
pg_decompresslog until improved version is uploaded.
I
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
-1. it isn't necessary for PITR. It's a new requirement for
standby_mode='on', unless we add the file size check into the backend. I
think we should add the file size check to the backend instead and save
admins the headache.
I
Aidan Van Dyk wrote:
* Heikki Linnakangas heikki.linnakan...@enterprisedb.com [100211 12:04]:
But it can be a problem - without the last WAL (or at least enough of
it) the master switched and archived, you have no guarantee of having
being consistent again (I'm thinking specifically of
On Thu, 2010-02-11 at 13:08 -0500, Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
-1. it isn't necessary for PITR. It's a new requirement for
standby_mode='on', unless we add the file size check into the backend. I
think we should add the file size check to
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
I think 'rsync' has the same problem.
There is a switch you can use to create the problem under rsync, but
by default rsync copies to a temporary file name and moves the
completed file to the target name.
-Kevin
--
Sent via
]] Robert Haas
| I've sometimes wondered why keepalives aren't the default for all TCP
| connections. They seem like they're usually a Good Thing (TM), but I
| wonder if we can think of any situations where someone might not want
| them?
As somebody mentioned somewhere else (I think): If you
On Thu, 2010-02-11 at 11:27 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
You still have to perform a backup of the database prior to upgrade and
that also must scan the whole database, so the overall time to upgrade
will still vary according to database size. So I don't
On Thu, Feb 11, 2010 at 1:33 PM, Simon Riggs si...@2ndquadrant.com wrote:
Avoiding a scan before running pg_upgrade is just a performance
optimisation.
But using pg_upgrade AT ALL is also a performance optimization; in
fact AFAICS it's the only reason to use pg_upgrade. So if you take
that
On Mon, Feb 8, 2010 at 5:53 AM, Boszormenyi Zoltan z...@cybertec.at wrote:
New patch is attached with the discussed changes.
This looks OK to me now, but it lacks docs.
I'll set it to Waiting on Author.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Boszormenyi Zoltan escribió:
Robert Haas írta:
...
OK, please change it.
New patch is attached with the discussed changes.
This looks all wrong. PORTAL_ONE_SELECT is now being passed through
FillPortalStore, which runs it to completion, whereas it was previously
passed via
On Thu, 2010-02-11 at 13:42 -0500, Robert Haas wrote:
On Thu, Feb 11, 2010 at 1:33 PM, Simon Riggs si...@2ndquadrant.com wrote:
Avoiding a scan before running pg_upgrade is just a performance
optimisation.
But using pg_upgrade AT ALL is also a performance optimization; in
fact AFAICS it's
Bruce Momjian wrote:
FYI, here is the output that had me confused:
ERROR: 42P01: relation lkjasdf does not exist at character 15
LOCATION: parserOpenTable, parse_relation.c:858
STATEMENT: select * from lkjasdf;
How about something like
ERROR: 42P01: relation lkjasdf
Simon Riggs si...@2ndquadrant.com writes:
Avoiding a scan before running pg_upgrade is just a performance
optimisation. I don't think we should be optimising an upgrade in this
way, especially since sane people do database backups before upgrade
anyway. The optimisation is misplaced. The fact
On Thu, Feb 11, 2010 at 6:03 AM, Bruce Momjian br...@momjian.us wrote:
Of course, maybe the word LOCATION is wrong and it should be FUNCTION:
ERROR: 42P01: relation lkjasdf does not exist at character 15
FUNCTION: parserOpenTable(), parse_relation.c:858
STATEMENT:
On Thu, Feb 11, 2010 at 2:04 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Boszormenyi Zoltan escribió:
Robert Haas írta:
...
OK, please change it.
New patch is attached with the discussed changes.
This looks all wrong. PORTAL_ONE_SELECT is now being passed through
Alvaro Herrera wrote:
Bruce Momjian wrote:
FYI, here is the output that had me confused:
ERROR: 42P01: relation lkjasdf does not exist at character 15
LOCATION: parserOpenTable, parse_relation.c:858
STATEMENT: select * from lkjasdf;
How about something like
On Thu, Feb 11, 2010 at 2:03 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, 2010-02-11 at 13:42 -0500, Robert Haas wrote:
On Thu, Feb 11, 2010 at 1:33 PM, Simon Riggs si...@2ndquadrant.com wrote:
Avoiding a scan before running pg_upgrade is just a performance
optimisation.
But using
1 - 100 of 163 matches
Mail list logo
