> > > I have updated the patch as per comments from Tom and Heikki.
> > > If you can verify it, then IMO it can be marked as 'Ready For
> > Committer'
> >
> > Would you please do that?
>
> Done.
Thank you.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hack
Hello, I looked this from another point of view.
I consider the current discussion to be based on how to predict
the last consistency point. But there is another aspect of this
issue.
I tried to postpone smgrtruncate after the next checkpoint. This
is similar to what hotstandby feedback does to v
On Mon, Feb 18, 2013 at 7:50 AM, Alvaro Herrera
wrote:
>
> So here's v11. I intend to commit this shortly. (I wanted to get it
> out before lunch, but I introduced a silly bug that took me a bit to
> fix.)
On Windows with Mingw I get this:
pgstat.c:4389:8: warning: variable 'found' set but not
On Tue, Jan 08, 2013 at 08:02:16PM -0500, Robert Haas wrote:
> On Tue, Jan 8, 2013 at 7:57 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> I was thinking more about a sprintf()-type function that only
> >> understands a handful of escapes, but adds the additional and novel
> >> escapes %I (quote
On Tue, Feb 19, 2013 at 5:48 PM, Simon Riggs wrote:
In access/transam/xlog.c we give the OS buffer caching a hint that we
won't need a WAL file any time soon with
posix_fadvise(openLogFile, 0, 0, POSIX_FADV_DONTNEED);
>
> I agree with Merlin and Joachim - if we have t
On Wed, Jan 23, 2013 at 12:06 PM, Pavel Stehule wrote:
> 2013/1/14 Tom Lane :
>> Well, fine, but then it should fix both of them and remove
>> minimal_error_message altogether. I would however suggest eyeballing
>> what happens when you try "\ef nosuchfunction" (with or without -E).
>> I'm pretty
Sorry, I found one more typo. Attached is a patch.
Thanks,
Best regards,
Etsuro Fujita
> -Original Message-
> From: Magnus Hagander [mailto:mag...@hagander.net]
> Sent: Friday, February 08, 2013 7:47 PM
> To: Etsuro Fujita
> Cc: PostgreSQL-development
> Subject: Re: [HACKERS] Comment ty
On Thu, Jan 24, 2013 at 11:40:41AM -0500, Xi Wang wrote:
> On 1/24/13 10:48 AM, Tom Lane wrote:
> > The fundamental problem here is that the compiler, unless told otherwise
> > by a compilation switch, believes it is entitled to assume that no
> > integer overflow will happen anywhere in the progra
On Mon, Jan 9, 2012 at 9:11 AM, Magnus Hagander wrote:
> On Mon, Jan 9, 2012 at 12:00, Magnus Hagander wrote:
> > On Mon, Jan 9, 2012 at 11:09, Magnus Hagander
> wrote:
> >> On Mon, Jan 9, 2012 at 07:34, Jaime Casanova
> wrote:
> >>> Hi,
> >>>
> >>> I was trying pg_basebackup on head, i used t
On 02/19/2013 03:41 PM, Kevin Grittner wrote:
> Kevin Grittner wrote:
>
>> I'm attaching the patch for just the system_views.sql file
>> for discussion before I go write docs for this part.
>
> Meh. If I'm gonna have pg_matviews I might as well include an
> isscannable column. v2 attached.
pg
Hopefully I am not wrong.
+/* Size of a varlena data, excluding header */
#define VARSIZE_ANY_EXHDR(PTR) \
--
Gurjeet Singh
http://gurjeet.singh.im/
EnterprsieDB Inc.
exhdr_comment.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
Kevin Grittner wrote:
> I'm attaching the patch for just the system_views.sql file
> for discussion before I go write docs for this part.
Meh. If I'm gonna have pg_matviews I might as well include an
isscannable column. v2 attached.
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
Josh Berkus wrote:
>> That I could probably do. Do you think they should have a separate
>> pg_stat_user_matviews table, etc., or do you think it would be
>> better to include them in with tables there?
>
> Well, ideally pg_matviews would have matview definitions, and
> pg_stat_matviews would ha
On 19 February 2013 20:19, Merlin Moncure wrote:
>>> In access/transam/xlog.c we give the OS buffer caching a hint that we
>>> won't need a WAL file any time soon with
>>>
>>> posix_fadvise(openLogFile, 0, 0, POSIX_FADV_DONTNEED);
>>>
> If that's the case, why have the advisory call at all?
Kevin Grittner
> There was one minor syntax issue not addressed by Noah, nor much
> discussed in general that I didn't want to just unilaterally
> choose; but given that nobody seems to care that much I will put
> forward a proposal and do it that way tomorrow if nobody objects.
> Before this pat
> That I could probably do. Do you think they should have a separate
> pg_stat_user_matviews table, etc., or do you think it would be
> better to include them in with tables there?
Well, ideally pg_matviews would have matview definitions, and
pg_stat_matviews would have stats on matview usage an
On 19.2.2013 23:31, Alvaro Herrera wrote:> Tomas Vondra wrote:
>
>> AFAIK the stats remain the same within a transaction, and as a
>> function runs within a transaction, it will either get new data on
>> the first iteration, or it will run all 300 of them. I've checked
>> several buildfarm members
Josh Berkus wrote:
> Well, I'm not sure about information_schema, but we'll definitely
> want a pg_matviews system view.
> That could wait until 9.4, though.
That I could probably do. Do you think they should have a separate
pg_stat_user_matviews table, etc., or do you think it would be
better
Tomas Vondra wrote:
> AFAIK the stats remain the same within a transaction, and as a function
> runs within a transaction, it will either get new data on the first
> iteration, or it will run all 300 of them. I've checked several
> buildfarm members and I'm yet to see a single duration between 12m
Erik Rijkers wrote:
> I was wondering if material views should not go into
> information_schema. I was thinking either .views or .tables.
> Have you considered this?
I had not considered this to be a good idea because
information_schema is defined by the standard, and materialized
views are an
On Tue, Feb 19, 2013 at 11:09:13PM +0100, Erik Rijkers wrote:
> On Sat, February 16, 2013 02:01, Kevin Grittner wrote:
> > matview-v4.patch.gz
>
> Hi,
>
> I was wondering if material views should not go into information_schema. I
> was thinking either
> .views or .tables. Have you considered t
On 02/19/2013 02:09 PM, Erik Rijkers wrote:
> On Sat, February 16, 2013 02:01, Kevin Grittner wrote:
>> matview-v4.patch.gz
>
> Hi,
>
> I was wondering if material views should not go into information_schema. I
> was thinking either
> .views or .tables. Have you considered this?
>
> I ask bec
On Sat, February 16, 2013 02:01, Kevin Grittner wrote:
> matview-v4.patch.gz
Hi,
I was wondering if material views should not go into information_schema. I was
thinking either
.views or .tables. Have you considered this?
I ask because as far as I can see querying for mv's has to go like this:
Please find attached the patch for some cleanup and fix bit rot in pgindent
script.
There were a few problems with the script.
.) It failed to use the $ENV{PGENTAB} even if it was set.
.) The file it tries to download from Postgres' ftp site is no longer
present.
ftp://ftp.postgresql.org/pub/
On 19.2.2013 11:27, Tom Lane wrote:
> Tomas Vondra writes:
>> Dne 19.02.2013 05:46, Alvaro Herrera napsal:
>>> Mastodon failed:
>>> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mastodon&dt=2013-02-19%2000%3A00%3A01
>>>
>>> probably worth investigating a bit; we might have broken somethin
On 19.02.2013 20:07, Fabrízio de Royes Mello wrote:
I would like to propose implement a way to track creation times to database
objects. This was discussed before in this thread [1].
This was discussed before in this thread [1] but we don't reach a consensus
of what we'll do, so I propose we dis
On Tue, Feb 19, 2013 at 5:38 PM, Josh Berkus wrote:
>
> > This was discussed before in this thread [1] but we don't reach a
> consensus
> > of what we'll do, so I propose we discuss any more about it and I can
> > implement it in GSOC2013, if my proposal will be accepted.
>
> As a mentor or as a
> This was discussed before in this thread [1] but we don't reach a consensus
> of what we'll do, so I propose we discuss any more about it and I can
> implement it in GSOC2013, if my proposal will be accepted.
As a mentor or as a student?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexpert
On Mon, Feb 18, 2013 at 2:16 AM, Heikki Linnakangas
wrote:
> On 17.02.2013 14:55, Joachim Wieland wrote:
>>
>> In access/transam/xlog.c we give the OS buffer caching a hint that we
>> won't need a WAL file any time soon with
>>
>> posix_fadvise(openLogFile, 0, 0, POSIX_FADV_DONTNEED);
>>
>> b
2013/2/19 Josh Berkus :
>
>>> I've come to value greppability of source code pretty highly. I think
>> that
>>> some of the points you raise are valid, but in my (minority) opinion
>>> overloading creates more problems than it solves. You're not going to
>>> convince me that get() is *ever* a goo
>> I've come to value greppability of source code pretty highly. I think
> that
>> some of the points you raise are valid, but in my (minority) opinion
>> overloading creates more problems than it solves. You're not going to
>> convince me that get() is *ever* a good name for a function - you mi
On Thu, Feb 14, 2013 at 4:02 PM, Josh Berkus wrote:
>
>
> [...]
>
> - Please suggest project ideas for GSOC
>
> - Students seeing this -- please speak up if you have projects you plan
> to submit.
>
>
I would like to propose implement a way to track creation times to database
objects. This was dis
On Feb 19, 2013, at 6:11 AM, Petr Jelinek wrote:
>> some of the points you raise are valid, but in my (minority) opinion
>> overloading creates more problems than it solves. You're not going to
>> convince me that get() is *ever* a good name for a function - you might as
>> well call it thing()
Dne 19.02.2013 11:27, Tom Lane napsal:
Tomas Vondra writes:
Dne 19.02.2013 05:46, Alvaro Herrera napsal:
Mastodon failed:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mastodon&dt=2013-02-19%2000%3A00%3A01
probably worth investigating a bit; we might have broken something.
Hmmm,
On 2/19/13 8:54 AM, Robert Haas wrote:
> In the department of crazy ideas, what about having pg_dump NEVER
> refresh ANY materialized views?
It might be useful to have an option for this, but I don't think it
should be the default. The default should be that the new database is
"ready to go".
Th
On Mon, Feb 18, 2013 at 8:27 PM, Heikki Linnakangas
wrote:
> backupStartPoint is set, which signals recovery to wait for an end-of-backup
> record, until the system is considered consistent. If the backup is taken
> from a hot standby, backupEndPoint is set, instead of inserting an
> end-of-backup
On Thu, Feb 14, 2013 at 4:08 PM, Michael Paquier
wrote:
> Hi all,
>
> Please find attached a new set of 3 patches for REINDEX CONCURRENTLY (v11).
> - 20130214_1_remove_reltoastidxid.patch
> - 20130214_2_reindex_concurrently_v11.patch
> - 20130214_3_reindex_concurrently_docs_v11.patch
> Patch 1 nee
On Tue, Feb 19, 2013 at 8:04 AM, Robert Haas wrote:
>> The argument for removing json_ prefix is that when function behaviors
>> are unambiguously controlled by the arguments, decorating the function
>> name to match the input argument is unnecessary verbosity.
>
> I've come to value greppability
On 2013-02-19 09:12:02 -0500, Robert Haas wrote:
> On Tue, Feb 19, 2013 at 9:00 AM, Andres Freund wrote:
> >> So the other way that we could do this is to use something that's the
> >> same size as a TOAST pointer but has different content - the
> >> seemingly-obvious choice being va_toastrelid =
2013/2/19 Robert Haas :
> In the department of crazy ideas, what about having pg_dump NEVER
> refresh ANY materialized views?
>
> It's true that the job of pg_dump and pg_restore is to put the new
> database in the same state that the old database was in, but I think
> you could make a reasonable
2013/2/19 Petr Jelinek :
>> -Original Message-
>> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
>> ow...@postgresql.org] On Behalf Of Robert Haas
>> Sent: 19 February 2013 15:05
>> To: Merlin Moncure
>> Cc: David E. Wheeler; PostgreSQL-development Hackers
>> > The argument
On Tue, Feb 19, 2013 at 9:00 AM, Andres Freund wrote:
>> So the other way that we could do this is to use something that's the
>> same size as a TOAST pointer but has different content - the
>> seemingly-obvious choice being va_toastrelid == 0.
>
> Unfortunately that would mean you need to copy t
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Robert Haas
> Sent: 19 February 2013 15:05
> To: Merlin Moncure
> Cc: David E. Wheeler; PostgreSQL-development Hackers
> > The argument for removing json_ prefix is th
On Mon, Feb 18, 2013 at 10:42 AM, Merlin Moncure wrote:
> if you wanted to. And yes, I absolutely think this is superior to
> cluttering the public namespace with xml specific verbage, and could
> be extended to other formats. Look at the other way: we currently
> have encode(format text, stuff
On 2013-02-19 08:48:05 -0500, Robert Haas wrote:
> On Sat, Feb 16, 2013 at 11:42 AM, Andres Freund
> wrote:
> > Given that there have been wishes to support something like b) for quite
> > some time, independent from logical decoding, it seems like a good idea
> > to add support for it. Its e.g.
On Sun, Feb 17, 2013 at 4:12 PM, Dimitri Fontaine
wrote:
>>> Well, a list of object OIDs is of exactly zero use once the command
>>> has been carried out. So I don't think that that represents a useful
>>> or even very testable feature on its own, if there's no provision to
>>> fire user code whi
On Mon, Feb 18, 2013 at 4:48 PM, Kevin Grittner wrote:
> This should allow me to simplify the code a little bit and move the
> RMV step to the very end. That may have some advantages when users
> want to start using the database while MVs are being populated.
In the department of crazy ideas, wh
On Sat, Feb 16, 2013 at 11:42 AM, Andres Freund wrote:
> Given that there have been wishes to support something like b) for quite
> some time, independent from logical decoding, it seems like a good idea
> to add support for it. Its e.g. useful for avoiding repeated detoasting
> or decompression o
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Amit Kapila
> Sent: Monday, February 18, 2013 6:38 PM
> To: 'Heikki Linnakangas'
> Cc: 'Phil Sorber'; 'Alvaro Herrera'; 'Magnus Hagander'; 'PostgreSQL-
> development
Tomas Vondra writes:
> Dne 19.02.2013 05:46, Alvaro Herrera napsal:
>> Mastodon failed:
>> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mastodon&dt=2013-02-19%2000%3A00%3A01
>>
>> probably worth investigating a bit; we might have broken something.
> Hmmm, interesting. A single Windows
Dne 19.02.2013 05:46, Alvaro Herrera napsal:
Alvaro Herrera wrote:
I have pushed it now. Further testing, of course, is always
welcome.
Mastodon failed:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mastodon&dt=2013-02-19%2000%3A00%3A01
probably worth investigating a bit; we might
On Monday, February 18, 2013 8:06 PM Boszormenyi Zoltan wrote:
>On 2013-01-29 11:15 keltezéssel, Magnus Hagander írta:
>> On Thu, Jan 24, 2013 at 7:04 AM, Hari Babu wrote:
>>> On Wed, Jan 23, 2013 11:48 PM, Magnus Hagander wrote:
On Wed, Jan 23, 2013 at 10:18 AM, Hari Babu wrote:
> Test sc
Robert Haas writes:
> Well, there's this, upon which we surely have not achieved consensus:
>
> http://www.postgresql.org/message-id/ca+tgmobq6ngsxguihwqcygf0q+7y9zhnerepo3s1vswkknw...@mail.gmail.com
Sub-Transaction Handling. I fail to come up with a regression test
showing any problem here, and
Re: Andres Freund 2013-02-18 <20130218213711.ga1...@awork2.anarazel.de>
> On 2013-02-14 10:02:13 -0800, Josh Berkus wrote:
> > - Please suggest project ideas for GSOC
>
> pg_upgrade support for debian's pg_upgradecluster
We'd need Peter to be the student for that one :)
http://bugs.debian.org/cgi
54 matches
Mail list logo
