I think it is desirable that this patch should be resubmitted for the next
CommitFest for further review and testing mentioned above. So I'd like to mark
this patch as Returned with Feedback. Is it OK?
Sounds like a good idea. Thanks for the review!
Ian Link
Etsuro Fujita
> This paragraph reads a bit strange to me:
>
> + A statistics session is the time period when statistics are gathered by
> statistics collector
> + without being reset. So a statistics session continues across normal
> shutdowns,
> + but whenever statistics are reset, like during a crash or upg
Haribabu kommi writes:
> To handle the above case instead of directly resetting the dead tuples as
> zero, how if the exact dead tuples
> are removed from the table stats. With this approach vacuum gets triggered
> frequently thus it reduces the bloat.
This does not seem like a very good idea a
2013/10/10 Ronan Dunklau :
> Le dimanche 6 octobre 2013 22:33:23 Kohei KaiGai a écrit :
>> 2013/9/10 Ronan Dunklau :
>> > For row-level triggers, it seems more complicated. From what I understand,
>> > OLD/NEW tuples are fetched from the heap using their ctid (except for
>> > BEFORE INSERT triggers
From: "Dimitri Fontaine"
"MauMau" writes:
Although this is not directly related to memory, could you set
max_prepared_transactions = max_connections at initdb time? People must
You really need to have a transaction manager around when issuing
prepared transaction as failing to commit/rollba
From: "Bruce Momjian"
On Thu, Oct 10, 2013 at 11:01:52PM +0900, MauMau wrote:
Although this is not directly related to memory, could you set
max_prepared_transactions = max_connections at initdb time? People
must feel frustrated when they can't run applications on a Java or
.NET application se
Haribabu kommi wrote:
> To handle the above case instead of directly resetting the dead
> tuples as zero, how if the exact dead tuples are removed from the
> table stats. With this approach vacuum gets triggered frequently
> thus it reduces the bloat.
> Patch for the same is attached in the mail.
Josh Berkus wrote:
> On 10/11/2013 01:11 PM, Bruce Momjian wrote:
>> In summary, I think we need to:
>>
>> * decide on new defaults for work_mem and maintenance_work_mem
>> * add an initdb flag to allow users/packagers to set shared_bufffers?
>> * add an autovacuum_work_mem setting?
>> * chang
On 10.10.2013 13:57, Heikki Linnakangas wrote:
> On 09.10.2013 02:04, Tomas Vondra wrote:
>> On 8.10.2013 21:59, Heikki Linnakangas wrote:
>>> On 08.10.2013 17:47, Alexander Korotkov wrote:
Hi, Tomas!
On Sun, Oct 6, 2013 at 3:58 AM, Tomas Vondra wrote:
> I've attempted to
Andres Freund wrote:
> On 2013-10-08 15:01:26 -0700, Kevin Grittner wrote:
>> Kevin Grittner wrote:
>>
>> > [ isolation test failed at snapshot-based isolation levels ]
>>
>> Fix pushed, that looks for the right results based on isolation level.
>
> Hm, given what we're trying to test here, would
Pavel Stehule escribió:
> It was my mistake - I was confused from timestamp with time zone type,
> what has zero related to date and time.
>
> fixed to immutable,
> fixed duplicate oid
Thanks. I wasn't sure about the error message returned when times are
outside range; how about this instead?
On 2013-10-04 11:04:53 -0400, Robert Haas wrote:
> On Fri, Oct 4, 2013 at 10:14 AM, Andres Freund wrote:
> > But that's not a new problem? It already exists and isn't really
> > excerbated by this.
> ...
> > I agree that we could use some more infrastructure around configuration,
> > but I fail to
On 10/11/13 3:57 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> Replace duplicate_oids with Perl implementation
>> It is more portable, more robust, and more readable.
>> From: Andrew Dunstan
>
> What about unused_oids?
We are not planning to put unused_oids in to the main build path, so
the
On 2013-10-01 10:12:13 -0400, Robert Haas wrote:
> On Tue, Oct 1, 2013 at 7:26 AM, Andres Freund wrote:
> > On 2013-10-01 06:20:20 -0400, Robert Haas wrote:
> >> On Mon, Sep 30, 2013 at 5:34 PM, Andres Freund
> >> wrote:
> >> >> What's wrong with #1?
> >> >
> >> > It seems confusing that a chang
On 2013-10-08 15:01:26 -0700, Kevin Grittner wrote:
> Kevin Grittner wrote:
>
> > [ isolation test failed at snapshot-based isolation levels ]
>
> Fix pushed, that looks for the right results based on isolation level.
Hm, given what we're trying to test here, wouldn't it be better to
explicitly
Andrew Dunstan writes:
> On 10/11/2013 03:57 AM, Tom Lane wrote:
>> What about unused_oids?
> Here's a quick version I whipped up along the same lines that you can
> play with.
> There's probably a good case for combining them.
Meh. To me, those two scripts are used in different scenarios, so
Bruce Momjian wrote:
> Thomas Fanghaenel wrote:
>> I was wondering about the proper semantics of CHAR comparisons in some corner
>> cases that involve control characters with values that are less than 0x20
>> (space).
What matters in general isn't where the characters fall when
comparing individ
On 10/11/2013 01:11 PM, Bruce Momjian wrote:
> In summary, I think we need to:
>
> * decide on new defaults for work_mem and maintenance_work_mem
> * add an initdb flag to allow users/packagers to set shared_bufffers?
> * add an autovacuum_work_mem setting?
> * change the default for temp_buff
On Thu, Oct 10, 2013 at 10:20:36PM -0700, Josh Berkus wrote:
> Robert,
>
> >> The counter-proposal to "auto-tuning" is just to raise the default for
> >> work_mem to 4MB or 8MB. Given that Bruce's current formula sets it at
> >> 6MB for a server with 8GB RAM, I don't really see the benefit of goi
On 10/11/2013 03:33 PM, Robert Haas wrote:
The build is continuing to fail on smew and anole. The reason it's
failing is because those machines are choosing max_connections = 10,
which is not enough to run the regression tests. I think this is
probably because of System V semaphore exhaustion.
On Sun, Sep 22, 2013 at 08:51:26PM -0400, Thomas Fanghaenel wrote:
> I was wondering about the proper semantics of CHAR comparisons in some corner
> cases that involve control characters with values that are less than 0x20
> (space).
>
> Consider the following testcase:
>
> ===
> create table t (
The build is continuing to fail on smew and anole. The reason it's
failing is because those machines are choosing max_connections = 10,
which is not enough to run the regression tests. I think this is
probably because of System V semaphore exhaustion. The machines are
not choosing a small value
Hello
2013/10/11 Alvaro Herrera
> Jeevan Chalke escribió:
> > On Wed, Sep 18, 2013 at 9:54 PM, Pavel Stehule >wrote:
> >
> > > thank you,
> > >
> > > I have no comments
> >
> > Assigned it to committer.
>
> Hm, these functions are marked as STABLE, right? Why aren't they
> immutable?
>
It wa
On Fri, Oct 11, 2013 at 5:43 AM, Robert Haas wrote:
* The visibility hacks that V4 is likely to have. The fact that
preserving the composable syntax may imply changes to
HeapTupleSatisfiesMVCC() so that rows locked but with no currently
visible version (under conventional rules
On Fri, Oct 11, 2013 at 10:02 AM, Andres Freund wrote:
> On 2013-10-11 08:43:43 -0400, Robert Haas wrote:
>> > I appreciate that it's odd that serializable transactions now have to
>> > worry about seeing something they shouldn't have seen (when they
>> > conclusively have to go lock a row version
On Thu, Oct 10, 2013 at 9:41 PM, Christopher Browne wrote:
> On Thu, Oct 10, 2013 at 12:28 PM, Bruce Momjian wrote:
>> How do we handle the Python dependency, or is this all to be done in
>> some other language? I certainly am not ready to take on that job.
>
> I should think it possible to reim
On 2013-10-11 09:22:50 +0530, Amit Kapila wrote:
> I think it will be difficult to prove by using any compression
> algorithm, that it compresses in most of the scenario's.
> In many cases it can so happen that the WAL will also not be reduced
> and tps can also come down if the data is non-compres
On 2013-10-11 08:43:43 -0400, Robert Haas wrote:
> > I appreciate that it's odd that serializable transactions now have to
> > worry about seeing something they shouldn't have seen (when they
> > conclusively have to go lock a row version not current to their
> > snapshot).
>
> Surely that's never
Hi,
On 2013-10-11 09:08:43 -0400, Robert Haas wrote:
> On Thu, Oct 10, 2013 at 7:11 PM, Andres Freund wrote:
> > On 2013-10-09 14:49:46 -0400, Robert Haas wrote:
> >> I spent some time looking at the sample plugin (patch 9/12). Here are
> >> some review comments:
> >>
> >> - I think that the dec
On Fri, 11 Oct 2013 10:00:51 +0530
Amit Kapila wrote:
> On Thu, Oct 10, 2013 at 10:06 PM, Gibheer
> wrote:
> > On Thu, 10 Oct 2013 09:55:24 +0530
> > Amit Kapila wrote:
> >
> >> On Thu, Oct 10, 2013 at 3:17 AM, Gibheer
> >> wrote:
> >> > On Mon, 7 Oct 2013 11:39:55 +0530
> >> > Amit Kapila wr
On 10/11/2013 03:57 AM, Tom Lane wrote:
Peter Eisentraut writes:
Replace duplicate_oids with Perl implementation
It is more portable, more robust, and more readable.
From: Andrew Dunstan
What about unused_oids?
Here's a quick version I whipped up along the same l
Arturas Mazeika writes:
> I would like to express my wonder to see the following line
> #define ExclusiveLock 7 /* blocks ROW
> SHARE/SELECT...FOR
> (line number 543) in /usr/include/postgresql/9.1/server/storage/lock.h
> file, because ExclusiveLock is a name of a
On 10/10/13 6:20 AM, Sameer Thakur wrote:
> Please find patch attached which adds documentation for session_start
> and introduced fields and corrects documentation for queryid to be
> query_id. session_start remains in the view as agreed.
Please fix the tabs in the SGML files.
--
Sent via pg
Jeevan Chalke escribió:
> On Wed, Sep 18, 2013 at 9:54 PM, Pavel Stehule wrote:
>
> > thank you,
> >
> > I have no comments
>
> Assigned it to committer.
Hm, these functions are marked as STABLE, right? Why aren't they
immutable?
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
Po
On Fri, Oct 11, 2013 at 9:27 AM, Michael Paquier
wrote:
> Finally I got the chance to put my hands on this code. Really sorry
> for the late replay.
Thanks for the review. I'll respond to this in more detail later, but
to make a long story short, I'm looking to apply
terminate-worker-v1.patch (p
On Fri, Oct 11, 2013 at 5:56 PM, Heikki Linnakangas wrote:
> 2. I didn't understand this change:
>
> @@ -422,24 +439,14 @@ g_cube_union(PG_FUNCTION_ARGS)
>> Datum
>> g_cube_compress(PG_FUNCTION_**ARGS)
>> {
>> - PG_RETURN_DATUM(PG_GETARG_**DATUM(0));
>> + GISTENTRY *entry = (GIST
Peter Eisentraut escribió:
> On Tue, 2013-09-17 at 15:13 +0500, Asif Naeem wrote:
> > I did put some time review the patch, please see my findings below
> > i.e.
>
> Updated patch for this.
Looks good to me.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24
On 09.10.2013 21:07, Robert Haas wrote:
On Tue, Sep 24, 2013 at 9:07 AM, Stas Kelvich wrote:
Hello
There is new version of patch. I have separated ordering operators to different
patch (https://commitfest.postgresql.org/action/patch_view?id=1243), fixed
formatting issues and implemented back
Hi pg_Hackers,
I would like to express my wonder to see the following line
#define ExclusiveLock 7 /* blocks ROW
SHARE/SELECT...FOR
(line number 543) in /usr/include/postgresql/9.1/server/storage/lock.h
file, because ExclusiveLock is a name of a class in libspatia
Hi,
Finally I got the chance to put my hands on this code. Really sorry
for the late replay.
On Fri, Sep 13, 2013 at 10:42 AM, Robert Haas wrote:
> Last week, I attempted to write some code to perform a trivial
> operation in parallel by launching background workers. Despite my
> earlier convic
On Fri, Oct 11, 2013 at 12:49 AM, Amit Kapila wrote:
> On Thu, Oct 10, 2013 at 6:45 PM, Andrew Dunstan wrote:
>>
>> On 10/09/2013 11:47 PM, Amit Kapila wrote:
>>>
>>>
>>> One of the advantage, I could see using "NULL For .." syntax is
>>> that already we have one syntax with which user can sp
On Thu, Oct 10, 2013 at 7:11 PM, Andres Freund wrote:
> Hi Robert,
>
> On 2013-10-09 14:49:46 -0400, Robert Haas wrote:
>> I spent some time looking at the sample plugin (patch 9/12). Here are
>> some review comments:
>>
>> - I think that the decoding plugin interface should work more like the
>>
vacuum is not happening on a heavily modified big table even if the dead tuples
are more than configured threshold.
This is because during at the end of vacuum, the number of dead tuples of the
table is reset as zero, because
of this reason the dead tuples which are occurred during the vacuum op
On Wed, Oct 9, 2013 at 9:30 PM, Peter Geoghegan wrote:
>>> * The syntax. I like the composability, and the way it's likely to
>>> become idiomatic to combine it with wCTEs. Others may not.
>>
>> I've actually lost track of what syntax you're proposing.
>
> I'm continuing to propose:
>
> INSERT...O
On Thu, Oct 10, 2013 at 10:35 PM, Andrew Gierth
wrote:
> The first alternative that springs to mind is:
>
> ERROR: Incorrect number of arguments for hypothetical set function
> DETAIL: Number of hypothetical arguments (3) must equal number of ordered
> columns (2)
I'd suggest trying to collapse
gettimeofday(&start, NULL);
for (i = 0; i < VALUES; i++) {
state = XXH32_init(result);
XXH32_update(state, &i, 4);
XXH32_digest(state);
}
gettimeofday(&end, NULL);
This code is using the "update" variant, which is only useful when dealing
with very large amount of
Le jeudi 10 octobre 2013 21:37:24 Peter Eisentraut a écrit :
> On Mon, 2013-10-07 at 22:00 -0400, Andrew Dunstan wrote:
> > The code has been sitting in HEAD for several months, and I
> > committed on the back branches because it was wanted.
>
> New features normally go through a full development
Peter Eisentraut writes:
> Replace duplicate_oids with Perl implementation
> It is more portable, more robust, and more readable.
> From: Andrew Dunstan
What about unused_oids?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On 10 October 2013 23:06 Fujii Masao wrote:
>On Wed, Oct 9, 2013 at 1:35 PM, Haribabu kommi
>wrote:
>> Thread-1
>>Threads-2
>> Head code FPW compressHead
>>
49 matches
Mail list logo
