Robert Haas writes:
> It looks like 9.1 currently introduces 11 new keywords: ATTRIBUTE,
> COLLATION, EXTENSION, LABEL, NOREPLICATION, PASSING, REF, REPLICATION,
> UNLOGGED, VALIDATE, and XMLEXISTS. Aside from VALIDATE, which is
> already being discussed on another thread, are there any of these
Robert Haas wrote:
> On Fri, Mar 11, 2011 at 10:36 PM, Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> >> 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
On Fri, Mar 11, 2011 at 10:36 PM, Bruce Momjian wrote:
> Alvaro Herrera wrote:
>> 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 rele
It looks like 9.1 currently introduces 11 new keywords: ATTRIBUTE,
COLLATION, EXTENSION, LABEL, NOREPLICATION, PASSING, REF, REPLICATION,
UNLOGGED, VALIDATE, and XMLEXISTS. Aside from VALIDATE, which is
already being discussed on another thread, are there any of these that
we can/should try to get
Alvaro Herrera wrote:
> 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 c
>> Oh yeah, so if VF committed, the xlog should have been ok too, but
>> can't say the same about the shared buffers.
>
> But there was a later block that *was* written out. What was the LSN
> on that block? everything in the WAL log should have been fsynced up
> to that point when that buffer was
Looking at the code, it seems we create shared invalidation messages for
temporary table activity? Is this true? Should we be avoiding it?
I tested this by reviewing the code and checking calls to
CacheInvalidateHeapTuple(), which happens for temporary table
creation/destruction.
--
Bruce Mo
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
>
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;'
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
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
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
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
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
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 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
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 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
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 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 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 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 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
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 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
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
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 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
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 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
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 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
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
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, 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
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, 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
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 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
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 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?
>
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 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
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
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 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
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
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
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
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
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
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 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
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
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
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
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
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
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.
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, 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
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
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 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
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/
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
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
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.
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
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
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 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
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
>>> 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 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
* 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
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
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 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
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
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
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
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
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: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
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 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 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 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 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 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: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
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
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
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
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
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
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,
>>> 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
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
1 - 100 of 107 matches
Mail list logo
