Sent from my iPad
On 04-Sep-2013, at 10:54, Satoshi Nagayasu wrote:
> Hi,
>
> (2013/09/04 12:52), Atri Sharma wrote:
>> On Wed, Sep 4, 2013 at 6:40 AM, Satoshi Nagayasu wrote:
>>> Hi,
>>>
>>> I'm considering overhauling pgstat.stat, and would like to know how many
>>> people are interested
Hi,
(2013/09/04 12:52), Atri Sharma wrote:
On Wed, Sep 4, 2013 at 6:40 AM, Satoshi Nagayasu wrote:
Hi,
I'm considering overhauling pgstat.stat, and would like to know how many
people are interested in this topic.
As you may know, this file could be handreds of MB in size, because
pgstat.stat
Hi,
(2013/09/04 13:07), Alvaro Herrera wrote:
Satoshi Nagayasu wrote:
As you may know, this file could be handreds of MB in size, because
pgstat.stat holds all access statistics in each database, and it needs
to read/write an entire pgstat.stat frequently.
As a result, pgstat.stat often gener
(2013/09/04 2:34), Josh Berkus wrote:
>
I've checked the PostgreSQL License,
and had a question.
http://opensource.org/licenses/PostgreSQL
>>
>> I don't know who opensource.org are, but their idea of "the PostgreSQL
>> license" doesn't appear to match the actual license text.
>
> Th
Hi,
In the following page, statistics are kept across server restarts:
http://www.postgresql.org/docs/current/static/monitoring-stats.html
"When the server shuts down, a permanent copy of the statistics data is stored
in the global subdirectory, so that statistics can be retained across server
Hi, Hackers!
I find that it takes a long time when I increase the scale of a numeric
datatype.
By checking the code, I found that's because it needs to rewrite that
table's file.
After checking that table's data file, I found only parameter n_header
changed.
And, I found the data in that nume
Satoshi Nagayasu wrote:
> As you may know, this file could be handreds of MB in size, because
> pgstat.stat holds all access statistics in each database, and it needs
> to read/write an entire pgstat.stat frequently.
>
> As a result, pgstat.stat often generates massive I/O operation,
> particular
On Wed, Sep 4, 2013 at 6:40 AM, Satoshi Nagayasu wrote:
> Hi,
>
> I'm considering overhauling pgstat.stat, and would like to know how many
> people are interested in this topic.
>
> As you may know, this file could be handreds of MB in size, because
> pgstat.stat holds all access statistics in eac
On Tue, Sep 3, 2013 at 09:44:33PM -0500, Merlin Moncure wrote:
> It gets worse and worse. The IS NULL operator is already pretty much
> special cased -- in just about all other case concerning rowtypes (for
> example coalesce) 'null containing rowtypes are *not* considered to be
> null as the con
On Tue, Sep 3, 2013 at 10:27:38PM -0400, Tom Lane wrote:
> I wrote:
> > And I will say once more that a patch that affects only the behavior of
> > eval_const_expressions can be rejected on its face. That code has to be
> > kept in sync with the behavior of execQual.c, not just whacked around by
On Tue, Sep 3, 2013 at 09:43:14PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > This has made me adjust my goal and change it so SELECT ROW(NULL) IS
> > NULL returns true, and any further nesting returns false.
>
> AFAICS, the only good argument for breaking backwards compatibility here
> i
On Tue, Sep 3, 2013 at 8:32 PM, Bruce Momjian wrote:
> On Fri, Jul 5, 2013 at 10:21:19AM -0400, Bruce Momjian wrote:
>> On Thu, Jul 4, 2013 at 04:29:20PM -0400, Tom Lane wrote:
>> > Bruce Momjian writes:
>> > > I developed the attached patch which properly recurses into ROW()
>> > > records che
The maintainer-check target never really caught on, I think. Most
people don't run it, and that in turn annoys those who do. Also, it
doesn't provide much functionality.
I propose that we get rid of it and roll the functionality into the
regular build.
Specifically:
- Running duplicate_oids du
I wrote:
> And I will say once more that a patch that affects only the behavior of
> eval_const_expressions can be rejected on its face. That code has to be
> kept in sync with the behavior of execQual.c, not just whacked around by
> itself. And then there are the NOT NULL constraint cases to wor
Bruce Momjian writes:
> This has made me adjust my goal and change it so SELECT ROW(NULL) IS
> NULL returns true, and any further nesting returns false.
AFAICS, the only good argument for breaking backwards compatibility here
is if you can convince people that the new behavior is more conformant
On Fri, Jul 5, 2013 at 10:21:19AM -0400, Bruce Momjian wrote:
> On Thu, Jul 4, 2013 at 04:29:20PM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > I developed the attached patch which properly recurses into ROW()
> > > records checking for NULLs; you can see it returns the right answer in
Hi,
I'm considering overhauling pgstat.stat, and would like to know how many
people are interested in this topic.
As you may know, this file could be handreds of MB in size, because
pgstat.stat holds all access statistics in each database, and it needs
to read/write an entire pgstat.stat frequent
>> 1)Addition of new string data types NATIONAL CHARACTER and NATIONAL
>> CHARACTER VARIABLE.
>> These types differ from the char/varchar data types in one important
>> respect: NATIONAL string types are always have UTF8 encoding even
>> (independent from used database encoding).
>I don't like
On Tue, Sep 3, 2013 at 9:13 AM, Tom Lane wrote:
> Andres Freund writes:
>> On 2013-09-03 08:59:53 -0500, Merlin Moncure wrote:
>>> While playing around with Andres's trick, I noticed that it works but
>>> will not match against operators taking "any" although those will
>>> match with explicit sc
On 2013-09-03 23:25:01 +0200, Hannu Krosing wrote:
> On 09/03/2013 05:27 PM, Robert Haas wrote:
> > On Thu, Aug 29, 2013 at 8:22 PM, Ants Aasma wrote:
> >> I might give it a shot later this cycle as I have familiarized my self
> >> with the problem domain anyway. I understand the appeal of staying
On 2013-09-03 15:56:15 -0400, Robert Haas wrote:
> On Tue, Sep 3, 2013 at 12:57 PM, Andres Freund wrote:
> >> And why is every 15 seconds good enough?
> >
> > Waiting 15s to become consistent instead of checkpoint_timeout seems to
> > be ok to me and to be a good tradeoff between overhead and wait
On 2013-09-03 12:56:53 -0400, Alvaro Herrera wrote:
> Antonin Houska wrote:
>
> > +
> > +Suffixes k (kilobytes) and m
> > +(megabytes) are accepted. For example: 10m
> > +
>
> "m" is for meters, or milli. Please use "M" here.
Shouldn't it be MB? Consistent with GUC
On Tue, Sep 3, 2013 at 07:47:22PM +0200, Magnus Hagander wrote:
>
> On Sep 3, 2013 6:23 PM, "Josh Berkus" wrote:
> >
> > Peter,
> >
> >
> > > I wonder, is anyone really running in production with full_page_writes
> > > off?
> >
> > We're doing so with clients on Joyent (ZFS). And also for "ephe
On 09/03/2013 05:27 PM, Robert Haas wrote:
> On Thu, Aug 29, 2013 at 8:22 PM, Ants Aasma wrote:
>> I might give it a shot later this cycle as I have familiarized my self
>> with the problem domain anyway. I understand the appeal of staying
>> with what we have, but this would cap the speedup at 4x
On 09/03/2013 06:56 PM, Alvaro Herrera wrote:
>> +/*
>> + * Only the following suffixes are allowed. It's not
>> too useful to
>> + * restrict the rate to gigabytes: such a rate will
>> probably bring
>> + * signific
On Tue, Sep 3, 2013 at 12:57 PM, Andres Freund wrote:
>> To my way of thinking, it seems as though we ought to always begin
>> replay at a checkpoint, so the standby ought always to see one of
>> these records immediately. Obviously that's not good enough, but why
>> not?
>
> We always see one af
Antonin Houska wrote:
> +
> +Suffixes k (kilobytes) and m
> +(megabytes) are accepted. For example: 10m
> +
"m" is for meters, or milli. Please use "M" here.
> +static uint32
> +parse_max_rate(char *src)
> +{
> + int factor;
> + char
On Mon, Sep 2, 2013 at 10:10 PM, Jeff Davis wrote:
> There is a significant amount of code supporting the changing of
> full_page_writes while the server is running, including an
> XLOG_FPW_CHANGE wal record. But I don't see the use-case; surely almost
> nobody changes this on a running server, be
Robert Haas escribió:
> The patch file turned out to be sorta garbled. I'm not sure if a
> broken version of diff was used to generate this or whether MauMau
> hand-edited it after the fact, but the number of lines that were
> indicated in the control lines didn't match the actual hunks, and
> pa
Bruce Momjian wrote:
> On Mon, Sep 2, 2013 at 10:14:03AM +0300, Heikki Linnakangas wrote:
> > diff --git a/src/backend/access/transam/xlog.c
> > b/src/backend/access/transam/xlog.c
> > index 39c58d0..28e62ea 100644
> > - XLogInsertSlotPadded *insertSlots;
> > + /*
> > +* Make sure the ab
Robert Haas writes:
> On Sun, Sep 1, 2013 at 10:36 AM, Stefan Kaltenbrunner
> wrote:
>> attached is a rough patch that does exactly that, if we are worried
>> about an api change we could simple do a ProcessGUCArrayNotice() in the
>> backbranches if that approach is actually sane.
> This patch h
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> So I think a more reasonable fix is just to skip the ProcessGUCArray
> call altogether when check_function_bodies = false, and to document
> that validators mustn't assume anything about the GUC environment
> when check_function_bodies = false.
>
> If no ob
On Tue, Sep 3, 2013 at 9:23 AM, Josh Berkus wrote:
> So it should remain a setting.
Sure. I wasn't suggesting deprecating it or anything.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/m
>>> I've checked the PostgreSQL License,
>>> and had a question.
>>> http://opensource.org/licenses/PostgreSQL
>
> I don't know who opensource.org are, but their idea of "the PostgreSQL
> license" doesn't appear to match the actual license text.
The OSI, which is the organization which defines w
On Sep 3, 2013 6:23 PM, "Josh Berkus" wrote:
>
> Peter,
>
>
> > I wonder, is anyone really running in production with full_page_writes
> > off?
>
> We're doing so with clients on Joyent (ZFS). And also for "ephemeral"
> postgres instances -- ones where we've also turned off fsync.
>
> It's also q
Robert Haas writes:
> On Tue, Sep 3, 2013 at 12:16 PM, Tomonari Katsumata
> wrote:
>> PostgreSQL is released under "the PostgreSQL License".
>> http://www.postgresql.org/about/licence/
The actual license terms can be found in the COPYRIGHT file in our
distribution. There is nothing in there men
On 2013-09-03 12:22:22 -0400, Robert Haas wrote:
> On Tue, Sep 3, 2013 at 12:05 PM, Andres Freund wrote:
> >> 1. I think more comments are needed here to explain why we need this.
> >> I don't know if the comments should go into the functions modified by
> >> this patch or in some other location,
On 09/03/2013 06:15 PM, Robert Haas wrote:
> On Sun, Sep 1, 2013 at 10:36 AM, Stefan Kaltenbrunner
> wrote:
>>> It would seem that a simple solution would be to add an elevel argument
>>> to ProcessGUCArray and then call it with NOTICE in the case that
>>> check_function_bodies is true. None of t
On 09/03/2013 11:16 AM, Tomonari Katsumata wrote:
> It seems the contents of the "COPYRIGTH" file are all required by the
> license.
> So I have confused why PostgreSQL has a "COPYRIGHT" file instead of
> "LICENSE".
> Anybody knows the reason?
> And is this non problem thing?
The first paragraph o
On Sun, Sep 1, 2013 at 10:36 AM, Stefan Kaltenbrunner
wrote:
>> It would seem that a simple solution would be to add an elevel argument
>> to ProcessGUCArray and then call it with NOTICE in the case that
>> check_function_bodies is true. None of the contrib modules call
>> ProcessGUCArray, but sh
On Tue, Sep 3, 2013 at 12:16 PM, Tomonari Katsumata
wrote:
> Hi,
>
> PostgreSQL is released under "the PostgreSQL License".
> http://www.postgresql.org/about/licence/
>
> I've checked the PostgreSQL License,
> and had a question.
> http://opensource.org/licenses/PostgreSQL
>
> It seems that the li
On Mon, Sep 2, 2013 at 3:16 PM, Jeff Davis wrote:
> On Fri, 2013-08-30 at 20:34 +0200, Andres Freund wrote:
>> I have a quick question: The reason I'd asked about the status of the
>> patch was that I was thinking about the state of the "forensic freezing"
>> patch. After a quick look at your prop
Hi,
PostgreSQL is released under "the PostgreSQL License".
http://www.postgresql.org/about/licence/
I've checked the PostgreSQL License,
and had a question.
http://opensource.org/licenses/PostgreSQL
It seems that the license requres a "LICENSE" file
in the target product
[quote]
> Then put the l
Peter,
> I wonder, is anyone really running in production with full_page_writes
> off?
We're doing so with clients on Joyent (ZFS). And also for "ephemeral"
postgres instances -- ones where we've also turned off fsync.
It's also quite reasonable to assume that future filesystems will also
be
On Tue, Sep 3, 2013 at 12:05 PM, Andres Freund wrote:
>> 1. I think more comments are needed here to explain why we need this.
>> I don't know if the comments should go into the functions modified by
>> this patch or in some other location, but I don't find what's here now
>> adequate for understa
On 2013-09-03 11:40:57 -0400, Robert Haas wrote:
> On Fri, Aug 30, 2013 at 11:19 AM, Andres Freund
> wrote:
> > 0005 wal_decoding: Log xl_running_xact's at a higher frequency than
> > checkpoints are done
> > * benefits hot standby startup
>
> Review:
>
> 1. I think more comments are needed he
On Fri, Aug 30, 2013 at 2:29 PM, Andres Freund wrote:
>> I don't know how big an impact adding the database oid would have, on the
>> case that the PGPROC/PGXACT split was done in the first place. In the worst
>> case it will make taking a snapshot 1/3 slower under contention. That needs
>> to be
On Fri, Aug 30, 2013 at 5:01 AM, Bjorn Munch wrote:
> On 29/08 21.17, MauMau wrote:
>>
>> Thanks. I belive PostgreSQL runs successfully on Solaris 10 and later,
>> because the binaries are published on the community site:
>>
>> http://ftp.postgresql.org/pub/binary/v9.3beta2/solaris/
>
> Sorry, I
On Thu, Aug 29, 2013 at 8:22 PM, Ants Aasma wrote:
> I might give it a shot later this cycle as I have familiarized my self
> with the problem domain anyway. I understand the appeal of staying
> with what we have, but this would cap the speedup at 4x and has large
> caveats with the extra lookup t
On Fri, Aug 30, 2013 at 11:19 AM, Andres Freund wrote:
> 0005 wal_decoding: Log xl_running_xact's at a higher frequency than
> checkpoints are done
> * benefits hot standby startup
Review:
1. I think more comments are needed here to explain why we need this.
I don't know if the comments should
On 09/03/2013 04:02 AM, Cédric Villemain wrote:
Simple one, attached.
I didn't document USE_VPATH, not sure how to explain that clearly.
Just a remember that the doc is written and is waiting to be commited.
There is also an issue spoted by Christoph with the installdirs prerequisite,
the atta
* Peter Geoghegan (p...@heroku.com) wrote:
> I wonder, is anyone really running in production with full_page_writes
> off?
The simple answer to this is "yes, definitely."
I don't know if they change it on-the-fly, but I doubt it.
Thanks,
Stephen
signature.asc
Descript
Thanks for the feedback everyone. I've attached the patch that we are now
running in production to service our hstore include queries. We rebuilt the
index to account for the on-disk incompatibility. I've submitted the patch
to commitfest here:
https://commitfest.postgresql.org/action/patch_view?id
Andres Freund writes:
> On 2013-09-03 08:59:53 -0500, Merlin Moncure wrote:
>> While playing around with Andres's trick, I noticed that it works but
>> will not match against operators taking "any" although those will
>> match with explicit schema declaration (FWICT it goes through the
>> search_p
On 2013-09-03 08:59:53 -0500, Merlin Moncure wrote:
> While playing around with Andres's trick, I noticed that it works but
> will not match against operators taking "any" although those will
> match with explicit schema declaration (FWICT it goes through the
> search_path trying to explicitly matc
On Fri, Aug 30, 2013 at 5:48 PM, Andres Freund wrote:
> Hi,
>
> On 2013-08-30 17:35:04 -0500, Merlin Moncure wrote:
>> "When a schema-qualified operator name is used in the OPERATOR syntax,
>> as for example in:
>> SELECT 3 OPERATOR(pg_catalog.+) 4;
>> the OPERATOR construct is taken to have the d
Heikki Linnakangas writes:
> On 03.09.2013 05:28, Boguk, Maksym wrote:
>> Target usage: ability to store UTF8 national characters in some
>> selected fields inside a single-byte encoded database.
> I think we should take a completely different approach to this. Two
> alternatives spring to mind
On 2013-09-02 21:59:42 -0700, Peter Geoghegan wrote:
> > I can't really agree with this part. First off, a heap_insert()
> > certainly isn't lightweight operation. There's several things that can
> > take extended time:
> > * toasting of rows (writing a gigabyte worth of data...)
> > * extension of
On Mon, Sep 2, 2013 at 10:32 PM, Bruce Momjian wrote:
> On Mon, Sep 2, 2013 at 10:14:03AM +0300, Heikki Linnakangas wrote:
>> diff --git a/src/backend/access/transam/xlog.c
>> b/src/backend/access/transam/xlog.c
>> index 39c58d0..28e62ea 100644
>> --- a/src/backend/access/transam/xlog.c
>> +++ b
Hi,
On 2013-09-03 14:35:18 +0200, Antonin Houska wrote:
> + /*
> + * THROTTLING_SAMPLE_MIN / MAX_RATE_LOWER (in seconds) should
> be the
> + * longest possible time to sleep.
> + */
> + pg_usleep((long) sleep);
> + else
> +
> +
On 07/24/2013 09:20 AM, Antonin Houska wrote:
> Hello,
> the purpose of this patch is to limit impact of pg_backup on running
> server.
Attached is a new version. Server-side implementation this time.
Antonin Houska (Tony)
diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_b
On 2013-09-02 19:10:57 -0700, Jeff Davis wrote:
> There is a significant amount of code supporting the changing of
> full_page_writes while the server is running, including an
> XLOG_FPW_CHANGE wal record. But I don't see the use-case; surely almost
> nobody changes this on a running server, becaus
On Tue, Sep 3, 2013 at 2:11 AM, Peter Geoghegan wrote:
> and it would be totally unacceptable if that meant that lots of people
> blocked on the page lock that an upserter held while it tried to
> acquire locks on tuples
By which I mean: it seems shaky that I'd then be assuming that to lock
all
On Tue, Sep 3, 2013 at 12:52 AM, Craig Ringer wrote:
> That'd certainly be the ideal, but as you say is far from simple, and
> IIRC prior discussions here have suggested the SSI / predicate locking
> stuff won't help.
I think that by far the strongest argument for what Andres suggested
(that has,
> Simple one, attached.
> I didn't document USE_VPATH, not sure how to explain that clearly.
Just a remember that the doc is written and is waiting to be commited.
There is also an issue spoted by Christoph with the installdirs prerequisite,
the attached patch fix that.
Also, the bugfixes were
On 09/03/2013 06:18 AM, Peter Geoghegan wrote:
> On Mon, Sep 2, 2013 at 6:25 AM, Craig Ringer wrote:
>> It'll be yet another way for people to get upsert wrong, of course.
>> They'll use a wCTE with RETURNING REJECTS to do an UPDATE of the rejects
>> w/o locking the table against writes first. Doc
On 03.09.2013 05:28, Boguk, Maksym wrote:
Target usage: ability to store UTF8 national characters in some
selected fields inside a single-byte encoded database.
For sample if I have a ru-RU.koi8r encoded database with mostly Russian
text inside, it would be nice to be able store an Japanese tex
于 2013-09-03 08:15, David Johnston 回复:
Jeff Davis-8 wrote
Is there any semantic difference between marking a constraint as
DISABLED and simply dropping it? Or does it just make it easier to
re-add it later?
David Johnston wrote:
I cannot answer the question but if there is none then the main
68 matches
Mail list logo
