* Not correspond yet
?* full_page_write = off
? ?- If the primary is full_page_write = off, archive recovery may
not act
? ? ? normally. Therefore the standby may need to check whether
full_page_write
? ? ? = off to WAL.
Isn't having a standby make the
* Not correspond yet
?* full_page_write = off
? ?- If the primary is full_page_write = off, archive recovery may
not act
? ? ? normally. Therefore the standby may need to check whether
full_page_write
? ? ? = off to WAL.
Isn't having a standby make the
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:
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
On ons, 2011-08-10 at 11:39 +0200, Magnus Hagander wrote:
On Tue, Aug 9, 2011 at 13:38, Peter Eisentraut pete...@gmx.net 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
On Tue, Aug 16, 2011 at 00:05, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, Aug 15, 2011 at 10:32 PM, Magnus Hagander mag...@hagander.net 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
On Tue, Aug 16, 2011 at 10:33, Peter Eisentraut pete...@gmx.net wrote:
On ons, 2011-08-10 at 11:39 +0200, Magnus Hagander wrote:
On Tue, Aug 9, 2011 at 13:38, Peter Eisentraut pete...@gmx.net wrote:
I noticed that the progress reporting code in pg_basebackup does not
allow for translation.
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 upgrade to
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
On Mon, Aug 15, 2011 at 23:49, Greg Stark st...@mit.edu wrote:
On Mon, Aug 15, 2011 at 9:31 PM, Tom Lane t...@sss.pgh.pa.us 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
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 mag...@hagander.net 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
On Mon, Aug 15, 2011 at 13:50, Robert Haas robertmh...@gmail.com wrote:
On Mon, Aug 15, 2011 at 7:03 AM, Magnus Hagander mag...@hagander.net wrote:
The pg_stat_replication view exposes all the fields in
StandbyReplyMessage *except* for the timestamp when the message was
generated. On an active
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.
On 08/16/2011 04:56 AM, Magnus Hagander wrote:
On Mon, Aug 15, 2011 at 23:49, Greg Starkst...@mit.edu wrote:
On Mon, Aug 15, 2011 at 9:31 PM, Tom Lanet...@sss.pgh.pa.us wrote:
... and that would be a seriously bad API. There are not SUSET
restrictions on other resources such as work_mem.
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
+*
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 addresses
On Tue, Aug 16, 2011 at 2:34 AM, senthilnathan
senthilnatha...@gmail.com 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.
On Tue, Aug 16, 2011 at 7:34 AM, senthilnathan
senthilnatha...@gmail.com 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
On Tue, Aug 16, 2011 at 10:51 AM, Magnus Hagander mag...@hagander.net wrote:
On Mon, Aug 15, 2011 at 13:50, Robert Haas robertmh...@gmail.com wrote:
On Mon, Aug 15, 2011 at 7:03 AM, Magnus Hagander mag...@hagander.net wrote:
The pg_stat_replication view exposes all the fields in
On Tue, Aug 16, 2011 at 9:35 AM, Magnus Hagander mag...@hagander.net 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
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 t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
On Tue, Aug 16, 2011 at 9:55 AM, Fujii Masao masao.fu...@gmail.com 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
On Tue, Aug 16, 2011 at 8:54 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, Aug 16, 2011 at 10:51 AM, Magnus Hagander mag...@hagander.net wrote:
On Mon, Aug 15, 2011 at 13:50, Robert Haas robertmh...@gmail.com wrote:
On Mon, Aug 15, 2011 at 7:03 AM, Magnus Hagander mag...@hagander.net
On Tue, Aug 16, 2011 at 7:23 AM, Andrew Dunstan and...@dunslane.net 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
Jeevan Chalke jeevan.cha...@enterprisedb.com 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???
On Mon, Aug 15, 2011 at 6:46 PM, Joachim Wieland j...@mcknight.de wrote:
On Mon, Aug 15, 2011 at 6:09 PM, Jim Nasby j...@nasby.net 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
On Tue, Aug 16, 2011 at 2:25 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Aug 16, 2011 at 8:54 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, Aug 16, 2011 at 10:51 AM, Magnus Hagander mag...@hagander.net
wrote:
On Mon, Aug 15, 2011 at 13:50, Robert Haas robertmh...@gmail.com
On Tue, Aug 16, 2011 at 16:00, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, Aug 16, 2011 at 2:25 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Aug 16, 2011 at 8:54 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, Aug 16, 2011 at 10:51 AM, Magnus Hagander mag...@hagander.net
Magnus Hagander mag...@hagander.net 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
On Tue, Aug 16, 2011 at 16:12, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net 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:
Robert Haas robertmh...@gmail.com 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,
On Tue, Aug 16, 2011 at 10:26 AM, Tom Lane t...@sss.pgh.pa.us 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
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 j...@mcknight.de 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
On Tue, Aug 16, 2011 at 10:43 AM, Alvaro Herrera
alvhe...@commandprompt.com 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 j...@mcknight.de wrote:
Also see what Robert wrote about proxies in between that keep
On Sat, Feb 26, 2011 at 20:59, Magnus Hagander mag...@hagander.net wrote:
On Sat, Feb 26, 2011 at 20:48, Yeb Havinga yebhavi...@gmail.com 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
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 function
On 16.08.2011 16:25, Simon Riggs wrote:
On Tue, Aug 16, 2011 at 9:55 AM, Fujii Masaomasao.fu...@gmail.com 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
On Tue, Aug 16, 2011 at 11:35, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Magnus Hagander mag...@hagander.net 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
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 robertmh...@gmail.com 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
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 full
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 mapping
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 via
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
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/1149512
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
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
On Mon, Aug 15, 2011 at 9:01 PM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com writes:
On Thu, Aug 11, 2011 at 5:09 PM, Tom Lane t...@sss.pgh.pa.us 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
On Aug 15, 2011, at 5:46 PM, Joachim Wieland wrote:
On Mon, Aug 15, 2011 at 6:09 PM, Jim Nasby j...@nasby.net 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 3:45 PM, Tom Lane t...@sss.pgh.pa.us 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
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 issue
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.
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 COMMIT
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
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 j...@nasby.net 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
On Tue, Aug 16, 2011 at 8:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jim Nasby j...@nasby.net 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
On Tue, Aug 16, 2011 at 8:10 PM, Tatsuo Ishii is...@postgresql.org 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
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
Robert Haas robertmh...@gmail.com writes:
On Tue, Aug 16, 2011 at 8:35 PM, Tom Lane t...@sss.pgh.pa.us 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
On Tue, Aug 16, 2011 at 8:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Aug 16, 2011 at 8:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I think we'd be far better off to maintain the position that a failed
BEGIN does not start a transaction, under any
On Tue, Aug 16, 2011 at 8:52 PM, Tatsuo Ishii is...@postgresql.org 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
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 inside
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 is
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
On Tue, Aug 16, 2011 at 9:54 PM, Jeff Davis pg...@j-davis.com 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
On Wed, Aug 17, 2011 at 12:00 AM, Magnus Hagander mag...@hagander.net 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
On Tue, Aug 16, 2011 at 11:56 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Tue, Aug 16, 2011 at 6:24 PM, Heikki Linnakangas
heikki.linnakan...@iki.fi 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
73 matches
Mail list logo
