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 :
> Hi Pavel,
>
> On 11/16/2012 12:21:11 AM, Pavel Stehule wrote:
>> 2012/11/16 Karl O. Pinc :
>
>> > 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 it? So
Marko Tiikkaja 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 itself yet
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 instea
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
wrote:
> On Thu, Nov 15, 2012 at 11:39 PM, Fujii Masao wrote:
>
>> Note that we cannot do a partial-match if KEEPONLYALNUM is disabled,
>> i.e., if query key contains multibyte characters. In this case, byte
>> length of
>> the trigram string mi
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
betwe
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,
> >
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 woul
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,
> >
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 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 commiter's
Amit Kapila 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 SYSTEM should be wha
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
>
On Monday, November 19, 2012 7:53 PM Dimitri Fontaine wrote:
> Amit Kapila 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
>
Hi,
Thanks for working on that cleanup job!
Kohei KaiGai 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 think you need
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 menti
On 11/19/2012 09:07 AM, Dimitri Fontaine wrote:
Dimitri Fontaine 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 need
On 11/19/2012 02:30:49 AM, Pavel Stehule wrote:
> Hello
>
> 2012/11/16 Karl O. Pinc :
> > Hi Pavel,
> >
> > On 11/16/2012 12:21:11 AM, Pavel Stehule wrote:
> >> 2012/11/16 Karl O. Pinc :
> >
> >> > As long as I'm talking crazy talk, why not
> >> > abandon psql as a shell language and instead make
Hi Dimitri,
Thanks for your checks.
2012/11/19 Dimitri Fontaine :
> Kohei KaiGai 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_obje
2012/11/19 Karl O. Pinc :
> On 11/19/2012 02:30:49 AM, Pavel Stehule wrote:
>> Hello
>>
>> 2012/11/16 Karl O. Pinc :
>> > Hi Pavel,
>> >
>> > On 11/16/2012 12:21:11 AM, Pavel Stehule wrote:
>> >> 2012/11/16 Karl O. Pinc :
>> >
>> >> > As long as I'm talking crazy talk, why not
>> >> > abandon psql
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.
>> Somethin
On Monday, November 19, 2012 6:05 AM Jeff Janes wrote:
On Mon, Oct 22, 2012 at 10:51 AM, Amit kapila 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 mail. It is
>>
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 PER
Kohei KaiGai 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 covered by a generi
Xi Wang 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 without
>
"Karl O. Pinc" 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 used in
On Thu, Nov 15, 2012 at 3:09 PM, Dimitri Fontaine
wrote:
> Robert Haas 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 extension, we decided last year that a
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)
> {
> res
2012/11/19 Dimitri Fontaine :
> Kohei KaiGai 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
>
> * Mo
On Thu, Nov 15, 2012 at 2:44 PM, Jeff Davis 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 torn page whi
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 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 not even have
>
Robert Haas 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 much of the appeal of
2012/11/19 Albe Laurenz :
> 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 descripti
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 subse
On 2012-11-19 11:04:31 -0500, Tom Lane wrote:
> Xi Wang 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 not be so r
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 bac
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)
* antos.postgresql.org
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
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 es
On Thu, Nov 15, 2012 at 2:35 PM, Tom Lane wrote:
> Robert Haas 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 passed to exec().
>> There's just
"Kevin Grittner" 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 overload LO
Robert Haas writes:
> On Thu, Nov 15, 2012 at 2:35 PM, Tom Lane 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" and have done.
> ... If we giv
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 id
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 th
On Sun, Nov 18, 2012 at 10:43 PM, Jeff Davis 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
> > > 2.
>
> 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
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. S
On Tue, Nov 20, 2012 at 12:08 AM, Jeff Davis 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 locks.
> >
>
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 lock
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 a
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 though
Jeff Davis 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 pretty
broken, or
On Wed, Nov 14, 2012 at 3:55 PM, Bruce Momjian 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 fsync;
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 changes
Kohei KaiGai escribió:
> 2012/10/22 Alvaro Herrera :
> > 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 tried to check
Tom Lane wrote:
> "Kevin Grittner" 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 have
Alvaro Herrera 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. :(
> Seems messy; we wo
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 Korotk
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 (object_ac
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
Some quick comments.
On Tue, Nov 20, 2012 at 3:02 AM, Tomas Vondra 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 md5(i::text) FROM
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);
> CREA
On Mon, Nov 19, 2012 at 5:50 PM, Andres Freund wrote:
> 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 o
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 m
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 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 removed. I
Hi,
On Tue, Nov 20, 2012 at 12:08 AM, Tomas Vondra 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 o
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 applie
75 matches
Mail list logo
