On Fri, Mar 11, 2011 at 4:46 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
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
On Fri, Mar 11, 2011 at 5:52 PM, Itagaki Takahiro
itagaki.takah...@gmail.com 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
On Fri, Mar 11, 2011 at 4:36 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Mar 8, 2011 at 5:48 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Mar 8, 2011 at 12:04 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Feb 9, 2011 at 5:12 PM, Magnus Hagander mag...@hagander.net wrote:
Kevin Grittner wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov 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
On Fri, Mar 11, 2011 at 5:04 AM, Robert Haas robertmh...@gmail.com 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
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...@gmail.com
Kevin Grittner wrote:
Thom Brown t...@linux.com 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 typechar/type, not typechar/type.
Oddly enough, there is a difference.
I am unsure
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 plausible. VF
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
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
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_DIRECT
*
On Fri, Mar 11, 2011 at 5:50 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Mar 10, 2011 at 3:29 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com writes:
they are, but there's no easy way to figure out what that means in
terms of wall-clock time,
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.
Simon
Robert Haas wrote:
On Sun, Feb 6, 2011 at 11:16 AM, Bruce Momjian br...@momjian.us 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
On Fri, Mar 11, 2011 at 7:18 AM, Bruce Momjian br...@momjian.us 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
On Fri, Mar 11, 2011 at 5:34 AM, Bruce Momjian br...@momjian.us 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
On Fri, Mar 11, 2011 at 7:08 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, Mar 11, 2011 at 5:50 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Mar 10, 2011 at 3:29 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com writes:
they are, but there's
On Fri, Mar 11, 2011 at 7:58 AM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Fri, Mar 11, 2011 at 5:34 AM, Bruce Momjian br...@momjian.us wrote:
Document that the parenthesized VACUUM syntax is deprecated, not the
FREEZE functionality.
The text you added here is flat-out
On Fri, Mar 11, 2011 at 6:17 AM, Nikhil Sontakke
nikhil.sonta...@enterprisedb.com 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
On Mon, Mar 7, 2011 at 8:47 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Sun, Mar 6, 2011 at 11:10 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Sun, Mar 6, 2011 at 5:03 PM, Fujii Masao masao.fu...@gmail.com wrote:
Why does internal_flush_if_writable compute bufptr differently from
On Fri, Mar 11, 2011 at 8:14 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Mar 7, 2011 at 8:47 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Sun, Mar 6, 2011 at 11:10 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Sun, Mar 6, 2011 at 5:03 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, Mar 11, 2011 at 10:02 PM, Robert Haas robertmh...@gmail.com 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
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_tbl2
On Fri, Mar 11, 2011 at 10:18 PM, Robert Haas robertmh...@gmail.com 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
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=# select
Kevin Grittner wrote:
Torello Querci tque...@gmail.com 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
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 robertmh...@gmail.com writes:
It seems there's at least one more
On Thu, Mar 10, 2011 at 8:12 AM, Zotov zo...@oe-it.ru 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
On Fri, Mar 11, 2011 at 8:21 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, Mar 11, 2011 at 10:02 PM, Robert Haas robertmh...@gmail.com 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
On Fri, Mar 11, 2011 at 3:59 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, Mar 11, 2011 at 5:52 PM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
contrib/pg_trgm in 9.1 becomes more attractive feature by index supports
for LIKE operators, but only alphabet and numeric characters
* 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 robertmh...@gmail.com 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
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 have
Fujii Masao masao.fu...@gmail.com 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
On tor, 2011-03-10 at 22:45 +0100, Magnus Hagander wrote:
On Thu, Mar 10, 2011 at 22:22, Bruce Momjian br...@momjian.us wrote:
Added to TODO:
Rename unix domain socket 'ident' connections to 'peer', to avoid
confusion with TCP 'ident'
Should we consider adding peer as
Gianni Ciolli gianni.cio...@2ndquadrant.it 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
On Fri, Mar 11, 2011 at 09:38:03AM -0500, Tom Lane wrote:
Gianni Ciolli gianni.cio...@2ndquadrant.it 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
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 yebhavi...@gmail.com 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
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 typechar/type, not typechar/type.
Oddly enough, there is a difference.
I am unsure on that one. We have many 'char'
Alvaro Herrera alvhe...@commandprompt.com 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...
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
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 t...@sss.pgh.pa.us
Date: Thu Mar 10 00:03:26 2011 -0500
Fix some oversights
Itagaki Takahiro itagaki.takah...@gmail.com 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
On Fri, Mar 11, 2011 at 9:15 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
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 alvhe...@commandprompt.com 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
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 heikki.linnakan...@enterprisedb.com 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
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Tom Lane's message of vie mar 11 12:40:50 -0300 2011:
Alvaro Herrera alvhe...@commandprompt.com 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
2011/3/11 Devrim GÜNDÜZ dev...@gunduz.org:
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
Excerpts from Tom Lane's message of vie mar 11 13:01:06 -0300 2011:
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Tom Lane's message of vie mar 11 12:40:50 -0300 2011:
Alvaro Herrera alvhe...@commandprompt.com writes:
One idea is to rename the type to something else. We
Robert Haas wrote:
On Fri, Mar 11, 2011 at 5:34 AM, Bruce Momjian br...@momjian.us 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
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 br...@momjian.us 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
2011/3/11 Dave Page dp...@pgadmin.org:
2011/3/11 Devrim GÜNDÜZ dev...@gunduz.org:
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:
On 11.03.2011 17:59, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com 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
On Fri, Mar 11, 2011 at 11:30 AM, David Christensen da...@endpoint.com 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 br...@momjian.us wrote:
I assume having psql support multiple -f files is not a high priority or
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
2011/3/11 Robert Haas robertmh...@gmail.com:
2011/3/11 Dave Page dp...@pgadmin.org:
2011/3/11 Devrim GÜNDÜZ dev...@gunduz.org:
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.
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 br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for
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
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 one
On Fri, Mar 11, 2011 at 11:50 AM, Bruce Momjian br...@momjian.us 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
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
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
c.h?
Why?
On Fri, Mar 11, 2011 at 11:53 AM, Bruce Momjian br...@momjian.us 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 t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com 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.
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:
#includestdio.h
#includestdlib.h
#includestring.h
#includestddef.h
#includestdarg.h
#ifdef HAVE_STRINGS_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 br...@momjian.us 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
Magnus Hagander wrote:
On Fri, Mar 11, 2011 at 17:46, Bruce Momjian br...@momjian.us 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
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
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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.
On Fri, Mar 11, 2011 at 12:37 PM, Jeff Davis pg...@j-davis.com 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
On 11.03.2011 19:41, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com 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
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 br...@momjian.us
On Fri, Mar 11, 2011 at 12:50 PM, Bruce Momjian br...@momjian.us 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
Christopher Browne wrote:
On Fri, Mar 11, 2011 at 12:50 PM, Bruce Momjian br...@momjian.us 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
On Wed, Mar 9, 2011 at 9:58 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Mar 10, 2011 at 2:06 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Mar 8, 2011 at 10:06 AM, Fujii Masao masao.fu...@gmail.com wrote:
How should the backends waiting for replication behave when
Bruce Momjian wrote:
Christopher Browne wrote:
On Fri, Mar 11, 2011 at 12:50 PM, Bruce Momjian br...@momjian.us 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
On Fri, Mar 11, 2011 at 2:28 PM, Nikhil Sontakke
nikhil.sonta...@enterprisedb.com 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
On Tue, Mar 8, 2011 at 4:44 PM, Tom Lane t...@sss.pgh.pa.us 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?
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 t...@sss.pgh.pa.us 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
On Fri, Mar 11, 2011 at 8:29 AM, Fujii Masao masao.fu...@gmail.com 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
On 11.03.2011 20:59, Robert Haas wrote:
On Tue, Mar 8, 2011 at 4:44 PM, Tom Lanet...@sss.pgh.pa.us 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
On Fri, Mar 11, 2011 at 2:39 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 11.03.2011 20:59, Robert Haas wrote:
On Tue, Mar 8, 2011 at 4:44 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Add missing keywords to gram.y's unreserved_keywords list.
We really need an automated
On Fri, Mar 11, 2011 at 09:03:33AM -0500, Robert Haas wrote:
On Fri, Mar 11, 2011 at 8:21 AM, Fujii Masao masao.fu...@gmail.com 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).
On Mar 11, 2011, at 1:40 PM, Robert Haas wrote:
On Fri, Mar 11, 2011 at 2:39 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 11.03.2011 20:59, Robert Haas wrote:
On Tue, Mar 8, 2011 at 4:44 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Add missing keywords to gram.y's
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
heikki.linnakan...@enterprisedb.com wrote:
On 11.03.2011 20:59, Robert Haas wrote:
On Tue, Mar 8, 2011 at 4:44 PM, Tom
Andrew Dunstan and...@dunslane.net 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
On Fri, Mar 11, 2011 at 3:00 PM, Andrew Dunstan aduns...@postgresql.org 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
Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net 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
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
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 expression
Martijn van Oosterhout klep...@svana.org 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:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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:
#includestdio.h
#includestdlib.h
#includestring.h
#includestddef.h
#includestdarg.h
#ifdef
On Thu, Mar 10, 2011 at 10:46:47PM -0500, Robert Haas wrote:
On Thu, Mar 10, 2011 at 10:36 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
Back in 2006, we have this commit:
commit 2b25e1169f44368c120931787628d51731b5cc8c
Author: Peter Eisentraut pete...@gmx.net
Date:
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
