Hi,
Tom Lane t...@sss.pgh.pa.us writes:
Simon Riggs si...@2ndquadrant.com writes:
Hot Standby returns ERRCODE_READ_ONLY_SQL_TRANSACTION in most cases
for illegal actions on a standby.
I don't think I like this patch: you are promoting what are and ought to
be very low-level internal sanity
On Fri, Jan 13, 2012 at 8:55 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
I felt that we were missing something simple here, but after review I
think we finally have all the pieces to achieve that with current 9.2
code base in fact.
Good, patch revoked. No time wasted, it was worth
On Thu, Jan 12, 2012 at 8:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Thu, Jan 12, 2012 at 5:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
More like \once ... any SQL command or meta command here ...
if we want to extend the scripting language. But I'd
On Wed, 21 Sep 2011 18:13:07 +0200, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 21.09.2011 18:46, Tom Lane wrote:
The idea that I was toying with was to allow the regular SQL-callable
comparison function to somehow return a function
Hi,
When I looked at pg_stat_replication just after starting the standby before
executing any write transactions on the master, I found that replay_location
indicated incorrect location different from sent/write/flush_location. Then,
if I ran write transaction on the master, replay_location
At this point I feel that this new functionality might be a bit
overkill for postgres, maybe it's better to stay lean and mean rather
than add a controversial feature like this.
I also agree that a more general replication timeout variable would be
more useful to a larger audience but that would
Hello,
I wonder if it would be possible to have a fast table clone function
(data only) while copying the corresponding data files
instead of using the CREATE TABLE AS way.
pg_upgrade seems to have such a mechanisms, though it requires to first
stop the server...
This would of course require to
On Fri, Jan 13, 2012 at 10:04 AM, Fujii Masao masao.fu...@gmail.com wrote:
When I looked at pg_stat_replication just after starting the standby before
executing any write transactions on the master, I found that replay_location
indicated incorrect location different from
Hi,
I found that even read transaction waits for sync rep when it generates
WAL records even if XID is not assigned. For example, imagine the case
where SELECT query does a heap clean operation and generates
XLOG_HEAP2_CLEAN record. ISTM that such a read transaction doesn't
need to wait for sync
On Fri, Jan 13, 2012 at 11:30 AM, Fujii Masao masao.fu...@gmail.com wrote:
I found that even read transaction waits for sync rep when it generates
WAL records even if XID is not assigned. For example, imagine the case
where SELECT query does a heap clean operation and generates
On Fri, Jan 13, 2012 at 7:30 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, Jan 13, 2012 at 9:15 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, Jan 13, 2012 at 7:41 AM, Fujii Masao masao.fu...@gmail.com wrote:
Thought? Comments?
This is almost exactly the same as my patch series
On Fri, Jan 13, 2012 at 12:27 PM, Fujii Masao masao.fu...@gmail.com wrote:
In my patch, the reason I avoided doing WRITE mode (which we had
previously referred to as RECV) was that no fsync of the WAL contents
takes place. In that case we are applying changes using un-fsynced WAL
data and in
There's one part of this that's still fuzzy in the spec I'd like to
clarify, if nothing else than for my own memory's sake--as the person
most likely to review a random pgbench patch. Simon gave an example
like this:
pgbench -x SET synchronous_commit = off
All are agreed this should take
On Fri, Jan 13, 2012 at 5:56 AM, Marc Mamin m.ma...@intershop.de wrote:
I wonder if it would be possible to have a fast table clone function (data
only) while copying the corresponding data files
instead of using the CREATE TABLE AS way.
pg_upgrade seems to have such a mechanisms, though it
This would be great, but I can't C :-(
Marc
-Original Message-
From: Robert Haas [mailto:robertmh...@gmail.com]
Sent: Freitag, 13. Januar 2012 14:12
To: Marc Mamin
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] CLONE TABLE DATA TO new_table
On Fri, Jan 13, 2012 at 5:56
The open items list for 9.2 says
Index-only scans need to be disabled when running under Hot Standby
There is no explanation, so please explain here so we can change it,
if possible.
Not sure its great policy to keep implementing things that don't work
on HS, while not giving a proper chance
On 01/12/2012 11:07 PM, Nick Roosevelt wrote:
Just reviewed the patch for adding URI connection string support for
libpg.
...Seems like the file has changed since this patch was created.
Please recreate the patch.
Thanks for the review. In the CommitFest appliation, it looks like
someone
On Fri, Jan 6, 2012 at 12:45 PM, Robert Haas robertmh...@gmail.com wrote:
Oh, that's brilliant. OK, I'll go try that.
All right, that test does in fact reveal the broken-ness of the
current code, and the patch I committed upthread does seem to fix it,
so I've committed that.
After further
On 01/03/2012 12:59 PM, Tom Lane wrote:
Noah Mischn...@leadboat.com writes:
Regarding the other message, avoid composing a translated message from
independently-translated parts.
Yes. I haven't looked at the patch, but I wonder whether it wouldn't be
better to dodge both of these
On Fri, Jan 13, 2012 at 14:42, Greg Smith g...@2ndquadrant.com wrote:
On 01/03/2012 12:59 PM, Tom Lane wrote:
Noah Mischn...@leadboat.com writes:
Regarding the other message, avoid composing a translated message from
independently-translated parts.
Yes. I haven't looked at the patch,
On Fri, Jan 13, 2012 at 8:27 AM, Simon Riggs si...@2ndquadrant.com wrote:
The open items list for 9.2 says
Index-only scans need to be disabled when running under Hot Standby
There is no explanation, so please explain here so we can change it,
if possible.
Not sure its great policy to keep
On Fri, Jan 13, 2012 at 2:03 PM, Robert Haas robertmh...@gmail.com wrote:
Since the xmin horizon on the standby may precede the xmin horizon on
the master
When hot_standby_feedback is turned on, the xmin of the standby is
provided to the master to ensure the situation you describe never
I think that people who are using index-only scans are going to want
some way to find out the degree to which the scans are in fact
index-only.
So here's a 5-line patch that adds the number of heap fetches to the
EXPLAIN ANALYZE output. This might not be all the instrumentation
we'll ever want
On Fri, Jan 13, 2012 at 10:17 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, Jan 13, 2012 at 2:03 PM, Robert Haas robertmh...@gmail.com wrote:
Since the xmin horizon on the standby may precede the xmin horizon on
the master
When hot_standby_feedback is turned on, the xmin of the
On Fri, Jan 13, 2012 at 16:21, Robert Haas robertmh...@gmail.com wrote:
I think that people who are using index-only scans are going to want
some way to find out the degree to which the scans are in fact
index-only.
So here's a 5-line patch that adds the number of heap fetches to the
EXPLAIN
On Jan 13, 2012, at 8:03 AM, Robert Haas wrote:
Or,
we could try to lift this restriction in the special case when
hot_standby_feedback is set, though I have a feeling that's not really
robust - any time you lose the connection to the master, it'll lose
your xmin holdback and possibly mark
On 13 January 2012 15:21, Robert Haas robertmh...@gmail.com wrote:
I think that people who are using index-only scans are going to want
some way to find out the degree to which the scans are in fact
index-only.
So here's a 5-line patch that adds the number of heap fetches to the
EXPLAIN
On Fri, Jan 13, 2012 at 10:29 AM, Magnus Hagander mag...@hagander.net wrote:
On Fri, Jan 13, 2012 at 16:21, Robert Haas robertmh...@gmail.com wrote:
I think that people who are using index-only scans are going to want
some way to find out the degree to which the scans are in fact
index-only.
On Fri, Jan 13, 2012 at 10:31 AM, Jim Nasby j...@nasby.net wrote:
Perhaps it would be possible to keep older copies of pages around when there
are older transactions running on the standby?
I've thought about that... it's basically a rollback segment, which
for that matter might be judged
On 13 January 2012 15:31, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jan 13, 2012 at 10:29 AM, Magnus Hagander mag...@hagander.net wrote:
Would also be good to have counter sin pg_stat_* for this, since you'd
usually want to look at this kind of data over time as well. In your
plans? ;)
Johann 'Myrkraverk' Oskarsson joh...@2ndquadrant.com writes:
Why would a string comparison work in one case and not another? In
the following example, it works to compare a and b, but not a and d.
This is in a C module which calls
DirectFunctionCall2( text_le, d1, d2 );
As of 9.1, I'd
[reviving discussion of another old patch]
In post:
http://archives.postgresql.org/pgsql-hackers/2011-06/msg00870.php
Florian Pflug f...@phlo.org wrote:
Updated patch attached.
Thanks.
The trigger depth is incremented before calling the trigger
function in ExecCallTriggerFunc() and
On Fri, Jan 13, 2012 at 10:41 AM, Peter Geoghegan pe...@2ndquadrant.com wrote:
On 13 January 2012 15:31, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jan 13, 2012 at 10:29 AM, Magnus Hagander mag...@hagander.net
wrote:
Would also be good to have counter sin pg_stat_* for this, since you'd
On Fri, Jan 13, 2012 at 3:22 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jan 13, 2012 at 10:17 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, Jan 13, 2012 at 2:03 PM, Robert Haas robertmh...@gmail.com wrote:
Since the xmin horizon on the standby may precede the xmin horizon on
Robert Haas robertmh...@gmail.com writes:
So here's a 5-line patch that adds the number of heap fetches to the
EXPLAIN ANALYZE output. This might not be all the instrumentation
we'll ever want here, but I think we at least want this much.
Cosmetic gripes:
1. Please initialize the counter in
There's some more details about this at
http://wiki.postgresql.org/wiki/Running_a_CommitFest , which we don't
expect everyone to know because it isn't one of the popular pages to
read. I've sorted out the problem for this one already, just letting
whoever made that change know about the
Eric's review follows:
Compiling on Ubuntu 10.04 LTS AMD64 on a GoGrid virtual machine from
2012-01-12 git checkout.
Patch applied fine.
'make check' results in failures when this patch is put into place.
6 of 128 tests failed.
Here are the
On Fri, Jan 13, 2012 at 11:13 AM, Simon Riggs si...@2ndquadrant.com wrote:
I think it should be you that comes up with a fix, not for me to
respond to your concerns about how hard it is. Many things that don't
fully work are rejected for that reason.
Well, I disagree. The fact that
On Thu, Jan 12, 2012 at 7:26 PM, Greg Smith g...@2ndquadrant.com wrote:
On 1/11/12 9:25 AM, Andres Freund wrote:
The heavy pressure putting it directly in the writeback queue
leads to less efficient io because quite often it won't reorder sensibly
with
other io anymore and thelike. At least
On Fri, Jan 13, 2012 at 5:08 PM, Robert Haas robertmh...@gmail.com wrote:
Also, what happens if an all-visible bit gets set on the standby
through some other mechanism - e.g. restored from an FPI or
XLOG_HEAP_NEWPAGE? I'm not sure whether we ever do an FPI of the
visibility map page itself,
Kevin Grittner kevin.gritt...@wicourts.gov writes:
You were right. One of the isolation tests failed an assertion;
things pass with the attached change, setting the cmax
conditionally. Some comments updated. I hope this is helpful.
I worked over this patch a bit, mostly cosmetically;
On Fri, Jan 13, 2012 at 2:30 AM, Alexander Björnhagen
alex.bjornha...@gmail.com wrote:
At this point I feel that this new functionality might be a bit
overkill for postgres, maybe it's better to stay lean and mean rather
than add a controversial feature like this.
I don't understand why this
Jeff Janes jeff.ja...@gmail.com writes:
I don't understand why this is controversial. In the current code, if
you have a master and a single sync standby, and the master disappears
and you promote the standby, now the new master is running *without a
standby*.
If you configured it to use
On Fri, Jan 13, 2012 at 3:44 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, Jan 13, 2012 at 11:30 AM, Fujii Masao masao.fu...@gmail.com wrote:
I found that even read transaction waits for sync rep when it generates
WAL records even if XID is not assigned. For example, imagine the case
Jeff Janes jeff.ja...@gmail.com wrote:\
I don't understand why this is controversial.
I'm having a hard time seeing why this is considered a feature. It
seems to me what is being proposed is a mode with no higher
integrity guarantee than asynchronous replication, but latency
equivalent to
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
3. I modified heap_lock_tuple to also return a
HeapUpdateFailureData, principally on the grounds that its API
should be largely parallel to heap_update, but having done that I
can't help wondering whether
Tom Lane t...@sss.pgh.pa.us wrote:
I worked over this patch a bit, mostly cosmetically; updated
version attached.
Thanks!
However, we're not there yet. I have a couple of remaining
concerns:
1. I think the error message needs more thought. I believe it's
possible to trigger this
On 01/13/2012 12:31 AM, Hitoshi Harada wrote:
So my conclusion is it's better than nothing, but we could do better
job here.
From timeline perspective, it'd be ok to apply this patch and improve
more later in 9.3+.
I agree, let's look at the items other than the target list during
Hi folks.
Is there any restriction in create and start threads inside Postgres?
I'm trying to develop a multithread planner, and some times is raised a
exception of access memory.
I'm debugging the code to see if is a bug in the planner, but until now, I
still not found. I tried to use the
On Fri, Jan 13, 2012 at 3:14 PM, Frederico zepf...@gmail.com wrote:
Hi folks.
Is there any restriction in create and start threads inside Postgres?
I'm trying to develop a multithread planner, and some times is raised a
exception of access memory.
I'm debugging the code to see if is a bug
Tom Lane t...@sss.pgh.pa.us wrote:
[rearranging so results directly follow statements]
select * from test;
id | parent | data | nchildren
++--+---
2 | 1 | root child A | 1
4 | 2 | grandchild 1 | 0
3 | 1 | root
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
I'm not sure what to do about this. If we throw an error there,
there will be no way that the trigger can override the error
because it will never get to run. Possibly we could plow ahead
with the
Kevin Grittner kevin.gritt...@wicourts.gov writes:
I'm also fine with generating an error for such dirty tricks, and I
agree that if that's indeed possible we should make the message
general enough to cover that case. Nothing comes to mind at the
moment, but I'll think on it.
What do you
Tom Lane t...@sss.pgh.pa.us wrote:
What do you think of
ERROR: tuple to be updated was already modified by an operation
triggered by the UPDATE command
HINT: Consider using an AFTER trigger instead of a BEFORE trigger
to propagate changes to other rows.
(s/update/delete/ for the DELETE
Hackers,
It occurs to me that I would find it quite personally useful if the
vacuumdb utility was multiprocess capable.
For example, just today I needed to manually analyze a database with
over 500 tables, on a server with 24 cores. And I needed to know when
the analyze was done, because it
On Tue, Nov 29, 2011 at 10:10 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Nov 29, 2011 at 3:37 AM, Daniel Farina dan...@heroku.com wrote:
Hmm, just to prod this thread: has any fix for this been committed?
After Nikhil confirmed that this bug could cause pg_dump to not be
able to
Am 13.01.2012 22:50, schrieb Josh Berkus:
It occurs to me that I would find it quite personally useful if the
vacuumdb utility was multiprocess capable.
For example, just today I needed to manually analyze a database with
over 500 tables, on a server with 24 cores. And I needed to know when
On Friday, January 13, 2012 10:50:32 PM Josh Berkus wrote:
Hackers,
It occurs to me that I would find it quite personally useful if the
vacuumdb utility was multiprocess capable.
For example, just today I needed to manually analyze a database with
over 500 tables, on a server with 24
On 13-01-2012 18:50, Josh Berkus wrote:
It occurs to me that I would find it quite personally useful if the
vacuumdb utility was multiprocess capable.
It is in the mid of my TODO list. reindexdb is in the plans too.
--
Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/
On Fri, Jan 13, 2012 at 4:50 PM, Josh Berkus j...@agliodbs.com wrote:
It occurs to me that I would find it quite personally useful if the
vacuumdb utility was multiprocess capable.
For example, just today I needed to manually analyze a database with
over 500 tables, on a server with 24 cores.
On 1/13/12 2:12 PM, Euler Taveira de Oliveira wrote:
On 13-01-2012 18:50, Josh Berkus wrote:
It occurs to me that I would find it quite personally useful if the
vacuumdb utility was multiprocess capable.
It is in the mid of my TODO list. reindexdb is in the plans too.
I'm even happier to
Robert Haas robertmh...@gmail.com writes:
Maybe we should try to split the baby here and defer the question of
whether to expose any of the parse tree internals, and if so how much,
to a future release. It seems to me that we could design a fairly
useful set of functionality around
On Monday, December 19, 2011 07:37:46 PM Robert Haas wrote:
Maybe we should try to split the baby here and defer the question of
whether to expose any of the parse tree internals, and if so how much,
to a future release.
I personally think this is an error and those details should at least be
Robert Haas robertmh...@gmail.com writes:
Well, I disagree. The fact that all-visible info can't be trusted in
standby mode is a problem that has existed since Hot Standby was
committed, and I don't feel obliged to fix it just because I was
involved in developing a new feature that happens to
Kevin Grittner kevin.gritt...@wicourts.gov writes:
I'm having a hard time seeing why this is considered a feature. It
seems to me what is being proposed is a mode with no higher
integrity guarantee than asynchronous replication, but latency
equivalent to synchronous replication. I can see
Christopher Browne cbbro...@gmail.com writes:
Yes, don't try to use threads.
http://wiki.postgresql.org/wiki/Developer_FAQ#Why_don.27t_you_use_threads.2C_raw_devices.2C_async-I.2FO.2C_.3Cinsert_your_favorite_wizz-bang_feature_here.3E.3F
... threads are not currently used instead of multiple
Andres Freund and...@anarazel.de writes:
I personally think this is an error and those details should at least be
available on the c level (e.g. some pg_command_trigger_get_plan() function,
only available via C) to allow sensible playing around with that knowledge. I
don't really see making
On 13.1.2012 18:07, Josh Berkus wrote:
Eric's review follows:
Compiling on Ubuntu 10.04 LTS AMD64 on a GoGrid virtual machine from
2012-01-12 git checkout.
Patch applied fine.
'make check' results in failures when this patch is put into place.
6 of 128
On 01/12/2012 09:28 PM, Alex Hunsaker wrote:
Util.c/o not depending on plperl_helpers.h was also throwing me for a
loop so I fixed it and SPI.c... Thoughts?
Basically looks good, but I'm confused by this:
do language plperl $$ elog('NOTICE', ${^TAINT}); $$;
Why is NOTICE quoted here?
Tom Lane t...@sss.pgh.pa.us wrote:
In this particular example, I think it would work just as well to
do the reference-count updates in AFTER triggers, and maybe the
short answer is to tell people they have to do it like that
instead of in BEFORE triggers.
I think that is quite often the
On Fri, Jan 13, 2012 at 16:07, Andrew Dunstan and...@dunslane.net wrote:
On 01/12/2012 09:28 PM, Alex Hunsaker wrote:
Util.c/o not depending on plperl_helpers.h was also throwing me for a loop
so I fixed it and SPI.c... Thoughts?
Basically looks good, but I'm confused by this:
do
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
However, I wonder what use-case led you to file bug #6123 to begin
with.
[ details ]
Hopefully this answers your question. I went looking for details on
particular failures here, but didn't have luck
On Friday, January 13, 2012 11:53:32 PM Dimitri Fontaine wrote:
Andres Freund and...@anarazel.de writes:
I personally think this is an error and those details should at least be
available on the c level (e.g. some pg_command_trigger_get_plan()
function, only available via C) to allow
On Fri, Jan 13, 2012 at 12:08:05PM -0500, Robert Haas wrote:
On Fri, Jan 13, 2012 at 11:13 AM, Simon Riggs si...@2ndquadrant.com wrote:
Many WAL records have latestRemovedXid on them. We can use the same
idea with XLOG_HEAP2_VISIBLE records, so we add a field to send the
latest
One patch that fell off the truck during a turn in the November
CommitFest was Allow substitute allocators for PGresult. Re-reading
the whole thing again, it actually turned into a rather different
submission in the middle, and I know I didn't follow that shift
correctly then. I'm replying
On Fri, Jan 13, 2012 at 5:37 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com writes:
Well, I disagree. The fact that all-visible info can't be trusted in
standby mode is a problem that has existed since Hot Standby was
committed, and I don't feel obliged
On Fri, Jan 13, 2012 at 8:02 PM, Noah Misch n...@leadboat.com wrote:
Simon spoke to the FPI side of the question. For heap pages, the
XLOG_HEAP_NEWPAGE consumers are CLUSTER, VACUUM FULL and ALTER TABLE SET
TABLESPACE. For the last, we will have already logged any PD_ALL_VISIBLE bits
through
On Fri, Jan 13, 2012 at 12:18 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, Jan 13, 2012 at 5:08 PM, Robert Haas robertmh...@gmail.com wrote:
Also, what happens if an all-visible bit gets set on the standby
through some other mechanism - e.g. restored from an FPI or
XLOG_HEAP_NEWPAGE?
On Sat, Jan 14, 2012 at 12:42:02AM -0500, Robert Haas wrote:
On Fri, Jan 13, 2012 at 8:02 PM, Noah Misch n...@leadboat.com wrote:
Simon spoke to the FPI side of the question. ?For heap pages, the
XLOG_HEAP_NEWPAGE consumers are CLUSTER, VACUUM FULL and ALTER TABLE SET
TABLESPACE. ?For the
79 matches
Mail list logo
