On 19.11.2012 02:17, Fujii Masao wrote:
This bug is derived from the commit d5497b95f3ca2fc50c6eef46d3394ab6e6855956.
This commit changed ExecuteRecoveryCommand() so that it calculates the
the last valid
retart file by using GetOldestRestartPoint(), even though
GetOldestRestartPoint() only
works
Hello
2012/11/16 Karl O. Pinc k...@meme.com:
Hi Pavel,
On 11/16/2012 12:21:11 AM, Pavel Stehule wrote:
2012/11/16 Karl O. Pinc k...@meme.com:
As long as I'm talking crazy talk, why not
abandon psql as a shell language and instead make a
pl/pgsql interpreter with readlne() in front
of
Marko Tiikkaja pgm...@joh.to writes:
What happens if you have a table foo and another table FoO?
They would go to the same file. If you think there are technical issues
behind that decision (e.g. the dump would not restore), I would like to hear
an example case.
I didn't try the patch
Josh Berkus wrote:
It would be nice for the user to have some way to know that a matview is
empty due to never being LOADed or recently being TRUNCATEd. However, I
don't think that relisvalid flag -- and preventing scanning the relation
-- is a good solution. What I'd rather have instead is a
Hi Michael,
On 2012-11-19 16:28:55 +0900, Michael Paquier wrote:
I have been able to fetch your code (thanks Andrea!) and some it. For the
time being I am spending some time reading the code and understanding the
whole set of features you are trying to implement inside core, even if I
got
On Mon, Nov 19, 2012 at 10:05 AM, Alexander Korotkov
aekorot...@gmail.comwrote:
On Thu, Nov 15, 2012 at 11:39 PM, Fujii Masao masao.fu...@gmail.comwrote:
Note that we cannot do a partial-match if KEEPONLYALNUM is disabled,
i.e., if query key contains multibyte characters. In this case, byte
Hi,
I gone through the discussion for this patch and here is my review:
The main aim of this patch is to reduce the number of log lines. It is also
suggested to use an options to provide the interval but few of us are not
much agree on it. So final discussion ended at keeping 5 sec interval
On 2012-11-14 13:27:26 -0300, Alvaro Herrera wrote:
Alvaro Herrera wrote:
* In heap_lock_tuple's XMAX_IS_MULTI case
[snip]
why is it membermode mode and not membermode = mode?
Uh, that's a bug. Fixed. As noticed in the comment above that snippet,
there was a deadlock
First, you can add me to the list of people saying 'wow', I'm impressed.
The approach I am taking to reviewing this to try and answer the
following question
1) How might a future version of slony be able to use logical
replication as described by your patch and design documents
and what
Hi Steve!
On 2012-11-17 22:50:35 -0500, Steve Singer wrote:
First, you can add me to the list of people saying 'wow', I'm impressed.
Thanks!
The approach I am taking to reviewing this to try and answer the following
question
1) How might a future version of slony be able to use logical
On 2012-11-14 13:27:26 -0300, Alvaro Herrera wrote:
Alvaro Herrera wrote:
* In heap_lock_tuple's XMAX_IS_MULTI case
[snip]
why is it membermode mode and not membermode = mode?
Uh, that's a bug. Fixed. As noticed in the comment above that snippet,
there was a deadlock
Hello all
I tested this patch and I can confirm, so this patch can increase
speed about 16-22% (depends on IO waits, load type).
I tested real query (anonymyzed)
SELECT SUM(COALESCE((a * b * c * (d + ((1 -(d)) * (1 -(e),0)) m1 FROM tab;
-- patched
4493 26.5591 postgres
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
pg_dump | pg_restore
pg_export | psql
While I agree that this idea - when implemented - would be nicer in
practically every way, I'm not sure I want to volunteer to do all the
necessary work.
What I think needs to happen now is a
Amit Kapila amit.kap...@huawei.com writes:
We have discussion about below 3 different syntaxes for this command
1. ALTER SYSTEM
2. SET PERSISENT
3. pg_change_conf()
I think to conclude, we need to evaluate which syntax has more advantages.
Comparison for above syntax
I think ALTER
On 11/17/2012 12:16:06 AM, Peter Eisentraut wrote:
I'm unsure whether splitting this out into a list (or table) is an
improvement. Other opinions?
This page is written as a narrative explanation of the RAISE feature,
but there is probably a desire to also have it serve as a reference
page
On Monday, November 19, 2012 7:53 PM Dimitri Fontaine wrote:
Amit Kapila amit.kap...@huawei.com writes:
We have discussion about below 3 different syntaxes for this command
1. ALTER SYSTEM
2. SET PERSISENT
3. pg_change_conf()
I think to conclude, we need to evaluate which syntax has
Hi,
Thanks for working on that cleanup job!
Kohei KaiGai kai...@kaigai.gr.jp writes:
The attached patch is the revised version of ALTER RENAME TO
consolidation. According to the previous suggestion, it uses
a common logic to check object-naming duplication at
check_duplicate_objectname().
I
Amit Kapila escribió:
The only point I can see against SET PERSISTENT is that other variants of
SET command can be used in
transaction blocks means for them ROLLBACK TO SAVEPOINT functionality works,
but for SET PERSISTENT,
it can't be done.
So to handle that might be we need to mention
On 11/19/2012 09:07 AM, Dimitri Fontaine wrote:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
pg_dump | pg_restore
pg_export | psql
While I agree that this idea - when implemented - would be nicer in
practically every way, I'm not sure I want to volunteer to do all the
necessary
On 11/19/2012 02:30:49 AM, Pavel Stehule wrote:
Hello
2012/11/16 Karl O. Pinc k...@meme.com:
Hi Pavel,
On 11/16/2012 12:21:11 AM, Pavel Stehule wrote:
2012/11/16 Karl O. Pinc k...@meme.com:
As long as I'm talking crazy talk, why not
abandon psql as a shell language and instead
Hi Dimitri,
Thanks for your checks.
2012/11/19 Dimitri Fontaine dimi...@2ndquadrant.fr:
Kohei KaiGai kai...@kaigai.gr.jp writes:
The attached patch is the revised version of ALTER RENAME TO
consolidation. According to the previous suggestion, it uses
a common logic to check object-naming
2012/11/19 Karl O. Pinc k...@meme.com:
On 11/19/2012 02:30:49 AM, Pavel Stehule wrote:
Hello
2012/11/16 Karl O. Pinc k...@meme.com:
Hi Pavel,
On 11/16/2012 12:21:11 AM, Pavel Stehule wrote:
2012/11/16 Karl O. Pinc k...@meme.com:
As long as I'm talking crazy talk, why not
Kohei KaiGai wrote:
I am not so happy with GetForeignRelInfo:
- The name seems ill-chosen from the FDW API side.
I guess that you chose the name because the function
is called from get_relation_info, but I think the name
should be more descriptive for the FDW API.
Something like
On Monday, November 19, 2012 6:05 AM Jeff Janes wrote:
On Mon, Oct 22, 2012 at 10:51 AM, Amit kapila amit.kap...@huawei.com wrote:
Today again I have again collected the data for configuration Shared_buffers
= 7G along with vmstat.
The data and vmstat information (bi) are attached with this
On Monday, November 19, 2012 8:36 PM Alvaro Herrera wrote:
Amit Kapila escribió:
The only point I can see against SET PERSISTENT is that other variants
of
SET command can be used in
transaction blocks means for them ROLLBACK TO SAVEPOINT functionality
works,
but for SET PERSISTENT,
Kohei KaiGai kai...@kaigai.gr.jp writes:
OK, Are you suggesting to add a generic comments such as Generic
function to change the name of a given object, for simple cases ...,
not a list of OBJECT_* at the head of this function, aren't you?
Just something like
* Most simple objects are
Xi Wang xi.w...@gmail.com writes:
On 11/18/12 6:47 PM, Tom Lane wrote:
I was against this style of coding before, and I still am.
For one thing, it's just about certain to introduce conflicts
against system headers.
I totally agree.
I would be happy to rewrite the integer overflow checks
Karl O. Pinc k...@meme.com writes:
Yes. I'm wrong. For some reason I thought you could use DO to make
an anonymous code block that would act as a SETOF function,
allowing RETURN NEXT expr (et-al) to be used in the
plpgsql code, allowing DO to return table results.
(Or, perhaps, instead, be
On Thu, Nov 15, 2012 at 3:09 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com writes:
Please find attached to this email an RFC patch implementing the basics
of the pg_dump --extension-script option. After much discussion around
the concept of an inline
On 11/19/12 11:04 AM, Tom Lane wrote:
I thought about this some more and realized that we can handle it
by realizing that division by -1 is the same as negation, and so
we can copy the method used in int4um. So the code would look like
if (arg2 == -1)
{
result =
2012/11/19 Dimitri Fontaine dimi...@2ndquadrant.fr:
Kohei KaiGai kai...@kaigai.gr.jp writes:
OK, Are you suggesting to add a generic comments such as Generic
function to change the name of a given object, for simple cases ...,
not a list of OBJECT_* at the head of this function, aren't you?
On Thu, Nov 15, 2012 at 2:44 PM, Jeff Davis pg...@j-davis.com wrote:
The issue about external utilities is a bigger problem than I realized
at first. Originally, I thought that it was just a matter of code to
associate the checksum with the data.
However, an external utility will never see a
Simon Riggs wrote:
This seems very similar to the REPLACE command we discussed
earlier, except this is restricted to Mat Views.
I don't remember that discussion -- do you have a reference?
If we're going to have this, I would prefer a whole command.
e.g. REPLACE matviewname REFRESH
Xi Wang xi.w...@gmail.com writes:
The reality is that C compilers are not friendly to postcondition
checking; they consider signed integer overflow as undefined behavior,
so they do whatever they want to do. Even workaround options like
-fwrapv are often broken, not to mention that they may
Robert Haas robertmh...@gmail.com writes:
That approach seems likely to break things for the hoped-for parallel
pg_dump feature, though I'm not sure exactly in what way.
Will the parallel dump solve the dependencies and extension membership
properties in parallel too?
Beyond that, I think
2012/11/19 Albe Laurenz laurenz.a...@wien.gv.at:
Kohei KaiGai wrote:
I am not so happy with GetForeignRelInfo:
- The name seems ill-chosen from the FDW API side.
I guess that you chose the name because the function
is called from get_relation_info, but I think the name
should be more
Albe Laurenz wrote:
Kevin Grittner wrote:
My take was more that MVs would often be refreshed by crontab, and
that you would want to keep subsequent steps from running and
generating potentially plausible but completely inaccurate results
if the LMV failed.
If one of these subsequent steps
On 2012-11-19 11:04:31 -0500, Tom Lane wrote:
Xi Wang xi.w...@gmail.com writes:
Since INTn_MIN and INTn_MAX are standard macros from the C library,
can we assume that every C compiler should provide them in stdint.h?
Not every C compiler provides stdint.h, unfortunately --- otherwise
I'd
On Mon, 2012-11-19 at 11:48 -0500, Robert Haas wrote:
I agree that the hazards are not equivalent, but I'm not sure I agree
that an external utility will never see a torn page while the system
is on-line. We have a bunch of code that essentially forces
full_page_writes=on during a base backup
Hi all!
There will be planned hardware/software maintenance this tomorrow
Tuesday (20th November 2012) from starting at 16:30 CET - affecting some
redundant services (ftp and www mirrors) as well as the following public
hosts:
* yridian.postgresql.org (www.postgresql.eu)
*
On 10.10.2012 17:54, Thom Brown wrote:
Hmm... I get something different. When I promote standby B, standby
C's log shows:
LOG: walreceiver ended streaming and awaits new instructions
LOG: re-handshaking at position 0/400 on tli 1
LOG: fetching timeline history file for timeline 2
On 2012-11-19 09:22:45 -0800, Jeff Davis wrote:
On Mon, 2012-11-19 at 11:48 -0500, Robert Haas wrote:
I agree that the hazards are not equivalent, but I'm not sure I agree
that an external utility will never see a torn page while the system
is on-line. We have a bunch of code that
On Thu, Nov 15, 2012 at 2:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Yeah. If we're going to do this at all, and I'm not convinced it's
worth the work, I think it's definitely good to support a variant
where we specify exactly the things that will be
Kevin Grittner kgri...@mail.com writes:
Simon Riggs wrote:
Either way, I don't much like overloading the use of LOAD, which
already has a very different meaning.
Well, it's hard to avoid creating new keywords without overloading
the meaning of exsiting ones.
FWIW, I'd much rather see us
Robert Haas robertmh...@gmail.com writes:
On Thu, Nov 15, 2012 at 2:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The biggest problem this patch has had from the very beginning is
overdesign, and this is more of the same. Let's please just define the
feature as popen, not fopen, the given string
Kevin,
I'm looking at whether there is some reasonable way to detect invalid
data as well as capture age of data. Every solution I've thought of
so far has at least one hard-to-solve race condition, but I have
hopes that I can either solve that for one of the ideas, or come up
with an idea
On 11/19/12 9:57 AM, Josh Berkus wrote:
Kevin,
I'm looking at whether there is some reasonable way to detect invalid
data as well as capture age of data. Every solution I've thought of
so far has at least one hard-to-solve race condition, but I have
hopes that I can either solve that for
On Sun, Nov 18, 2012 at 10:43 PM, Jeff Davis pg...@j-davis.com wrote:
On Sun, 2012-11-18 at 15:19 +0100, Andres Freund wrote:
On Sunday, November 18, 2012 03:07:01 AM Jeff Davis wrote:
Process A (process that clears a VM bit for a data page):
1. Acquires exclusive lock on data buffer
It's quite common to load a lot of data, and then do some reads for a
while (setting hint bits and flushing them to disk), and then do a
VACUUM a while later, setting PD_ALL_VISIBLE and writing all of the
pages again. Also, if I remember correctly, Robert went to significant
effort when
On Mon, 2012-11-19 at 18:30 +0100, Andres Freund wrote:
Yes, definitely.
OK. I suppose that makes sense for large writes.
If that is not true, then I'm concerned about replicating corruption, or
backing up corrupt blocks over good ones. How do we prevent that? It
seems like a pretty major
On 19.11.2012 11:59, Jeevan Chalke wrote:
Hi,
I gone through the discussion for this patch and here is my review:
The main aim of this patch is to reduce the number of log lines. It is
also suggested to use an options to provide the interval but few of us
are not much agree on it. So
On Tue, Nov 20, 2012 at 12:08 AM, Jeff Davis pg...@j-davis.com wrote:
On Mon, 2012-11-19 at 23:50 +0530, Atri Sharma wrote:
Sorry If I am being a bit naive, but shouldnt a simple mutex work in
the case when a process wants to change the VM bit in cache?
Mutex would be cheaper than
On Mon, 2012-11-19 at 23:50 +0530, Atri Sharma wrote:
Sorry If I am being a bit naive, but shouldnt a simple mutex work in
the case when a process wants to change the VM bit in cache?
Mutex would be cheaper than locks.
I thought mutexes are locks?
The point is to avoid taking new locks
On Tue, 2012-11-20 at 00:13 +0530, Atri Sharma wrote:
My mistake...I thought we were more concerned about the cost of
locking.
I agree, locking many data pages simultaneously could be hazardous.
This requires more thought.Maybe removing PD_ALL_VISIBLE isnt such a
great idea after all...
On 2012-11-19 10:46:37 -0800, Jeff Davis wrote:
On Tue, 2012-11-20 at 00:13 +0530, Atri Sharma wrote:
My mistake...I thought we were more concerned about the cost of
locking.
I agree, locking many data pages simultaneously could be hazardous.
This requires more thought.Maybe
Jeff Davis pg...@j-davis.com writes:
As I said elsewhere in the thread, I'm not planning to introduce any
additional locking. There is already precedent in IndexOnlyNext.
Of course, that just begs the question of whether the code in
IndexOnlyNext is correct. And after looking at it, it seems
On Wed, Nov 14, 2012 at 3:55 PM, Bruce Momjian br...@momjian.us wrote:
On Mon, Nov 12, 2012 at 10:29:39AM -0800, Jeff Janes wrote:
Is turning off synchronous_commit enough? What about turning off fsync?
I did some testing with the attached patch on a magnetic disk with no
BBU that turns off
I've added this to the open commitfest. I think that a formal review
is probably required here.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Kohei KaiGai escribió:
2012/10/22 Alvaro Herrera alvhe...@2ndquadrant.com:
Here's an updated version of this patch, which also works in
an EXEC_BACKEND environment. (I haven't tested this at all on Windows,
but I don't see anything that would create a portability problem there.)
I also
Tom Lane wrote:
Kevin Grittner kgri...@mail.com writes:
Josh Berkus wrote:
What use would a temporary matview be?
It would be essentially like a temporary table, with all the same
persistence options. I'm not really sure how often it will be more
useful than a temporary table before we
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Kohei KaiGai escribió:
StartOneBackgroundWorker always scan the BackgroundWorkerList from
the head. Isn't it available to save the current position at static variable?
If someone tries to manage thousand of bgworkers, it makes a busy loop. :(
On Mon, 2012-11-19 at 10:35 -0800, Jeff Davis wrote:
Yes, the blocks written *after* the checkpoint might have a bad checksum
that will be fixed during recovery. But the blocks written *before* the
checkpoint should have a valid checksum, but if they don't, then
recovery doesn't know about
Hi!
New version of patch is attached. Changes are following:
1) Right way to convert from pg_wchar to multibyte.
2) Optimization of producing CFNA-like graph on trigrams (produce smaller,
but equivalent, graphs in less time).
3) Comments and refactoring.
--
With best regards,
Alexander
Kohei KaiGai wrote:
Sorry, I missed the attached version.
Please use this revision.
All those direct uses of object_access_hook make me think that the
InvokeObjectAccessHook() macro we have is insufficient. Maybe we could
have InvokeObjectAccessHookArg1() so that instead of
+ if
On Mon, November 19, 2012 22:58, Alexander Korotkov wrote:
New version of patch is attached.
Hi Alexander,
I get some compile-errors:
(Centos 6.3, Linux 2.6.32-279.14.1.el6.x86_64 GNU/Linux, gcc (GCC) 4.7.2)
make contrib
trgm_regexp.c:73:2: error: unknown type name TrgmStateKey
make[1]:
On 19.11.2012 22:58, Alexander Korotkov wrote:
Hi!
New version of patch is attached. Changes are following:
1) Right way to convert from pg_wchar to multibyte.
2) Optimization of producing CFNA-like graph on trigrams (produce
smaller, but equivalent, graphs in less time).
3) Comments and
Some quick comments.
On Tue, Nov 20, 2012 at 3:02 AM, Tomas Vondra t...@fuzzy.cz wrote:
6) It does not compile - I do get a bunch of errors like this
Fixed.
7) Once fixed, it seems to work
CREATE EXTENSION pg_trgm ;
CREATE TABLE TEST (val TEXT);
INSERT INTO test
SELECT
On Tue, 2012-11-06 at 10:57 -0500, Robert Haas wrote:
But, with the attached patch:
rhaas=# create function xyz(smallint) returns smallint as $$select
$1$$ language sql;
CREATE FUNCTION
rhaas=# select xyz(5);
xyz
-
5
(1 row)
rhaas=# create table abc (a int);
CREATE TABLE
On Mon, Nov 19, 2012 at 5:50 PM, Andres Freund and...@2ndquadrant.comwrote:
Hi Michael,
On 2012-11-19 16:28:55 +0900, Michael Paquier wrote:
I have been able to fetch your code (thanks Andrea!) and some it. For the
time being I am spending some time reading the code and understanding the
On 12-11-18 11:07 AM, Andres Freund wrote:
Hi Steve!
I think we should provide some glue code to do this, otherwise people
will start replicating all the bugs I hacked into this... More
seriously: I think we should have support code here, no user will want
to learn the intracacies of feedback
Since ereport() can now communicate to the compiler whether it returns
or not, a fair amount of keep compiler quiet code is dead. Since the
method that ereport() uses is not dependent on any compiler-specific
attributes, I think this code can just be removed. I propose the
attached patch.
diff
Peter Eisentraut pete...@gmx.net writes:
Since ereport() can now communicate to the compiler whether it returns
or not, a fair amount of keep compiler quiet code is dead. Since the
method that ereport() uses is not dependent on any compiler-specific
attributes, I think this code can just be
Hi,
On Tue, Nov 20, 2012 at 12:08 AM, Tomas Vondra t...@fuzzy.cz wrote:
On 19.11.2012 11:59, Jeevan Chalke wrote:
Hi,
I gone through the discussion for this patch and here is my review:
The main aim of this patch is to reduce the number of log lines. It is
also suggested to use an
hello
I looked on issue with consuming memory by query
HashSetOp Except (cost=0.00..297100.69 rows=594044 width=30)
- Append (cost=0.00..234950.32 rows=8286716 width=30)
- Subquery Scan on *SELECT* 1 (cost=0.00..168074.62
rows=5940431 width=29)
- Seq Scan on ac
Hello,
Agreed. Attached patch introduces the pgstatginindex() which now reports
GIN version number, number of pages in the pending list and number of
tuples in the pending list, as information about a GIN index.
It seems fine on the whole, and I have some suggestions.
1. This patch applies
75 matches
Mail list logo
