On 2013-09-06 23:07:04 -0400, Bruce Momjian wrote:
> On Fri, Sep 6, 2013 at 11:00:24PM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > On Thu, Sep 5, 2013 at 05:06:41PM -0400, Bruce Momjian wrote:
> > >> Another possible fix would be to avoid the IS NULL value optimizer
> > >> expansion i
On 2013-09-06 20:29:08 -0400, Bruce Momjian wrote:
> On Sat, Sep 7, 2013 at 12:26:23AM +0200, Andres Freund wrote:
> > I wonder if we shouldn't trigger most vacuums (not analyze!) via unset
> > fsm bits. Perhaps combined with keeping track of RecentGlobalXmin to
>
> Fsm bits? FSM tracks the free
Hi,
The revised patch for wal buffer statistics is attached.
A test script is also attached. Please take a look.
Regards,
(2013/07/19 7:49), Satoshi Nagayasu wrote:
Will revise and re-resubmit for the next CF.
Regards,
2013/07/19 1:06, Alvaro Herrera wrote:
What happened to this patch? We
2013/9/7 Tom Lane :
> Robert Haas writes:
>> I find this a somewhat depressing response. Didn't we discuss this
>> exact design at the developer meeting in Ottawa? I thought it sounded
>> reasonable to you then, or at least I don't remember you panning it.
>
> What I recall saying is that I didn
Robert Haas writes:
> On Fri, Sep 6, 2013 at 6:31 PM, Andres Freund wrote:
>> On 2013-09-06 14:48:33 -0400, Tom Lane wrote:
>>> Well, sure, but I would think that ALTER SYSTEM SET should be constrained
>>> to only set known GUCs, not invent new ones on the fly.
>> Hm. That sounds inconvenient to
On Fri, Sep 6, 2013 at 11:00:24PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Thu, Sep 5, 2013 at 05:06:41PM -0400, Bruce Momjian wrote:
> >> Another possible fix would be to avoid the IS NULL value optimizer
> >> expansion if a ROW construct is inside a ROW(). I have attached a patch
Bruce Momjian writes:
> On Thu, Sep 5, 2013 at 05:06:41PM -0400, Bruce Momjian wrote:
>> Another possible fix would be to avoid the IS NULL value optimizer
>> expansion if a ROW construct is inside a ROW(). I have attached a patch
>> that does this for review.
> Having received no replies, do p
On Thu, Sep 5, 2013 at 05:06:41PM -0400, Bruce Momjian wrote:
> Another possible fix would be to avoid the IS NULL value optimizer
> expansion if a ROW construct is inside a ROW(). I have attached a patch
> that does this for review.
Having received no replies, do people perfer this version of t
Greg Stark writes:
> What would be nicer would be to display the C define, EINVAL, EPERM, etc.
> Afaik there's no portable way to do that though. I suppose we could just
> have a small array or hash table of all the errors we know about and look
> it up.
Yeah, I was just thinking the same thing.
Andres Freund writes:
> On 2013-09-06 10:13:23 -0400, Tom Lane wrote:
>> Well, if you feel an absolute compulsion to make them consistent, I'd
>> go with making SET disallow creation of variables with names the file
>> parser wouldn't recognize. But why is it such a bad thing if SET can
>> do tha
On Wed, 2013-09-04 at 10:06 +0200, Boszormenyi Zoltan wrote:
> 2013-08-17 12:08 keltezéssel, Boszormenyi Zoltan írta:
> >
> > I have put the broken up patchset into a GIT tree of mine at GitHub:
> > https://github.com/zboszor/ecpg-readahead/
> > but the huge compressed patch is also attached for re
On Wed, 2013-08-28 at 13:56 +0200, Kohei KaiGai wrote:
> The attached patch fixed the portion I was pointed out, so its overall
> design has not been changed so much.
The documentation doesn't build:
openjade:catalogs.sgml:237:28:X: reference to non-existent ID
"CATALOG-PG-ROWLEVELSEC"
--
S
On Fri, Sep 6, 2013 at 06:36:47PM +0200, Andres Freund wrote:
> On 2013-09-06 12:30:56 -0400, Bruce Momjian wrote:
> > > I am not sure I understand this though. What would be the point to go
> > > and set all visible and not do the rest of the vacuuming work?
> > >
> > > I think triggering vacuumi
Kohei KaiGai writes:
> The attached patch adds a new plan node type; CustomPlan that enables
> extensions to get control during query execution, via registered callbacks.
TBH, I think this is really an exercise in building useless mechanism.
I don't believe that any actually *interesting* new typ
On Sat, Sep 7, 2013 at 12:26:23AM +0200, Andres Freund wrote:
> > So, what should trigger an auto-vacuum vacuum for these workloads?
> > Rather than activity, which is what normally drives autovacuum, it is
> > lack of activity that should drive it, combined with a high VM cleared
> > bit percent
On Fri, Sep 6, 2013 at 01:01:59PM -0400, Bruce Momjian wrote:
> This December 2012 thread by Andrew Dunstan shows he wasn't aware that a
> manual VACUUM was required for index-only scans. That thread ended with
> us realizing that pg_upgrade's ANALYZE runs will populate
> pg_class.relallvisible.
On 9/5/13 2:42 PM, Blake Smith wrote:
> Thanks for checking the tests. I wasn't able to duplicate your test
> results. Did you run the hstore regression tests with the revised patch
> I attached in the thread? Attached is the output I got with the latest
> patch applied.
See
http://pgci.eisentrau
On 9/5/13 10:47 PM, Noah Misch wrote:
On Thu, Sep 05, 2013 at 10:41:25AM -0700, Jeff Janes wrote:
In order to avoid the rewrite, the code would have to be changed to
look up the column definition and if it specifies the scale, then
ignore the per-row n_header, and look at the n_header only if th
On 2013-09-06 13:01:59 -0400, Bruce Momjian wrote:
> On Fri, Sep 6, 2013 at 06:36:47PM +0200, Andres Freund wrote:
> > On 2013-09-06 12:30:56 -0400, Bruce Momjian wrote:
> > > > I am not sure I understand this though. What would be the point to go
> > > > and set all visible and not do the rest of
On Wed, Aug 28, 2013 at 10:30:34PM -0400, Noah Misch wrote:
> On Wed, Aug 28, 2013 at 03:16:14PM +0200, Andres Freund wrote:
> > I vote for just removing that VALGRIND_PRINTF - it doesn't give you
> > anything you cannot easily achieve otherwise...
Done.
> I'd like to see a buildfarm member runni
Robert Haas writes:
> I find this a somewhat depressing response. Didn't we discuss this
> exact design at the developer meeting in Ottawa? I thought it sounded
> reasonable to you then, or at least I don't remember you panning it.
What I recall saying is that I didn't see how the planner side
On Fri, Sep 6, 2013 at 2:34 PM, Hannu Krosing wrote:
> On 09/06/2013 07:57 PM, Robert Haas wrote:
>> On Fri, Sep 6, 2013 at 12:34 PM, Greg Stark wrote:
>>> But I wonder if we could just declare that that's not what the scale typmod
>>> does. That it's just a maximum scale but it's perfectly valid
On Sun, Jun 9, 2013 at 10:25 PM, Noah Misch wrote:
> - Test recovery, such as by running a streaming replica under Memcheck
> while
> the primary runs "make installcheck-world".
>
In general we need a lot more testing on the recovery code.
> - Memcheck has support for detecting leaks. I ha
On Fri, Sep 6, 2013 at 4:53 PM, Tom Lane wrote:
> Kohei KaiGai writes:
>> The attached patch adds a new plan node type; CustomPlan that enables
>> extensions to get control during query execution, via registered callbacks.
>
> TBH, I think this is really an exercise in building useless mechanism.
On Fri, Sep 6, 2013 at 6:31 PM, Andres Freund wrote:
> On 2013-09-06 14:48:33 -0400, Tom Lane wrote:
>> Andres Freund writes:
>> > On 2013-09-06 10:13:23 -0400, Tom Lane wrote:
>> >> Well, if you feel an absolute compulsion to make them consistent, I'd
>> >> go with making SET disallow creation o
On 2013-09-06 14:48:33 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-09-06 10:13:23 -0400, Tom Lane wrote:
> >> Well, if you feel an absolute compulsion to make them consistent, I'd
> >> go with making SET disallow creation of variables with names the file
> >> parser wouldn't recogni
On 2013-09-06 15:13:30 -0400, Bruce Momjian wrote:
> On Fri, Sep 6, 2013 at 01:01:59PM -0400, Bruce Momjian wrote:
> > This December 2012 thread by Andrew Dunstan shows he wasn't aware that a
> > manual VACUUM was required for index-only scans. That thread ended with
> > us realizing that pg_upgr
Alexander Korotkov writes:
> PostGIS spotted that picksplit algorithm freezes in infinite loop when
> dealing with nan values. I discovered same bug is present in core
> opclasses. Attached patch fixes this issue interpreting nan as value
> greater than infinity like btree comparison function does
Hannu Krosing writes:
> On 09/06/2013 08:48 PM, Tom Lane wrote:
>> Well, sure, but I would think that ALTER SYSTEM SET should be constrained
>> to only set known GUCs, not invent new ones on the fly.
> What's the reasoning behind this ?
If you don't know what a GUC is, you don't know what are va
On Fri, Sep 6, 2013 at 1:34 PM, Jeremy Harris wrote:
>> What's an index-hash operation?
>
> Ones that hit tuplesort_begin_index_hash()
Oh. Well, it looks to me like that function can only get called when
building a hash index. Specifically, according to the comment in
hashbuild(), a hash index
Blake,
I think it's better to implement this patch as a separate opclass, so users
will have option to choose indexing.
Oleg
On Tue, Sep 3, 2013 at 6:24 PM, Blake Smith wrote:
> Thanks for the feedback everyone. I've attached the patch that we are now
> running in production to service our hs
On 09/06/2013 08:48 PM, Tom Lane wrote:
> Andres Freund writes:
>> On 2013-09-06 10:13:23 -0400, Tom Lane wrote:
>>> Well, if you feel an absolute compulsion to make them consistent, I'd
>>> go with making SET disallow creation of variables with names the file
>>> parser wouldn't recognize. But w
Jim Nasby escribió:
> I also have a vague memory of some features that would benefit from
> being able to have typemod info available at a tuple level in a table,
> not just for the entire table. Unfortunately I can't remember why we
> wanted that... (Alvaro, do you recall? I'm pretty sure it's so
On 9/5/13 8:29 PM, Gavin Flower wrote:
How about a 'VACUUM AFTER' command (part of the 'BEGIN' transaction syntax?)
that would:
1. only be valid in a transaction
2. initiate a vacuum after the current transaction completed
3. defer any vacuum triggered due to other criteria
If the transacti
On Fri, Sep 6, 2013 at 9:34 AM, Greg Stark wrote:
>
>
> But I wonder if we could just declare that that's not what the scale typmod
> does. That it's just a maximum scale but it's perfectly valid for NUMERIC
> data with lower scales to be stored in a column than the typmod says. In a
> way the cur
Greg Stark writes:
> But I wonder if we could just declare that that's not what the scale typmod
> does. That it's just a maximum scale but it's perfectly valid for NUMERIC
> data with lower scales to be stored in a column than the typmod says. In a
> way the current behaviour is like bpchar but i
Hackers,
PostGIS spotted that picksplit algorithm freezes in infinite loop when
dealing with nan values. I discovered same bug is present in core
opclasses. Attached patch fixes this issue interpreting nan as value
greater than infinity like btree comparison function does.
This patch contain copy
On 9/6/13 2:13 PM, Bruce Momjian wrote:
On Fri, Sep 6, 2013 at 01:01:59PM -0400, Bruce Momjian wrote:
This December 2012 thread by Andrew Dunstan shows he wasn't aware that a
manual VACUUM was required for index-only scans. That thread ended with
us realizing that pg_upgrade's ANALYZE runs wil
Robert Haas writes:
> Sure, but the point is that 5. is not the same as 5.000 today. If
> you start whacking this around you'll be changing that behavior, I
> think.
Yeah. And please note that no matter what the OP may think, a lot of
people *do* consider that there's a useful distinction b
On 9/5/13 11:37 AM, Robert Haas wrote:
ISTM that at some point we'll want to look at putting top-level shared
>memory into this system (ie: allowing dynamic resizing of GUCs that affect
>shared memory size).
A lot of people want that, but being able to resize the shared memory
chunk itself is on
On Fri, Sep 6, 2013 at 12:34 PM, Greg Stark wrote:
> But I wonder if we could just declare that that's not what the scale typmod
> does. That it's just a maximum scale but it's perfectly valid for NUMERIC
> data with lower scales to be stored in a column than the typmod says. In a
> way the curren
On 09/06/2013 07:57 PM, Robert Haas wrote:
> On Fri, Sep 6, 2013 at 12:34 PM, Greg Stark wrote:
>> But I wonder if we could just declare that that's not what the scale typmod
>> does. That it's just a maximum scale but it's perfectly valid for NUMERIC
>> data with lower scales to be stored in a co
On Fri, Sep 6, 2013 at 03:08:54PM +0200, Andres Freund wrote:
> On 2013-09-06 01:22:36 -0400, Alvaro Herrera wrote:
> > I think it's shortsighted to keep thinking of autovacuum as just a way
> > to run VACUUM and ANALYZE. We have already discussed work items that
> > need to be done separately, s
On 06/09/13 15:44, Robert Haas wrote:
On Fri, Sep 6, 2013 at 3:34 AM, Jeremy Harris wrote:
I don't see the regression tests running any index-hash operations.
What am I missing?
What's an index-hash operation?
Ones that hit tuplesort_begin_index_hash()
--
Cheers,
Jeremy
--
Sent vi
On 2013-09-06 12:30:56 -0400, Bruce Momjian wrote:
> > I am not sure I understand this though. What would be the point to go
> > and set all visible and not do the rest of the vacuuming work?
> >
> > I think triggering vacuuming by scanning the visibility map for the
> > number of unset bits and us
On Thu, Sep 5, 2013 at 8:53 PM, Alvaro Herrera wrote:
> Greg Stark escribió:
>
> > The main difficulty is that Postgres is very extensible. So to implement
> > this you need to think bigger than NUMERIC. It should also be possible to
> > alter a column from varchar(5) to varchar(10) for example (b
On Fri, Sep 6, 2013 at 3:57 PM, Andres Freund wrote:
> On 2013-09-06 10:52:03 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > I have no clue about the gettext stuff but I am in favor of including
> > > the raw errno in strerror() messages (no backpatching tho).
> >
> > I dislike that on gr
Robert Haas wrote:
> Tom Lane wrote:
>> There's a large undercurrent of "I say it's bad for you" in
>> this thread, with frankly nothing to back it up. If we try to
>> be as nanny-ish as you're suggesting here, we'll just annoy
>> users.
>
> +1.
+1
I can definitely see a place for an ASCII7 en
"wangs...@highgo.com.cn" wrote:
> I modified the code for this situation.I consider it very simple.
> It will does not modify the table file, when the scale has been
> increased exclusively.
This patch would allow data in a column which was not consistent
with the column definition:
test=# cre
On 2013-09-06 10:52:03 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I have no clue about the gettext stuff but I am in favor of including
> > the raw errno in strerror() messages (no backpatching tho).
>
> I dislike that on grounds of readability and translatability; and
> I'm also of the o
Andres Freund writes:
> I have no clue about the gettext stuff but I am in favor of including
> the raw errno in strerror() messages (no backpatching tho).
I dislike that on grounds of readability and translatability; and
I'm also of the opinion that errno codes aren't really consistent
enough ac
On 09/06/2013 03:12 PM, Andres Freund wrote:
> On 2013-09-06 13:38:56 +0200, Hannu Krosing wrote:
>> On 09/06/2013 09:23 AM, Dimitri Fontaine wrote:
>>> Alvaro Herrera writes:
I'm not sure if we need to expose all these new maintenance actions as
SQL commands.
>>> I strongly think we sho
On Fri, Sep 6, 2013 at 10:19 AM, Tom Lane wrote:
> There's a large undercurrent of "I say it's bad for you" in this thread,
> with frankly nothing to back it up. If we try to be as nanny-ish as
> you're suggesting here, we'll just annoy users.
+1.
--
Robert Haas
EnterpriseDB: http://www.enterp
On Fri, Sep 6, 2013 at 3:34 AM, Jeremy Harris wrote:
>I don't see the regression tests running any index-hash operations.
> What am I missing?
What's an index-hash operation?
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscripti
On 2013-09-06 10:37:16 -0400, Tom Lane wrote:
> "MauMau" writes:
> > I've been suffering from PostgreSQL's problems related to character
> > encoding
> > for some time. I really wish to solve those problems, because they make
> > troubleshooting difficult. I'm going to propose fixes for them,
Andres Freund writes:
> On 2013-02-25 21:13:25 -0500, Tom Lane wrote:
>>> b) allow variables to start with a digit from the second level onwards.
>> That seems like a seriously bad idea. I note that SET does *not* allow
>> this;
> Hm. One thing about this is that we currently allow something si
"MauMau" writes:
> I've been suffering from PostgreSQL's problems related to character encoding
> for some time. I really wish to solve those problems, because they make
> troubleshooting difficult. I'm going to propose fixes for them, and I would
> appreciate if you could help release the of
On 2013-09-06 10:13:23 -0400, Tom Lane wrote:
> Andres Freund writes:
> >> That seems like a seriously bad idea. I note that SET does *not* allow
> >> this;
>
> > Hm. One thing about this is that we currently allow something silly as:
> > SET "1"."1bar""blub" = 3;
>
> > So I'd like to either rest
Craig Ringer writes:
> What we SHOULD be doing is making it an explicit decision to use
> SQL_ASCII, and NEVER creating a cluster or database with that encoding
> by default. Ever. If we can't decide what the correct default encoding
> is (say, if locale is "C") we should error out unless a specif
On 2013-02-25 21:13:25 -0500, Tom Lane wrote:
> > b) allow variables to start with a digit from the second level onwards.
>
> That seems like a seriously bad idea. I note that SET does *not* allow
> this;
Hm. One thing about this is that we currently allow something silly as:
SET "1"."1bar""blub
Hello,
I've been suffering from PostgreSQL's problems related to character encoding
for some time. I really wish to solve those problems, because they make
troubleshooting difficult. I'm going to propose fixes for them, and I would
appreciate if you could help release the official patches as
On 2013-09-06 13:38:56 +0200, Hannu Krosing wrote:
> On 09/06/2013 09:23 AM, Dimitri Fontaine wrote:
> > Alvaro Herrera writes:
> >> I'm not sure if we need to expose all these new maintenance actions as
> >> SQL commands.
> > I strongly think we should, if only for diagnostic purposes.
> It woul
On 2013-09-06 01:22:36 -0400, Alvaro Herrera wrote:
> I think it's shortsighted to keep thinking of autovacuum as just a way
> to run VACUUM and ANALYZE. We have already discussed work items that
> need to be done separately, such as truncating the last few empty pages
> on a relation that was vac
Hi Agustin,
> I want to know if exists a postgres function or some easy way to know if
a PK in a table is already referenced in another table/tables.
Unfortunately, this is not the correct mailing list.
Instead you should ask these types of questions on either NOVICE or GENERAL.
http://www.post
Hi everyone:
I want to know if exists a postgres function or some easy way to know if a
PK in a table is already referenced in another table/tables.
e.g.
I want to delete a row but first I've got to change or delete in the
table/tables where is referenced, and I have many table where could be
ref
On 09/06/2013 09:23 AM, Dimitri Fontaine wrote:
> Alvaro Herrera writes:
>> I'm not sure if we need to expose all these new maintenance actions as
>> SQL commands.
> I strongly think we should, if only for diagnostic purposes.
It would be much easier and more flexible to expose them
as pg_*() fun
On 4 Sep 2013 20:46, "Heikki Linnakangas" wrote:
>
> One fairly simple thing we could do is to teach catcache.c to resize the
caches. Then we could make the initial size of all the syscaches much
smaller. At the moment, we use fairly caches for catalogs like pg_enum (256
entries) and pg_usermappi
On 09/06/2013 09:14 AM, Craig Ringer wrote:
On 09/05/2013 08:47 PM, Peter Eisentraut wrote:
Other ideas? Are there legitimate uses for SQL_ASCII?
IMO people who want SQL_ASCII should actually be storing everything in
`bytea`; that's a truer reflection of what they're actually storing,
retriev
Le jeudi 5 septembre 2013 17:14:37 Bruce Momjian a écrit :
> On Thu, Sep 5, 2013 at 06:14:33PM +0200, Magnus Hagander wrote:
> > > I have developed the attached patch which implements an auto-tuned
> > > effective_cache_size which is 4x the size of shared buffers. I had to
> > > set effective_cac
Hi,
I don't see the regression tests running any index-hash operations.
What am I missing?
--
Cheers,
Jeremy
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Alvaro Herrera writes:
> I'm not sure if we need to expose all these new maintenance actions as
> SQL commands.
I strongly think we should, if only for diagnostic purposes. Also to
adapt to some well defined workloads that the automatic system is not
designed to handle.
Regards,
--
Dimitri Font
On 09/05/2013 08:47 PM, Peter Eisentraut wrote:
> Other ideas? Are there legitimate uses for SQL_ASCII?
IMO people who want SQL_ASCII should actually be storing everything in
`bytea`; that's a truer reflection of what they're actually storing,
retrieving, and working with and how they're doing it
72 matches
Mail list logo
