On Fri, Mar 11, 2011 at 4:46 PM, Heikki Linnakangas
wrote:
>> Is this an open item for 9.1?
>
> Simon fixed it, commit b9075a6d2f9b07a00262a670dd60272904c79dce.
Oh, thanks!
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
--
Sent via pgsql-ha
contrib/pg_trgm in 9.1 becomes more attractive feature by index supports
for LIKE operators, but only alphabet and numeric characters are indexed
by default. But, we can modify KEEPONLYALNUM in the source code to
keep all characters in n-gram words.
However, the limitation and KEEPONLYALNUM are no
On Fri, Mar 11, 2011 at 5:52 PM, Itagaki Takahiro
wrote:
> contrib/pg_trgm in 9.1 becomes more attractive feature by index supports
> for LIKE operators, but only alphabet and numeric characters are indexed
> by default. But, we can modify KEEPONLYALNUM in the source code to
> keep all characters
On Fri, Mar 11, 2011 at 4:36 AM, Robert Haas wrote:
> On Tue, Mar 8, 2011 at 5:48 AM, Fujii Masao wrote:
>> On Tue, Mar 8, 2011 at 12:04 PM, Fujii Masao wrote:
>>> On Wed, Feb 9, 2011 at 5:12 PM, Magnus Hagander wrote:
I was also worried about the non-hot-standby case, but I see that the
>
Kevin Grittner wrote:
> Tom Lane wrote:
> > "Kevin Grittner" writes:
>
> >> shouldn't we be getting support for the new syntax added, so
> >> there can be a release or two supporting both?
> >
> > You mean like 9.0?
>
> Yeah, just like that.
>
> If we're going to be supporting that long t
On Fri, Mar 11, 2011 at 5:04 AM, Robert Haas wrote:
>> if ((wrote_xlog && XactSyncCommit) || forceSyncCommit || nrels > 0 ||
>> SyncRepRequested())
>>
>> Whenever synchronous_replication is TRUE, we disable synchronous_commit.
>> But, before disabling that, we should check also max_wal_send
What has been done with this report/fix?
---
Daniel Popowich wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5842
> Logged by: Daniel Popowich
> Email address: danielpopow...@gmai
Kevin Grittner wrote:
> Thom Brown wrote:
>
> > I've attached a couple minor fixes to the docs. One relating to
> > SECURITY LABEL and the other for pg_class.relpersistence
>
> relpersistence should be "char", not char.
> Oddly enough, there is a difference.
I am unsure on that one. We have
Hi,
>>> 1. Somebody inserts a bunch of new tuples into the relation, causing
>>> growth in the index.
>>
>> In case it's not obvious VACUUM FULL would do precisely that.
>
> Oh, I didn't even think about that. Yeah, that could be it, too.
Thanks a lot Greg and Robert. This theory seems very plau
On 10.03.2011 22:50, Bruce Momjian wrote:
Bruce Momjian wrote:
Has this been addressed?
I see we have with this commit:
9de3aa65f01fb51cbc725e8508ea233e4e92c46c
We fixed GiST. B-tree still has the issue that if you have a checkpoint
in the middle of an insert, and crash, you might
Hi,
maybe we should change the "1000 digits" here:
http://developer.postgresql.org/pgdocs/postgres/datatype-numeric.html#DATATYPE-NUMERIC-DECIMAL
because ISTM that up to 2^17 digits are supported (which makes more
sense than 1000).
Best regards,
Dr. Gianni Ciolli - 2ndQuadrant Italia
Postgre
Greg Smith wrote:
> Bruce Momjian wrote:
> > xlogdefs.h says:
> >
> > /*
> > * Because O_DIRECT bypasses the kernel buffers, and because we never
> > * read those buffers except during crash recovery, it is a win to use
> > * it in all cases where we sync on each write(). We could allow O_DI
On Fri, Mar 11, 2011 at 5:50 AM, Robert Haas wrote:
> On Thu, Mar 10, 2011 at 3:29 PM, Dimitri Fontaine
> wrote:
>> Robert Haas writes:
>>> they are, but there's no easy way to figure out what that means in
>>> terms of wall-clock time, which I think would be useful.
>>
>> Jan Wieck had a detail
What happened to this patch?
---
Simon Riggs wrote:
> On Sun, 2011-02-06 at 12:11 -0500, Bruce Momjian wrote:
> > Did this ever get addressed?
>
> Patch attached.
>
> Seems like the easiest fix I can come up with.
>
> > S
Robert Haas wrote:
> On Sun, Feb 6, 2011 at 11:16 AM, Bruce Momjian wrote:
> > I assume having psql support multiple -f files is not a high priority or
> > something we don't want.
>
> IIRC, nobody objected to the basic concept, and it seems useful. I
> thought we were pretty close to committing
On Fri, Mar 11, 2011 at 7:18 AM, Bruce Momjian wrote:
> What happened to this patch?
I added it to the next CommitFest. It would be reasonably to apply it
sooner, perhaps, but nobody's reviewed it. Want to volunteer?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Post
On Fri, Mar 11, 2011 at 5:34 AM, Bruce Momjian wrote:
> Document that the parenthesized VACUUM syntax is deprecated, not the
> FREEZE functionality.
The text you added here is flat-out wrong (you used "unparenthesized"
in both halves of the sentence), and it's also not as clear as the
text it rep
On Fri, Mar 11, 2011 at 7:08 AM, Fujii Masao wrote:
> On Fri, Mar 11, 2011 at 5:50 AM, Robert Haas wrote:
>> On Thu, Mar 10, 2011 at 3:29 PM, Dimitri Fontaine
>> wrote:
>>> Robert Haas writes:
they are, but there's no easy way to figure out what that means in
terms of wall-clock time,
On Fri, Mar 11, 2011 at 7:58 AM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Fri, Mar 11, 2011 at 5:34 AM, Bruce Momjian wrote:
>> > Document that the parenthesized VACUUM syntax is deprecated, not the
>> > FREEZE functionality.
>>
>> The text you added here is flat-out wrong (you used "unpar
On Fri, Mar 11, 2011 at 6:17 AM, Nikhil Sontakke
wrote:
>> VACUUM FULL - immediate shutdown - problem with recovery?
An immediate shutdown == an intentional crash. OK, so you have the
VACUUM FULL and the immediate shutdown just afterward. So we just
need to figure out what happened during recov
On Mon, Mar 7, 2011 at 8:47 PM, Fujii Masao wrote:
> On Sun, Mar 6, 2011 at 11:10 PM, Fujii Masao wrote:
>> On Sun, Mar 6, 2011 at 5:03 PM, Fujii Masao wrote:
Why does internal_flush_if_writable compute bufptr differently from
internal_flush? And shouldn't it be static?
It s
On Fri, Mar 11, 2011 at 8:14 AM, Fujii Masao wrote:
> On Mon, Mar 7, 2011 at 8:47 PM, Fujii Masao wrote:
>> On Sun, Mar 6, 2011 at 11:10 PM, Fujii Masao wrote:
>>> On Sun, Mar 6, 2011 at 5:03 PM, Fujii Masao wrote:
> Why does internal_flush_if_writable compute bufptr differently from
>
On Fri, Mar 11, 2011 at 10:02 PM, Robert Haas wrote:
>> How about sending the timestamp of last applied transaction
>> (i.e., this is the return value of pg_last_xact_replay_timestamp)
>> from the standby to the master, and reporting it in
>> pg_stat_replication? Then you can see the lag by compar
Is this still an open bug?
---
Tom Lane wrote:
> I find that pg_upgrade fails in HEAD when asked to do a 9.1-to-9.1
> upgrade of the regression database. It gets to this bit of the
> restore script:
>
> CREATE TABLE test_t
On Fri, Mar 11, 2011 at 10:18 PM, Robert Haas wrote:
>> I added this replication timeout patch into next CF.
>>
>> I explain why this feature is required for the future review;
>>
>> Without this feature, walsender might unexpectedly remain for a while when
>> the standby crashes or the network ou
Where are we on this?
---
Erik Rijkers wrote:
> On Wed, February 9, 2011 09:35, Jeff Davis wrote:
> > Updated patch.
> >
>
> The operators << >> and -|- have the following behavior with empty ranges:
>
> testdb=# selec
Kevin Grittner wrote:
> Torello Querci wrote:
>
> > I attach a path for this
>
> It's too late in the release cycle to consider this for version 9.1.
> Please add it to the open CommitFest for consideration for 9.2:
>
> https://commitfest.postgresql.org/action/commitfest_view/open
I have ad
Is this something for the next commit-fest?
---
Stephen Frost wrote:
-- Start of PGP signed section.
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Robert Haas writes:
> > > It seems there's at least one more thing to worry a
On Thu, Mar 10, 2011 at 8:12 AM, Zotov wrote:
> Hello, i have an old system where used implicit casting
> float<->integer
> numeric<->float
> numeric<->integer
>
> I want define implicit casts, but postgresql don`t know cast priority
> now postgresql have PREFERRED flag, but only flag
> I can`t d
On Fri, Mar 11, 2011 at 8:21 AM, Fujii Masao wrote:
> On Fri, Mar 11, 2011 at 10:02 PM, Robert Haas wrote:
>>> How about sending the timestamp of last applied transaction
>>> (i.e., this is the return value of pg_last_xact_replay_timestamp)
>>> from the standby to the master, and reporting it in
On Fri, Mar 11, 2011 at 3:59 AM, Fujii Masao wrote:
> On Fri, Mar 11, 2011 at 5:52 PM, Itagaki Takahiro
> wrote:
>> contrib/pg_trgm in 9.1 becomes more attractive feature by index supports
>> for LIKE operators, but only alphabet and numeric characters are indexed
>> by default. But, we can modif
* Bruce Momjian (br...@momjian.us) wrote:
> Is this something for the next commit-fest?
I already moved it there..
Thanks,
Stephen
signature.asc
Description: Digital signature
Fujii Masao wrote:
> On Fri, Mar 11, 2011 at 10:18 PM, Robert Haas wrote:
> >> I added this replication timeout patch into next CF.
> >>
> >> I explain why this feature is required for the future review;
> >>
> >> Without this feature, walsender might unexpectedly remain for a while when
> >> the
>>> VACUUM FULL - immediate shutdown - problem with recovery?
>
> An immediate shutdown == an intentional crash. OK, so you have the
> VACUUM FULL and the immediate shutdown just afterward. So we just
> need to figure out what happened during recovery.
>
Right.
>> But WAL replay should still ha
Fujii Masao writes:
> Yeah, since I like the former, I changed the wordings in the doc and
> recovery.conf.sample. What about the attached patch?
Please stop plastering the code with elog(FATAL) calls. Those are
hardly ever appropriate. In contexts where it might be reasonable
to do that, the e
On tor, 2011-03-10 at 22:45 +0100, Magnus Hagander wrote:
> On Thu, Mar 10, 2011 at 22:22, Bruce Momjian wrote:
> >
> > Added to TODO:
> >
> >Rename unix domain socket 'ident' connections to 'peer', to avoid
> >confusion with TCP 'ident'
>
> Should we consider adding "peer" as an
Gianni Ciolli writes:
> maybe we should change the "1000 digits" here:
>
> http://developer.postgresql.org/pgdocs/postgres/datatype-numeric.html#DATATYPE-NUMERIC-DECIMAL
> because ISTM that up to 2^17 digits are supported
This is incorrect. (You're confusing the number of stored digits
with
On Fri, Mar 11, 2011 at 09:38:03AM -0500, Tom Lane wrote:
> Gianni Ciolli writes:
> > maybe we should change the "1000 digits" here:
>
> >
> > http://developer.postgresql.org/pgdocs/postgres/datatype-numeric.html#DATATYPE-NUMERIC-DECIMAL
>
> > because ISTM that up to 2^17 digits are supported
FYI, this is now on the TODO list:
Increase maximum values for max_standby_streaming_delay and
log_min_duration_statement
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg01517.php
Magnus Hagander wrote:
> On Fri, Mar 4, 2011 at 15:23, Yeb Havinga wrote:
> > On 2011-02-18 11:02, Magnus Hagander wrote:
> >>
> >> Better late than never (or?), here's the final cleanup of
> >> pg_streamrecv for moving into the main distribution, per discussion
> >> back in late dec or early jan.
Removing CC to pg-docs so that Robert reads it.
Excerpts from Bruce Momjian's message of vie mar 11 08:13:20 -0300 2011:
> Kevin Grittner wrote:
> > relpersistence should be "char", not char.
> > Oddly enough, there is a difference.
>
> I am unsure on that one. We have many 'char' mentions in c
Alvaro Herrera writes:
> One idea is to rename the type to something else. We could keep "char"
> as an alias for backwards compatibility, but use the new name in system
> catalogs, and document it as the main name of the type.
We don't have type aliases...
regards, tom
I'm seeing this failure on a build machine with an old (and therefore
unusable) version of flex:
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -Wformat-security
-fno-strict-aliasing -fwrapv -I../../../src/include -D_GNU_SOURCE
-I/usr/local/include/
On 11.03.2011 17:41, Dave Page wrote:
Looks like we're missing the pre-build output from the tarball.
Yes. Tom spotted and fixed this yesterday:
commit 174f65ab00bb8de0f119a6a60d562b516ba71bba
Author: Tom Lane
Date: Thu Mar 10 00:03:26 2011 -0500
Fix some oversights in distprep and mai
Itagaki Takahiro writes:
> contrib/pg_trgm in 9.1 becomes more attractive feature by index supports
> for LIKE operators, but only alphabet and numeric characters are indexed
> by default. But, we can modify KEEPONLYALNUM in the source code to
> keep all characters in n-gram words.
> However, the
On Fri, Mar 11, 2011 at 9:15 PM, Heikki Linnakangas
wrote:
> On 11.03.2011 17:41, Dave Page wrote:
>>
>> Looks like we're missing the pre-build output from the tarball.
>
> Yes. Tom spotted and fixed this yesterday:
I really should pay more attention to the committers list. Thanks!
--
Dave Pa
On Fri, Feb 11, 2011 at 02:13:22AM -0500, Noah Misch wrote:
> Automated tests would go a long way toward building confidence that this patch
> does the right thing. Thanks to the SSI patch, we now have an in-tree test
> framework for testing interleaved transactions. The only thing it needs to be
Excerpts from Tom Lane's message of vie mar 11 12:40:50 -0300 2011:
> Alvaro Herrera writes:
> > One idea is to rename the type to something else. We could keep "char"
> > as an alias for backwards compatibility, but use the new name in system
> > catalogs, and document it as the main name of the
On Fri, 2011-03-11 at 17:45 +0200, Heikki Linnakangas wrote:
>
> On 11.03.2011 17:41, Dave Page wrote:
> > Looks like we're missing the pre-build output from the tarball.
>
> Yes. Tom spotted and fixed this yesterday:
I believe we need an alpha5 for post-alpha-4 fixes, including syncrep
ones.
Heikki Linnakangas writes:
> On 10.03.2011 22:50, Bruce Momjian wrote:
>> Bruce Momjian wrote:
>
> Has this been addressed?
>>
>> I see we have with this commit:
>>
>> 9de3aa65f01fb51cbc725e8508ea233e4e92c46c
> We fixed GiST. B-tree still has the issue that if you have a checkpoint
> in the m
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of vie mar 11 12:40:50 -0300 2011:
>> Alvaro Herrera writes:
>>> One idea is to rename the type to something else. We could keep "char"
>>> as an alias for backwards compatibility, but use the new name in system
>>> catalogs, and document
2011/3/11 Devrim GÜNDÜZ :
> On Fri, 2011-03-11 at 17:45 +0200, Heikki Linnakangas wrote:
>>
>> On 11.03.2011 17:41, Dave Page wrote:
>> > Looks like we're missing the pre-build output from the tarball.
>>
>> Yes. Tom spotted and fixed this yesterday:
>
> I believe we need an alpha5 for post-alpha-4
Excerpts from Tom Lane's message of vie mar 11 13:01:06 -0300 2011:
> Alvaro Herrera writes:
> > Excerpts from Tom Lane's message of vie mar 11 12:40:50 -0300 2011:
> >> Alvaro Herrera writes:
> >>> One idea is to rename the type to something else. We could keep "char"
> >>> as an alias for back
Robert Haas wrote:
> On Fri, Mar 11, 2011 at 5:34 AM, Bruce Momjian wrote:
> > Document that the parenthesized VACUUM syntax is deprecated, not the
> > FREEZE functionality.
>
> The text you added here is flat-out wrong (you used "unparenthesized"
> in both halves of the sentence), and it's also
On Mar 11, 2011, at 6:17 AM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Sun, Feb 6, 2011 at 11:16 AM, Bruce Momjian wrote:
>>> I assume having psql support multiple -f files is not a high priority or
>>> something we don't want.
>>
>> IIRC, nobody objected to the basic concept, and it seem
2011/3/11 Dave Page :
> 2011/3/11 Devrim GÜNDÜZ :
>> On Fri, 2011-03-11 at 17:45 +0200, Heikki Linnakangas wrote:
>>>
>>> On 11.03.2011 17:41, Dave Page wrote:
>>> > Looks like we're missing the pre-build output from the tarball.
>>>
>>> Yes. Tom spotted and fixed this yesterday:
>>
>> I believe we
On 11.03.2011 17:59, Tom Lane wrote:
Heikki Linnakangas writes:
On 10.03.2011 22:50, Bruce Momjian wrote:
Bruce Momjian wrote:
Has this been addressed?
I see we have with this commit:
9de3aa65f01fb51cbc725e8508ea233e4e92c46c
We fixed GiST. B-tree still has the issue that if you have a
On Fri, Mar 11, 2011 at 11:30 AM, David Christensen wrote:
>
> On Mar 11, 2011, at 6:17 AM, Bruce Momjian wrote:
>
>> Robert Haas wrote:
>>> On Sun, Feb 6, 2011 at 11:16 AM, Bruce Momjian wrote:
I assume having psql support multiple -f files is not a high priority or
something we don't
I know we allow people to use file system snapshots as backups, but what
happens if they are using tablespaces and they can't do the snapshots
simultaneously? If there is only one check point happening between the
first and last snapshot, would the WAL logs clean up that inconsistency
like they do
2011/3/11 Robert Haas :
> 2011/3/11 Dave Page :
>> 2011/3/11 Devrim GÜNDÜZ :
>>> On Fri, 2011-03-11 at 17:45 +0200, Heikki Linnakangas wrote:
On 11.03.2011 17:41, Dave Page wrote:
> Looks like we're missing the pre-build output from the tarball.
Yes. Tom spotted and fixed t
Twenty percent of our C files include unistd.h. Should we include
unistd.h in c.h and remove mentions of unistd.h in files that include
c.h?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be
On 11.03.2011 18:50, Bruce Momjian wrote:
Twenty percent of our C files include unistd.h. Should we include
unistd.h in c.h and remove mentions of unistd.h in files that include
c.h?
Why?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing l
Heikki Linnakangas wrote:
> On 11.03.2011 18:50, Bruce Momjian wrote:
> > Twenty percent of our C files include unistd.h. Should we include
> > unistd.h in c.h and remove mentions of unistd.h in files that include
> > c.h?
>
> Why?
Well, that is one less C include file in 151 C files, and just o
On Fri, Mar 11, 2011 at 11:50 AM, Bruce Momjian wrote:
> Twenty percent of our C files include unistd.h. Should we include
> unistd.h in c.h and remove mentions of unistd.h in files that include
> c.h?
Why?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Comp
On 11.03.2011 18:53, Bruce Momjian wrote:
Heikki Linnakangas wrote:
On 11.03.2011 18:50, Bruce Momjian wrote:
Twenty percent of our C files include unistd.h. Should we include
unistd.h in c.h and remove mentions of unistd.h in files that include
c.h?
Why?
Well, that is one less C include f
Heikki Linnakangas wrote:
> On 11.03.2011 18:53, Bruce Momjian wrote:
> > Heikki Linnakangas wrote:
> >> On 11.03.2011 18:50, Bruce Momjian wrote:
> >>> Twenty percent of our C files include unistd.h. Should we include
> >>> unistd.h in c.h and remove mentions of unistd.h in files that include
> >
On Fri, Mar 11, 2011 at 11:53 AM, Bruce Momjian wrote:
> Heikki Linnakangas wrote:
>> On 11.03.2011 18:50, Bruce Momjian wrote:
>> > Twenty percent of our C files include unistd.h. Should we include
>> > unistd.h in c.h and remove mentions of unistd.h in files that include
>> > c.h?
>>
>> Why?
>
On Fri, Mar 11, 2011 at 9:31 AM, Tom Lane wrote:
> Fujii Masao writes:
>> Yeah, since I like the former, I changed the wordings in the doc and
>> recovery.conf.sample. What about the attached patch?
>
> Please stop plastering the code with elog(FATAL) calls. Those are
> hardly ever appropriate.
On 11.03.2011 18:55, Bruce Momjian wrote:
OK, I am just asking. FYI, we already include a boatload of includes in
c.h:
#include
#include
#include
#include
#include
#ifdef HAVE_STRINGS_H
#include
#endif
#ifdef HAVE_STDINT_H
Excerpts from Heikki Linnakangas's message of vie mar 11 13:59:59 -0300 2011:
> Presumably all of these are used by something in c.h itself. At least
> strings.h is needed by memset, and stddef.h and/or stdlib.h is needed
> for size_t. I'm too lazy to check the rest, but if there are any header
On Fri, Mar 11, 2011 at 17:46, Bruce Momjian wrote:
> I know we allow people to use file system snapshots as backups, but what
> happens if they are using tablespaces and they can't do the snapshots
> simultaneously? If there is only one check point happening between the
> first and last snapshot
Magnus Hagander wrote:
> On Fri, Mar 11, 2011 at 17:46, Bruce Momjian wrote:
> > I know we allow people to use file system snapshots as backups, but what
> > happens if they are using tablespaces and they can't do the snapshots
> > simultaneously? ?If there is only one check point happening betwee
On Fri, 2011-03-11 at 08:37 -0500, Bruce Momjian wrote:
> Where are we on this?
The options are:
1. Rip out empty ranges. Several people have been skeptical of their
usefulness, but I don't recall anyone directly saying that they should
be removed. Robert Haas made the point that range types aren
Heikki Linnakangas writes:
> On 11.03.2011 17:59, Tom Lane wrote:
>> But that will be fixed during WAL replay.
> Not under the circumstances that started the original thread:
> 1. Backend splits a page
> 2. Checkpoint starts
> 3. Checkpoint runs to completion
> 4. Crash
> (5. Backend never got t
On Fri, Mar 11, 2011 at 12:37 PM, Jeff Davis wrote:
> Right now it's #3, and I lean pretty strongly toward keeping it. Without
> #3, people will get confused when fairly simple operations fail in a
> data-dependent way (at runtime). With #3, people will run into problems
> only in situations where
On 11.03.2011 19:41, Tom Lane wrote:
Heikki Linnakangas writes:
On 11.03.2011 17:59, Tom Lane wrote:
But that will be fixed during WAL replay.
Not under the circumstances that started the original thread:
1. Backend splits a page
2. Checkpoint starts
3. Checkpoint runs to completion
4. C
It has bothered me that many of our time routines use special magic
constants for time values, e.g. 24, 12, 60, etc.
The attached patch changes these magic constants to macros to clarify
the code. I would like to apply this for 9.1 as a cleanup.
--
Bruce Momjian http://momjian.us
E
On Fri, Mar 11, 2011 at 12:50 PM, Bruce Momjian wrote:
> It has bothered me that many of our time routines use special magic
> constants for time values, e.g. 24, 12, 60, etc.
>
> The attached patch changes these magic constants to macros to clarify
> the code. I would like to apply this for 9.1
Christopher Browne wrote:
> On Fri, Mar 11, 2011 at 12:50 PM, Bruce Momjian wrote:
> > It has bothered me that many of our time routines use special magic
> > constants for time values, e.g. 24, 12, 60, etc.
> >
> > The attached patch changes these magic constants to macros to clarify
> > the code
On Wed, Mar 9, 2011 at 9:58 PM, Fujii Masao wrote:
> On Thu, Mar 10, 2011 at 2:06 AM, Robert Haas wrote:
>> On Tue, Mar 8, 2011 at 10:06 AM, Fujii Masao wrote:
>>> How should the backends waiting for replication behave when
>>> synchrnous_standby_names
>>> is set to '' and the configuration file
Bruce Momjian wrote:
> Christopher Browne wrote:
> > On Fri, Mar 11, 2011 at 12:50 PM, Bruce Momjian wrote:
> > > It has bothered me that many of our time routines use special magic
> > > constants for time values, e.g. 24, 12, 60, etc.
> > >
> > > The attached patch changes these magic constants
On Fri, Mar 11, 2011 at 2:28 PM, Nikhil Sontakke
wrote:
>> I'm not sure, but I doubt it. If the VACUUM FULL committed, then the
>> WAL records should be on disk, but if the immediate shutdown happened
>> while it was still running, then the WAL records might still be in
>> wal_buffers, in which c
On Tue, Mar 8, 2011 at 4:44 PM, Tom Lane wrote:
> Add missing keywords to gram.y's unreserved_keywords list.
>
> We really need an automated check for this ... and did VALIDATE really
> need to become a keyword at all, rather than picking some other syntax
> using existing keywords?
I think we ou
Excerpts from Robert Haas's message of vie mar 11 15:59:40 -0300 2011:
> On Tue, Mar 8, 2011 at 4:44 PM, Tom Lane wrote:
> > Add missing keywords to gram.y's unreserved_keywords list.
> >
> > We really need an automated check for this ... and did VALIDATE really
> > need to become a keyword at all
On Fri, Mar 11, 2011 at 8:29 AM, Fujii Masao wrote:
>> I think we should consider making this change for 9.1. This is a real
>> wart, and it's going to become even more of a problem with sync rep, I
>> think.
>
> Yeah, that's a welcome! Please feel free to review the patch.
I discussed this with
On 11.03.2011 20:59, Robert Haas wrote:
On Tue, Mar 8, 2011 at 4:44 PM, Tom Lane wrote:
Add missing keywords to gram.y's unreserved_keywords list.
We really need an automated check for this ... and did VALIDATE really
need to become a keyword at all, rather than picking some other syntax
using
On Fri, Mar 11, 2011 at 2:39 PM, Heikki Linnakangas
wrote:
> On 11.03.2011 20:59, Robert Haas wrote:
>>
>> On Tue, Mar 8, 2011 at 4:44 PM, Tom Lane wrote:
>>>
>>> Add missing keywords to gram.y's unreserved_keywords list.
>>>
>>> We really need an automated check for this ... and did VALIDATE rea
On Fri, Mar 11, 2011 at 09:03:33AM -0500, Robert Haas wrote:
> On Fri, Mar 11, 2011 at 8:21 AM, Fujii Masao wrote:
> >
> > In that case, the last write WAL timestamp would become equal to the
> > last replay WAL timestamp. So we can see that there is no lag.
>
> Oh, I see (I think). You're talki
On Mar 11, 2011, at 1:40 PM, Robert Haas wrote:
> On Fri, Mar 11, 2011 at 2:39 PM, Heikki Linnakangas
> wrote:
>> On 11.03.2011 20:59, Robert Haas wrote:
>>>
>>> On Tue, Mar 8, 2011 at 4:44 PM, Tom Lane wrote:
Add missing keywords to gram.y's unreserved_keywords list.
We
On 03/11/2011 02:50 PM, David Christensen wrote:
On Mar 11, 2011, at 1:40 PM, Robert Haas wrote:
On Fri, Mar 11, 2011 at 2:39 PM, Heikki Linnakangas
wrote:
On 11.03.2011 20:59, Robert Haas wrote:
On Tue, Mar 8, 2011 at 4:44 PM, Tom Lane wrote:
Add missing keywords to gram.y's unreserve
Andrew Dunstan writes:
> On 03/11/2011 02:50 PM, David Christensen wrote:
>> On Mar 11, 2011, at 1:40 PM, Robert Haas wrote:
>>> ALTER CONSTRAINT ... VALID sounds like it just marks the constraint as
>>> valid. "VALIDATE CONSTRAINT" sounds like it scans and checks that the
>>> constraint is valid.
On Fri, Mar 11, 2011 at 3:00 PM, Andrew Dunstan wrote:
> On 03/11/2011 02:56 PM, Andrew Dunstan wrote:
>>
>>
>>
>> SET VALID? (c.f. SET NULL).
>
> Of course I mean SET NOT NULL.
>
>
> Anyway, the full thing would be something like
>
>
> ALTER TABLE foo SET VALID CONSTRAINT bar;
Or ALTER TABLE foo
Tom Lane wrote:
> Andrew Dunstan writes:
>> SET VALID? (c.f. SET NULL).
>
> That sounds the best so far, but maybe we should think about other
> phrases altogether (ie, not arising from the word "valid")? I
> don't have any great ideas offhand, just trying to think outside
> the box.
At the
On 03/11/2011 02:56 PM, Andrew Dunstan wrote:
SET VALID? (c.f. SET NULL).
Of course I mean SET NOT NULL.
Anyway, the full thing would be something like
ALTER TABLE foo SET VALID CONSTRAINT bar;
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
On Thu, Mar 10, 2011 at 05:51:31PM -0500, Tom Lane wrote:
> No, that's not what I'm on about. Consider
>
> (((A COLLATE X) || B) || (C COLLATE Y)) < (D COLLATE Z)
>
> (I've spelled out the parenthesization in full for clarity, but most
> of these parens could be omitted.) Is this expressi
Martijn van Oosterhout writes:
> On Thu, Mar 10, 2011 at 05:51:31PM -0500, Tom Lane wrote:
>> No, that's not what I'm on about. Consider
>>
>> (((A COLLATE X) || B) || (C COLLATE Y)) < (D COLLATE Z)
> The rules are essentially as described here:
> http://msdn.microsoft.com/en-us/library/ms17988
Heikki Linnakangas writes:
> On 11.03.2011 18:55, Bruce Momjian wrote:
>> OK, I am just asking. FYI, we already include a boatload of includes in
>> c.h:
>>
>> #include
>> #include
>> #include
>> #include
>> #include
>> #ifdef HAVE_STRINGS_H
>> #include
>> #endif
>> #ifdef HAVE_STDINT_H
>> #incl
On Thu, Mar 10, 2011 at 10:46:47PM -0500, Robert Haas wrote:
> On Thu, Mar 10, 2011 at 10:36 PM, Bruce Momjian wrote:
> > Robert Haas wrote:
> >> Back in 2006, we have this commit:
> >>
> >> commit 2b25e1169f44368c120931787628d51731b5cc8c
> >> Author: Peter Eisentraut
> >> Date: Sat Oct 7 20:59
Currently, if you create a temporary table with the ON COMMIT action of
DELETE ROWS, the table will truncated for every commit, whether there is
any data in the table or not.
I measured the overhead using this test:
$ (echo 'CREATE TEMPORARY TABLE TEST2 (x int);'; jot -b 'SELECT 1;'
Excerpts from Bruce Momjian's message of vie mar 11 00:59:03 -0300 2011:
> > At a minimum, we should probably also remove -X no-security-label and
> > -X no-unlogged-table-data, which don't exist in any released versions
> > (unless you want to count alphas). But considering that this has been
>
1 - 100 of 107 matches
Mail list logo
