On Thu, 11 Feb 2010, Tom Lane wrote:
Oleg Bartunov 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 why
there were no
On Thu, 11 Feb 2010, Robert Haas wrote:
2010/2/11 Oleg Bartunov :
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 why
there we
2010/2/10 daveg :
> 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 f
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 i
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 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-p
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 pro
Hi Robert,
On Tue, Feb 9, 2010 at 17:43, Robert Haas wrote:
> On Tue, Feb 9, 2010 at 7:08 AM, Jeroen Vermeulen wrote:
> > = Projected-cost threshold =
> >
> > If a prepared statement takes parameters, and the generic plan has a high
> > projected cost, re-plan each EXECUTE individually with all
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 abou
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 sub
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
2010/2/11 Bart Samwel :
> Hi Robert,
>
> On Tue, Feb 9, 2010 at 17:43, Robert Haas wrote:
>>
>> On Tue, Feb 9, 2010 at 7:08 AM, Jeroen Vermeulen wrote:
>> > = Projected-cost threshold =
>> >
>> > If a prepared statement takes parameters, and the generic plan has a
>> > high
>> > projected cost, r
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?
>
On Thu, Feb 11, 2010 at 13:25, Pavel Stehule wrote:
> 2010/2/11 Bart Samwel :
> > 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
On Thu, Feb 11, 2010 at 7:39 AM, Bart Samwel wrote:
> On Thu, Feb 11, 2010 at 13:25, Pavel Stehule
> wrote:
>>
>> 2010/2/11 Bart Samwel :
>> > Perhaps this could be based on a (configurable?) ratio of observed
>> > planning
>> > time and projected execution time. I mean, if planning it the first
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_comman
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
On Thu, Feb 11, 2010 at 13:41, Robert Haas wrote:
> On Thu, Feb 11, 2010 at 7:39 AM, Bart Samwel 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 is one of the things that
>
On Thu, Feb 11, 2010 at 3:38 AM, Oleg Bartunov 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 paid
> you
On Thu, Feb 11, 2010 at 7:48 AM, Bart Samwel wrote:
> On Thu, Feb 11, 2010 at 13:41, Robert Haas wrote:
>>
>> On Thu, Feb 11, 2010 at 7:39 AM, Bart Samwel wrote:
>> > Anyhow, I have no clue how much time the planner takes. Can anybody
>> > provide
>> > any statistics in that regard?
>>
>> It dep
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
On Thu, Feb 11, 2010 at 3:00 AM, Oleg Bartunov 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 documen
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 t
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 req
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 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 try.
pg_standby will
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 tha
On Thu, 2010-02-11 at 14:41 +0100, Dimitri Fontaine wrote:
> Simon Riggs 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 tha
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 require
* Heikki Linnakangas [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 using simple commands like 'cp' or
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, p
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
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 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 getting more
and more f
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 t
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 upl
* Heikki Linnakangas [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 half WAL file in standby mode i
On Thu, Feb 11, 2010 at 1:18 PM, Robert Haas 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 match what I'v
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 me
On Thu, 11 Feb 2010, Robert Haas wrote:
On Thu, Feb 11, 2010 at 3:00 AM, Oleg Bartunov 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 p
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 alr
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.
On Thu, 11 Feb 2010, Greg Stark wrote:
On Thu, Feb 11, 2010 at 1:18 PM, Robert Haas 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,
Bart Samwel 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 maybe we cou
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 fi
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
ex
On Thu, Feb 11, 2010 at 8:46 AM, Marko Tiikkaja
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 useful because you can w
Simon Riggs 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.
See the comments for u
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 install
Ühel kenal päeval, K, 2010-02-10 kell 21:17, kirjutas Tom Lane:
> Robert Haas writes:
> > On Wed, Feb 10, 2010 at 3:30 PM, Alvaro Herrera
> > wrote:
> >> If this doesn't fit in 24x80 maybe we need to find a more compact way to
> >> display things.
>
> > +1. I wouldn't mind a one-line summary, b
]] 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 ch
On Thu, Feb 11, 2010 at 2:15 AM, Tollef Fog Heen
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 need to have all the client
Robert Haas writes:
> On Thu, Feb 11, 2010 at 7:48 AM, Bart Samwel 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 to replan when replannin
On Thu, Feb 11, 2010 at 2:30 AM, Priit Laes 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 don't r
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 hav
Bart Samwel 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 subscription:
ht
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 location
Simon Riggs 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 similar situation wher
Robert Haas 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 them at all, but the
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 upl
>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
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 need to have all t
2010/2/11 Tom Lane :
> Robert Haas writes:
>> On Thu, Feb 11, 2010 at 7:48 AM, Bart Samwel 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
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
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
t
"Kevin Grittner" 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 them into arranging for
Aidan Van Dyk wrote:
> * Heikki Linnakangas [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 ha
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 ;
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 backing
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 ba
On Thu, 11 Feb 2010 10:53:22 -0500, Robert Haas
wrote:
> On Thu, Feb 11, 2010 at 8:46 AM, Marko Tiikkaja
> 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 th
Aidan Van Dyk wrote:
> * Heikki Linnakangas [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 of code.
>
> This 1 check
* Heikki Linnakangas [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 backup)
>
> You have to wa
On Thu, 11 Feb 2010 19:28:28 +0200, I wrote:
> On Thu, 11 Feb 2010 10:53:22 -0500, Robert Haas
> wrote:
>> On Thu, Feb 11, 2010 at 8:46 AM, Marko Tiikkaja
>> 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 i
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 exte
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.
Heikki Linnakangas 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 think the file size check needs to
Aidan Van Dyk wrote:
> * Heikki Linnakangas [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 ba
On Thu, 2010-02-11 at 13:08 -0500, Tom Lane wrote:
> Heikki Linnakangas 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
>
Heikki Linnakangas 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 pgsql-hackers mailing list (pgsql-hack
]] 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 pa
On Thu, 2010-02-11 at 11:27 -0500, Tom Lane wrote:
> Simon Riggs 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
On Thu, Feb 11, 2010 at 1:33 PM, Simon Riggs 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 away there's no reason
On Mon, Feb 8, 2010 at 5:53 AM, Boszormenyi Zoltan 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 changes to your s
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 P
On Thu, 2010-02-11 at 13:42 -0500, Robert Haas wrote:
> On Thu, Feb 11, 2010 at 1:33 PM, Simon Riggs 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 reas
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 "l
Simon Riggs 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 that we are active
On Thu, Feb 11, 2010 at 6:03 AM, Bruce Momjian 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: select * fro
On Thu, Feb 11, 2010 at 2:04 PM, Alvaro Herrera
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
> FillPortalStore, wh
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 somethin
On Thu, Feb 11, 2010 at 2:03 PM, Simon Riggs wrote:
> On Thu, 2010-02-11 at 13:42 -0500, Robert Haas wrote:
>> On Thu, Feb 11, 2010 at 1:33 PM, Simon Riggs wrote:
>> > Avoiding a scan before running pg_upgrade is just a performance
>> > optimisation.
>>
>> But using pg_upgrade AT ALL is also a pe
1 - 100 of 163 matches
Mail list logo
