Thanks for your reply.
What will happen if you issue *checkpoint* at STANDBY. I presume that it
will flush the data to the disk.
Will there be any conflict with the master WAL.(like checkpoint location...)
Senthil
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Backup
I found that I forgot to remove levelstep and buffersize from reloptions.c.
Updated patch is attached.
--
With best regards,
Alexander Korotkov.
gist_fast_build-0.14.1.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
On ons, 2011-08-10 at 11:39 +0200, Magnus Hagander wrote:
> On Tue, Aug 9, 2011 at 13:38, Peter Eisentraut wrote:
> > I noticed that the progress reporting code in pg_basebackup does not
> > allow for translation. This would normally be easy to fix, but this
> > code has a number of tricky issues
On Tue, Aug 16, 2011 at 00:05, Simon Riggs wrote:
> On Mon, Aug 15, 2011 at 10:32 PM, Magnus Hagander wrote:
>
>>> At present the WALSender only sends from one file at a time, so
>>> sending a message when we open a new file would be straightforward.
>>
>> Are you sure? We can receive a single me
On Tue, Aug 16, 2011 at 10:33, Peter Eisentraut wrote:
> On ons, 2011-08-10 at 11:39 +0200, Magnus Hagander wrote:
>> On Tue, Aug 9, 2011 at 13:38, Peter Eisentraut wrote:
>> > I noticed that the progress reporting code in pg_basebackup does not
>> > allow for translation. This would normally be
On mån, 2011-08-15 at 18:39 +0100, Peter Geoghegan wrote:
> > If you want to upgrade a system running 8.3 (that uses float based
> timestamps) in using
> > pg_upgrade you must compile 9.0 (or 8.4 or 9.1) with
> > --disable-integer-datetimes. If at some point in the future you
> then want
> > to up
Hi,
When I tested the PITR on git master with max_wal_senders > 0,
I found that the following inappropriate log meesage was always
output even though cascading replication is not in progress. Attached
patch fixes this problem.
LOG: terminating all walsender processes to force cascaded
standb
On Mon, Aug 15, 2011 at 23:49, Greg Stark wrote:
> On Mon, Aug 15, 2011 at 9:31 PM, Tom Lane wrote:
>> ... and that would be a seriously bad API. There are not SUSET
>> restrictions on other resources such as work_mem. Why do we need
>> one for this?
>
> I think a better analogy would be imposi
Hi Tom,
While going through few test-cases, I found that we cannot have two opened
cursors with same name even though they are in two different functions. Here
is what I mean:
1. I have two functions func1 and func2.
2. func1 calls func2
3. Both has cursor with same name, say mycursor
4. Somehow
Magnus Hagander writes:
> Note that the progress indicator will *always* count wrong when you
> choose to include WAL, since we just don't know how much WAL there
> should be. I guess in this case we could just advance the "end
> counter" as well as we go, making sure it doesn't shoot above 100%.
On Mon, Aug 15, 2011 at 13:50, Robert Haas wrote:
> On Mon, Aug 15, 2011 at 7:03 AM, Magnus Hagander wrote:
>> The pg_stat_replication view exposes all the fields in
>> StandbyReplyMessage *except* for the timestamp when the message was
>> generated. On an active system this is not all that inter
On 08/14/2011 12:31 AM, Heikki Linnakangas wrote:
The same idea could of course be used to calculate the effective cache hit
ratio for each table. Cache hit ratio would have the problem of feedback loops,
though.
Yeah, I'm not excited about making the planner and statistics more
dynamic. Feedb
On 08/16/2011 04:56 AM, Magnus Hagander wrote:
On Mon, Aug 15, 2011 at 23:49, Greg Stark wrote:
On Mon, Aug 15, 2011 at 9:31 PM, Tom Lane wrote:
... and that would be a seriously bad API. There are not SUSET
restrictions on other resources such as work_mem. Why do we need
one for this?
I
Looking at the calculation of levelStep:
+ /*
+* Calculate levelStep by available amount of memory. We should be able
to
+* load into main memory one page of each underlying node buffer (which
+* are in levelStep below). That give constraint over
+* mainten
Accidentally specifying an IPv6 address in pg_hba.conf on a system
that doesn't have ipv6 support gives the following error:
LOG: specifying both host name and CIDR mask is invalid: "::1/128"
Which is obviously wrong, because I didn't do that. Do we need to
detect and special-case ipv6 addresse
On Tue, Aug 16, 2011 at 2:34 AM, senthilnathan
wrote:
> Thanks for your reply.
>
> What will happen if you issue *checkpoint* at STANDBY. I presume that it
> will flush the data to the disk.
It will perform a restartpoint.
http://www.postgresql.org/docs/9.0/static/wal-configuration.html
--
Rob
On Tue, Aug 16, 2011 at 7:34 AM, senthilnathan
wrote:
> Thanks for your reply.
>
> What will happen if you issue *checkpoint* at STANDBY. I presume that it
> will flush the data to the disk.
Yes. On the standby that is known as a restartpoint.
> Will there be any conflict with the master WAL.(li
On Tue, Aug 16, 2011 at 10:51 AM, Magnus Hagander wrote:
> On Mon, Aug 15, 2011 at 13:50, Robert Haas wrote:
>> On Mon, Aug 15, 2011 at 7:03 AM, Magnus Hagander wrote:
>>> The pg_stat_replication view exposes all the fields in
>>> StandbyReplyMessage *except* for the timestamp when the message w
On Tue, Aug 16, 2011 at 9:35 AM, Magnus Hagander wrote:
>> So right now what we do is allow a single packet to span multiple
>> files, but since MAX_SEND_SIZE is 128KB it will always be smaller than
>> a single file, so we can only ever span two files at most.
>
> Unless someone has tweaked their
On Tue, Aug 16, 2011 at 4:04 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> I can see that that's equal to the formula given in the paper, log_B(M/4B),
> but I couldn't see any explanation for that formula in the paper. Your
> explanation makes sense, but where did it come
On Tue, Aug 16, 2011 at 12:37 AM, Tom Lane wrote:
> Robert Haas writes:
>> $SUBJECT is wildly out-of-date. Is there any point in keeping this,
>> given the large (and actually correct) comment block near the top of
>> sinvaladt.c?
>
> Huh, I never noticed that file before. Yeah, it seems useles
On Tue, Aug 16, 2011 at 9:55 AM, Fujii Masao wrote:
> When I tested the PITR on git master with max_wal_senders > 0,
> I found that the following inappropriate log meesage was always
> output even though cascading replication is not in progress. Attached
> patch fixes this problem.
>
> LOG: t
On Tue, Aug 16, 2011 at 8:54 AM, Simon Riggs wrote:
> On Tue, Aug 16, 2011 at 10:51 AM, Magnus Hagander wrote:
>> On Mon, Aug 15, 2011 at 13:50, Robert Haas wrote:
>>> On Mon, Aug 15, 2011 at 7:03 AM, Magnus Hagander
>>> wrote:
The pg_stat_replication view exposes all the fields in
S
On Tue, Aug 16, 2011 at 7:23 AM, Andrew Dunstan wrote:
> There is no LIMIT imposed on a query by a server setting, which would be the
> right analogy here.
I am not sure I understand any of these analogies. I think Peter's
point is that it's not very difficult to write (perhaps accidentally)
a C
Jeevan Chalke writes:
> 1. I have two functions func1 and func2.
> 2. func1 calls func2
> 3. Both has cursor with same name, say mycursor
> 4. Somehow I forgot closing it
> 5. executing func1 throws an error 'cursor "mycursor" already in use'
> Is this expected behavior???
Yes ... or at least, i
On Mon, Aug 15, 2011 at 6:46 PM, Joachim Wieland wrote:
> On Mon, Aug 15, 2011 at 6:09 PM, Jim Nasby wrote:
>> I suspect that all the other cases of BEGIN failing would be syntax errors,
>> so
>> you would immediately know in testing that something was wrong. A missing
>> file
>> is definitely
On Tue, Aug 16, 2011 at 2:25 PM, Robert Haas wrote:
> On Tue, Aug 16, 2011 at 8:54 AM, Simon Riggs wrote:
>> On Tue, Aug 16, 2011 at 10:51 AM, Magnus Hagander
>> wrote:
>>> On Mon, Aug 15, 2011 at 13:50, Robert Haas wrote:
On Mon, Aug 15, 2011 at 7:03 AM, Magnus Hagander
wrote:
>>>
On Tue, Aug 16, 2011 at 16:00, Simon Riggs wrote:
> On Tue, Aug 16, 2011 at 2:25 PM, Robert Haas wrote:
>> On Tue, Aug 16, 2011 at 8:54 AM, Simon Riggs wrote:
>>> On Tue, Aug 16, 2011 at 10:51 AM, Magnus Hagander
>>> wrote:
On Mon, Aug 15, 2011 at 13:50, Robert Haas wrote:
> On Mon,
Magnus Hagander writes:
> Accidentally specifying an IPv6 address in pg_hba.conf on a system
> that doesn't have ipv6 support gives the following error:
> LOG: specifying both host name and CIDR mask is invalid: "::1/128"
> Which is obviously wrong, because I didn't do that. Do we need to
> det
On Tue, Aug 16, 2011 at 16:12, Tom Lane wrote:
> Magnus Hagander writes:
>> Accidentally specifying an IPv6 address in pg_hba.conf on a system
>> that doesn't have ipv6 support gives the following error:
>
>> LOG: specifying both host name and CIDR mask is invalid: "::1/128"
>
>> Which is obviou
Robert Haas writes:
> I don't think it's going to be feasible to implement a security
> restriction that keeps untrusted users from hosing the machine with a
> long running CTE; there are nearly infinitely many ways for an
> untrusted user who can run queries to hose the machine, and plugging
> on
On Tue, Aug 16, 2011 at 10:26 AM, Tom Lane wrote:
>> In fact, we already have some things sort of like this: you can use
>> statement_timeout to kill queries that run for too long, and we just
>> recently added temp_file_limit to kill those that eat too much temp
>> file space. I can see a good
Excerpts from Robert Haas's message of mar ago 16 09:59:04 -0400 2011:
> On Mon, Aug 15, 2011 at 6:46 PM, Joachim Wieland wrote:
> > Also see what Robert wrote about proxies in between that keep track
> > of the transaction state. Consider they see a BEGIN query that
> > fails. How would they kno
On Tue, Aug 16, 2011 at 10:43 AM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of mar ago 16 09:59:04 -0400 2011:
>> On Mon, Aug 15, 2011 at 6:46 PM, Joachim Wieland wrote:
>
>> > Also see what Robert wrote about proxies in between that keep track
>> > of the transaction state. Con
On Sat, Feb 26, 2011 at 20:59, Magnus Hagander wrote:
> On Sat, Feb 26, 2011 at 20:48, Yeb Havinga wrote:
>> On 2011-02-26 18:19, Magnus Hagander wrote:
>>>
>>> Attached is an updated version of the patch that includes these
>>> changes, as well as Windows support and an initial cut at a ref page
After backporting plpython.c from HEAD, this is the error message I get:
ERROR: key "pg.dropped.6" not found in mapping
HINT: To return null in a column, add the value None to the mapping
with the key named after the column.
CONTEXT: while creating return value
PL/Python functio
On 16.08.2011 16:25, Simon Riggs wrote:
On Tue, Aug 16, 2011 at 9:55 AM, Fujii Masao wrote:
When I tested the PITR on git master with max_wal_senders> 0,
I found that the following inappropriate log meesage was always
output even though cascading replication is not in progress. Attached
patch
On Tue, Aug 16, 2011 at 11:35, Dimitri Fontaine wrote:
> Magnus Hagander writes:
>> Note that the progress indicator will *always* count wrong when you
>> choose to include WAL, since we just don't know how much WAL there
>> should be. I guess in this case we could just advance the "end
>> counte
On 16/08/11 16:52, Jean-Baptiste Quenot wrote:
> After backporting plpython.c from HEAD, this is the error message I get:
>
> ERROR: key "pg.dropped.6" not found in mapping
> HINT: To return null in a column, add the value None to the mapping
> with the key named after the column
On 16 August 2011 14:43, Robert Haas wrote:
> What would the following program do?
> 10 PRINT "HELLO"
> 20 GOTO 10
>
> And gets back an infinite stream of HELLO HELLO HELLO HELLO HELLO
heh, that's pretty funny. It also compliments my view, because the
Turing test is only failed because the hu
On 11-08-16 02:09 AM, Jun Ishiduka wrote:
>
> Thanks.
>
> This has the following two problems.
> * pg_start_backup() must set 'on' to full_page_writes of the master that
>is actual writing of the WAL, but not the standby.
Is there any way to tell from the WAL segments if they contain the ful
On 16/08/11 17:06, Jan Urbański wrote:
> On 16/08/11 16:52, Jean-Baptiste Quenot wrote:
>> After backporting plpython.c from HEAD, this is the error message I get:
>>
>> ERROR: key "pg.dropped.6" not found in mapping
>> HINT: To return null in a column, add the value None to the m
On tis, 2011-08-16 at 16:17 +0200, Magnus Hagander wrote:
> Well, I got this on a win64 build. It's *supposed* to have ipv6. I
> wonder if it breaks on windows just because there is no ipv6 address
> on the machine...
It would mean that getaddrinfo() of "::1" failed. That seems weird.
--
Sent
Dear Jan,
Sorry I typed the wrong git commands. With latest plpython from
branch master I got the same gdb backtrace as reported before. I
managed to wrap up a testcase that fails 100% of times on my setup:
https://gist.github.com/1149512
Hope it crashes on your side too :-)
This is the result
On 16/08/11 19:07, Jean-Baptiste Quenot wrote:
> Dear Jan,
>
> Sorry I typed the wrong git commands. With latest plpython from
> branch master I got the same gdb backtrace as reported before. I
> managed to wrap up a testcase that fails 100% of times on my setup:
> https://gist.github.com/114951
Why is there ever a buffer on the root node? It seems like a waste of
time to load N tuples from the heap into the root buffer, only to empty
the buffer after it fills up. You might as well pull tuples directly
from the heap.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
On Tue, Aug 16, 2011 at 9:43 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> Why is there ever a buffer on the root node? It seems like a waste of time
> to load N tuples from the heap into the root buffer, only to empty the
> buffer after it fills up. You might as well pull
On 16.08.2011 21:46, Alexander Korotkov wrote:
On Tue, Aug 16, 2011 at 9:43 PM, Heikki Linnakangas<
heikki.linnakan...@enterprisedb.com> wrote:
Why is there ever a buffer on the root node? It seems like a waste of time
to load N tuples from the heap into the root buffer, only to empty the
buff
On Mon, Aug 15, 2011 at 9:01 PM, Tom Lane wrote:
> This might be the last bug from my concurrent-vacuum-full testing --- at
> least, I have no remaining unexplained events from about two full days
> of running the tests. The ones that are left involve backends randomly
> failing like this:
>
> ps
Robert Haas writes:
> On Thu, Aug 11, 2011 at 5:09 PM, Tom Lane wrote:
>> What's bothering me at the moment is that the CLOBBER_CACHE_ALWAYS hack,
>> which was meant to expose exactly this sort of problem, failed to do so
>> --- buildfarm member jaguar has been running with that flag for ages and
On Aug 15, 2011, at 5:46 PM, Joachim Wieland wrote:
> On Mon, Aug 15, 2011 at 6:09 PM, Jim Nasby wrote:
>> I suspect that all the other cases of BEGIN failing would be syntax errors,
>> so
>> you would immediately know in testing that something was wrong. A missing
>> file
>> is definitely not a
On Tue, Aug 16, 2011 at 3:45 PM, Tom Lane wrote:
>> It would be nice to move the short-circuit test I recently inserted at
>> the top of SIGetDataEntries() somewhere higher up in the call stack,
>> but right now the layers of abstraction are so thick that it's not
>> exactly clear how to do that.
I'm looking into the idea I mentioned earlier:
> All is not entirely lost, however: there's still some possible
> performance benefit to be gained here, if we go to the scheme of
> identifying victim catcache entries by hashvalue only. Currently,
> each heap_update in a cached catalog has to issu
On Tue, 2011-08-16 at 11:01 -0500, Jim Nasby wrote:
> Also, an invalid transaction seems to be the result of least
> surprise... if you cared enough to begin a transaction, you're going
> to expect that either everything between that and the COMMIT succeeds
> or fails, not something in-between.
Ag
On Aug 16, 2011, at 5:40 PM, Jeff Davis wrote:
> On Tue, 2011-08-16 at 11:01 -0500, Jim Nasby wrote:
>> Also, an invalid transaction seems to be the result of least
>> surprise... if you cared enough to begin a transaction, you're going
>> to expect that either everything between that and the COMMI
Hi,
I'm working on implemeting query cache for pgpool-II. The query cache
must be deleted if related tables are dropped. Finding tables oids
from DROP TABLE t1, t2, t3... is easy. Problem is DROP TABLE
CASCADE. It seems there's no easy way to find table oids which will be
deleted by DROP TABLE CAS
Just a suggestion, but...
Why not using an external wrapper function on reportDependentObjects in
dependency.c to find the list of Oids for a cascade deletion based on a list
of objects?
Isn't it possible?
Regards,
--
Michael Paquier
http://michael.otacoo.com
Jim Nasby writes:
> Well, it appears we have a larger problem, as Robert pointed out that trying
> to start a writable transaction on a hot standby leaves you not in a
> transaction (which I feel is a problem).
> So IMHO the right thing to do here is make it so that runtime errors in BEGIN
> l
On Tue, Aug 16, 2011 at 8:35 PM, Tom Lane wrote:
> Jim Nasby writes:
>> Well, it appears we have a larger problem, as Robert pointed out that trying
>> to start a writable transaction on a hot standby leaves you not in a
>> transaction (which I feel is a problem).
>
>> So IMHO the right thing t
On Tue, Aug 16, 2011 at 8:10 PM, Tatsuo Ishii wrote:
> I'm working on implemeting query cache for pgpool-II. The query cache
> must be deleted if related tables are dropped. Finding tables oids
> from DROP TABLE t1, t2, t3... is easy. Problem is DROP TABLE
> CASCADE. It seems there's no easy way t
> Presumably it would also need to invalidated if someone did ALTER
> TABLE (which might recurse into unspecified children).
Good point. For DROP TABLE/ALTER TABLE, I need to take care of its chidren.
> It sort of seems like what you want to do is snoop the sinval traffic...
It's hard for pgpool
Robert Haas writes:
> On Tue, Aug 16, 2011 at 8:35 PM, Tom Lane wrote:
>> I think we'd be far better off to maintain the position that a failed
>> BEGIN does not start a transaction, under any circumstances.
> Also agreed.
>> To do
>> that, we cannot have this new option attached to the BEGIN,
On Tue, Aug 16, 2011 at 8:53 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Aug 16, 2011 at 8:35 PM, Tom Lane wrote:
>>> I think we'd be far better off to maintain the position that a failed
>>> BEGIN does not start a transaction, under any circumstances.
>
>> Also agreed.
>
>>> To do
>>>
On Tue, Aug 16, 2011 at 8:52 PM, Tatsuo Ishii wrote:
>> Presumably it would also need to invalidated if someone did ALTER
>> TABLE (which might recurse into unspecified children).
>
> Good point. For DROP TABLE/ALTER TABLE, I need to take care of its chidren.
>
>> It sort of seems like what you wa
On Tue, 2011-08-16 at 20:35 -0400, Tom Lane wrote:
> I'm not convinced by the above argument, because it requires that
> you pretend there's a significant difference between syntax errors and
> "run time" errors (whatever those are).
After a syntax error like "COMMMIT" the transaction will remain
On 08/16/2011 08:52 PM, Tatsuo Ishii wrote:
>> Presumably it would also need to invalidated if someone did ALTER
>> TABLE (which might recurse into unspecified children).
>
> Good point. For DROP TABLE/ALTER TABLE, I need to take care of its chidren.
>
>> It sort of seems like what you want to do
On Tue, 2011-08-16 at 21:08 -0400, Robert Haas wrote:
> attaching it to BEGIN feels natural to me.
My only objection is that people have different expectations about
whether the session will remain in a transaction block when they
encounter an error. So, it's hard to make this work without surpri
On Tue, Aug 16, 2011 at 9:54 PM, Jeff Davis wrote:
>> If we did add another toplevel command, what would we call it?
>
> "SET TRANSACTION SNAPSHOT" perhaps?
Hmm, that's not bad, but I think we'd have to partially reserve
TRANSACTION to make it work, which doesn't seem worth the pain it
would caus
On Wed, Aug 17, 2011 at 12:00 AM, Magnus Hagander wrote:
> Adjust total size in pg_basebackup progress report when reality changes
>
> When streaming including WAL, the size estimate will always be incorrect,
> since we don't know how much WAL is included. To make sure the output doesn't
> look co
On Tue, Aug 16, 2011 at 11:56 PM, Heikki Linnakangas
wrote:
> I think there's a race condition here. If a walsender is just starting up,
> it might not have registered itself as a walsender yet. It's actually been
> there before this patch to suppress the log message.
Right. To address this probl
On Tue, Aug 16, 2011 at 6:24 PM, Heikki Linnakangas
wrote:
> Fix bogus comment that claimed that the new BACKUP METHOD line in
> backup_label was new in 9.0. Spotted by Fujii Masao.
Thanks for fixing that.
What about the remaining of the patch which I submitted? Unless I'm missing
something, the
On 17.08.2011 00:17, Tom Lane wrote:
I'm looking into the idea I mentioned earlier:
All is not entirely lost, however: there's still some possible
performance benefit to be gained here, if we go to the scheme of
identifying victim catcache entries by hashvalue only. Currently,
each heap_update
72 matches
Mail list logo