On Thu, Feb 3, 2011 at 18:29, Alex Hunsaker wrote:
> On Mon, Jan 31, 2011 at 01:34, Alexey Klyukin wrote:
>> I've looked at the patch and added a test for arrays exceeding or equal
>> maximum dimensions to check, whether the recursive function won't bring
>> surprises there. I've also added che
Tomas Vondra wrote:
Because when I create a database, the field is
NULL - that's true. But once I connect to the database, the stats are
updated and the field is set (thanks to the logic in pgstat.c).
OK--so it does what I was hoping for, I just didn't test it the right
way. Let's call tha
On Sat, Feb 5, 2011 at 7:44 PM, Noah Misch wrote:
>> But this is a little unsatisfying, for two reasons. First, the error
>> message will be subtly wrong: we can make it complain about a table or
>> a type, but not a foreign table. At a quick look, it likes the right
>> fix might be to replace t
nclude btree_gist in
core, to make range types more useful with exclusion constraints
out-of-the-box. This should be left for later, I'm just including this
for the archives so it doesn't get lost.
Regards,
Jeff Davis
rangetypes-20110205.patch.gz
Description: GNU Zip compres
On Sun, Feb 6, 2011 at 01:54, Robert Haas wrote:
> On Thu, Feb 3, 2011 at 7:56 AM, Magnus Hagander wrote:
>> Include more status information in walsender results
>>
>> Add the current xlog insert location to the response of
>> IDENTIFY_SYSTEM, and adds result sets containing start
>> and stop loc
"Kevin Grittner" wrote:
> So now that I'm sure we actually do need code there, I'll add it.
Hmmm... First cut at this here:
http://git.postgresql.org/gitweb?p=users/kgrittn/postgres.git;a=commitdiff;h=3ccedeb451ee74ee78ef70735782f3550b621eeb
It passes all the usual regression tests, the n
On Thu, Feb 3, 2011 at 7:56 AM, Magnus Hagander wrote:
> Include more status information in walsender results
>
> Add the current xlog insert location to the response of
> IDENTIFY_SYSTEM, and adds result sets containing start
> and stop location of backups to BASE_BACKUP responses.
Does this hav
On Sat, Feb 05, 2011 at 10:03:59AM -0500, Robert Haas wrote:
> Looking at this still more, it appears that independent of any change
> this patch may wish to make, there's a live bug here related to the
> foreign table patch I committed back in December. Creating a foreign
> table creates an epony
On Sat, Feb 5, 2011 at 5:04 PM, Cédric Villemain
wrote:
> Robert, I am unsure with the hint_bit_write_allowance counter. It
> looks a bit fragile because
> nothing prevent hint_bit_write_allowance counter to increase a lot,
> so that is not 100 but X*100 next hint bit will be written. Isn't it ?
On Sat, Feb 5, 2011 at 5:41 PM, Tom Lane wrote:
> Currently, the extensions patch considers that foreign data wrappers,
> foreign servers, and user mapping objects can all be parts of extensions.
> This is slightly problematic for pg_dump, where somebody decided to take
> a shortcut and not implem
On Mon, Jan 17, 2011 at 06:33:08PM -0600, Kevin Grittner wrote:
> Itagaki Takahiro wrote:
> > Shigeru HANADA wrote:
>
> >> Attached patch would avoid this leak by adding per-copy context to
> >> CopyState. This would be overkill, and ResetCopyFrom() might be
> >> reasonable though.
> >
> > Good
Currently, the extensions patch considers that foreign data wrappers,
foreign servers, and user mapping objects can all be parts of extensions.
This is slightly problematic for pg_dump, where somebody decided to take
a shortcut and not implement user mappings using the full DumpableObject
infrastru
2011/2/5 Bruce Momjian :
> Robert Haas wrote:
>> On Sat, Feb 5, 2011 at 10:37 AM, C?dric Villemain
>> wrote:
>> > Please update the commitfest with the accurate patch, there is only
>> > the old immature v1 of the patch in it.
>> > I was about reviewing it...
>> >
>> > https://commitfest.postgresq
Hi,
I do performance tests against orignal JDBC driver and my version in binary
and in text mode. I saw strange results when I was reading varchar values.
Here is some output from simple benchmark
Plain strings speed Execution: 8316582, local: 2116608, all:
10433190
Binary str
On Sat, Feb 5, 2011 at 4:31 PM, Bruce Momjian wrote:
> Uh, in this C comment:
>
> + * or not we want to take the time to write it. We allow up to 5% of
> + * otherwise-not-dirty pages to be written due to hint bit changes,
>
> 5% of what? 5% of all buffers? 5% of all hint-bit-dirt
On Sat, Feb 5, 2011 at 4:19 PM, Cédric Villemain
wrote:
> just reading the patch...
> I understand the idea of the 5% flush.
> *maybe* it make sense to use effective_io_concurrency GUC here to
> improve the ratio, but it might be perceived as a bad usage ..
> currently effective_io_concurrency is
Robert Haas wrote:
> On Sat, Feb 5, 2011 at 10:37 AM, C?dric Villemain
> wrote:
> > Please update the commitfest with the accurate patch, there is only
> > the old immature v1 of the patch in it.
> > I was about reviewing it...
> >
> > https://commitfest.postgresql.org/action/patch_view?id=500
>
2011/2/5 Robert Haas :
> On Sat, Feb 5, 2011 at 3:07 PM, Cédric Villemain
> wrote:
>>> So I think this probably needs more testing
>>> before we decide whether or not it's a good idea.
>>
>> I *may* have an opportunity to test that in a real world application
>> where this hint bit was an issue.
>
"Kevin Grittner" wrote:
> So now that I'm sure we actually do need code there, I'll add it.
In working on this I noticed the apparent need to move two calls to
PredicateLockTuple a little bit to keep them inside the buffer lock.
Without at least a share lock on the buffer, it seems that here
2011/2/5 Robert Haas :
> On Sat, Feb 5, 2011 at 3:20 PM, Cédric Villemain
> wrote:
>>> In the case where a table is skipped for this reason, we log a message
>>> at log level LOG. The version of the patch I posted does that
>>> unconditionally, but my intention was to change it before commit so
>
On Sat, Feb 5, 2011 at 3:20 PM, Cédric Villemain
wrote:
>> In the case where a table is skipped for this reason, we log a message
>> at log level LOG. The version of the patch I posted does that
>> unconditionally, but my intention was to change it before commit so
>> that it only logs the messag
2011/2/5 Robert Haas :
> On Sat, Feb 5, 2011 at 12:54 PM, Cédric Villemain
> wrote:
>> what do you implement exactly ?
>> * The original request from Josh to get LOG when autovac can not run
>> because of locks
>> * VACOPT_NOWAIT, what is it ?
>
> What the patch implements is:
>
> If autovacuum ca
On Sat, Feb 5, 2011 at 3:07 PM, Cédric Villemain
wrote:
>> So I think this probably needs more testing
>> before we decide whether or not it's a good idea.
>
> I *may* have an opportunity to test that in a real world application
> where this hint bit was an issue.
That would be great. But note t
2011/2/5 Robert Haas :
> On Sat, Feb 5, 2011 at 10:37 AM, Cédric Villemain
> wrote:
>> Please update the commitfest with the accurate patch, there is only
>> the old immature v1 of the patch in it.
>> I was about reviewing it...
>>
>> https://commitfest.postgresql.org/action/patch_view?id=500
>
>
On Sat, Feb 5, 2011 at 12:54 PM, Cédric Villemain
wrote:
> what do you implement exactly ?
> * The original request from Josh to get LOG when autovac can not run
> because of locks
> * VACOPT_NOWAIT, what is it ?
What the patch implements is:
If autovacuum can't get the table lock immediately, i
On Sat, Feb 5, 2011 at 10:37 AM, Cédric Villemain
wrote:
> Please update the commitfest with the accurate patch, there is only
> the old immature v1 of the patch in it.
> I was about reviewing it...
>
> https://commitfest.postgresql.org/action/patch_view?id=500
Woops, sorry about that. Here's an
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > Tom Lane wrote:
> > >> Bruce Momjian writes:
> > >>> I have reviewed is_absolute_path() and have implemented
> > >>> path_is_relative_and_below_cwd() to cleanly handle cases like 'E:abc' on
> > >>> Win32; patch attached.
> >
On Sat, Feb 5, 2011 at 10:56 AM, Tom Lane wrote:
> Robert Haas writes:
>> Err... wait. Actually, I think the right thing to do might be to
>> remove OCLASS_FOREIGN_TABLE altogether. I don't think it's actually
>> used for anything. For a foreign table, we use OCLASS_CLASS, just as
>> we do for
Heikki Linnakangas wrote:
> On 02.02.2011 19:36, Kevin Grittner wrote:
>
>> Then there's one still lurking outside the new predicate* files,
>> in heapam.c. It's about 475 lines into the heap_update function
>> (25 lines from the bottom). In reviewing where we needed to
>> acquire predicate lock
2011/2/4 Robert Haas :
> On Sun, Jan 30, 2011 at 10:26 PM, Robert Haas wrote:
>> On Sun, Jan 30, 2011 at 10:03 PM, Alvaro Herrera
>> wrote:
>>> Excerpts from Robert Haas's message of dom ene 30 23:37:51 -0300 2011:
>>>
Unless I'm missing something, making autovacuum.c call
ConditionalLo
Robert Haas writes:
> Err... wait. Actually, I think the right thing to do might be to
> remove OCLASS_FOREIGN_TABLE altogether. I don't think it's actually
> used for anything. For a foreign table, we use OCLASS_CLASS, just as
> we do for indexes and sequences. I think that's just leftover cr
2011/1/19 Robert Haas :
> On Wed, Jan 19, 2011 at 11:52 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> ... So what we
>>> want to do is write a percentage of them, in a way that guarantees
>>> that they'll all eventually get written if people continue to access
>>> the same data.
>>
>> The word "
On Thu, Jan 27, 2011 at 2:48 PM, Noah Misch wrote:
> Done as attached.
Looking at this still more, it appears that independent of any change
this patch may wish to make, there's a live bug here related to the
foreign table patch I committed back in December. Creating a foreign
table creates an e
On Sat, Feb 5, 2011 at 3:05 AM, Noah Misch wrote:
> Correct. It's perhaps obvious, but rewriting the table will always reindex
> it.
Right.
>> 3. If we're changing the data type of a column in the table, reindex the
>> table.
>
> Rebuild indexes that depend on a changing column. Other indexe
May I sum up?
o in the recent there are no efforts known to experiment with
reference types, methods, or rule inference on top of PostgreSQL --
advice that can be given mostly points to the given documented functionality
o inside the PostgreSQL community, there is not many knowledge in
c
Robert,
Thanks for the obviously thought-out review.
On Sat, Feb 05, 2011 at 01:29:35AM -0500, Robert Haas wrote:
> On Thu, Jan 27, 2011 at 2:48 PM, Noah Misch wrote:
> > Done as attached. ?This preserves compatibility with our current handling of
> > composite type dependencies. ?The rest you'v
36 matches
Mail list logo
