On 22.06.2011 01:51, Tom Lane wrote:
I notice that the SSI code is rather heavily invested in function
declarations like this:
extern bool PageIsPredicateLocked(const Relation relation, const BlockNumber
blkno);
I find this to be poor style, and would like to see if there's any
support for get
> # Avoid bug that converts 'x =- 1' to 'x = -1'
> $source =~ s!=- !-= !g;
I haven't looked at the shell script this replaces, but is that the correct
substitution pattern? (BTW, I'm not seeing the token =- anywhere except in the
Makefile, which wouldn't be run against, no? Am I mi
Excerpts from Greg Sabino Mullane's message of mié jun 22 03:24:34 UTC 2011:
>
> Hash: RIPEMD160
>
> > Do we do enough to show which tables are db shared, e.g. pg_database? I
> > don't see any indication from psql \dS. Are our docs clear enough?
>
> I don't think \dS should be indicating such
Not sure what the normal process is for patches, but I put together a
few small patches for pg_upgrade after trying to use it earlier today
and staring a non-helpful error message before I finally figured out
what was going on.
0001 is just a simple typo fix, but didn't want to mix it in with the
On Wed, Jun 22, 2011 at 01:31:11AM -0400, Dan Ports wrote:
> Yes, I suspect it can be done better. The reason it's tricky is a lock
> ordering issue; part of releasing a SerializableXact has to be done
> while holding SerializableXactHashLock and part has to be done without
> it (because it involve
On Tue, Jun 21, 2011 at 03:01:48PM +0300, Heikki Linnakangas wrote:
> Thanks, committed.
Thanks.
> In the long term, I'm not sure this is the best way to handle this. It
> feels a bit silly to set the flag, release the SerializableXactHashLock,
> and reacquire it later to remove the transaction
I was looking at ExecSeqScan today and noticed that it invokes
PredicateLockRelation each time it's called, i.e. for each tuple
returned. Any reason we shouldn't skip that call if
rs_relpredicatelocked is already set, as in the attached patch?
That would save us a bit of overhead, since checking t
On 22 June 2011 14:01, Pavel Stehule wrote:
> ook, now is clean, so this is majority opinion.
>
> Please, can you send a final patch.
I don't have any further changes to add to Alvaro's version 3, which
is already up on the CF app.
Cheers,
BJ
--
Sent via pgsql-hackers mailing list (pgsql-hacke
2011/6/22 Brendan Jurd :
> On 22 June 2011 00:47, Tom Lane wrote:
>> Alvaro Herrera writes:
>>> Excerpts from Pavel Stehule's message of mar jun 21 00:59:44 -0400 2011:
because >>pamservice<< - is known keyword, but 'pamservice' is some
literal without any mean. You should to use a makr
On 06/21/2011 11:15 PM, Tom Lane wrote:
Andrew Dunstan writes:
Attached is a WIP possible replacement for pgindent. Instead of a shell
script invoking a mishmash of awk and sed, some of which is pretty
impenetrable, it uses a single engine (perl) to do all the pre and post
indent processing.
On Tue, Jun 21, 2011 at 6:22 PM, Peter Geoghegan wrote:
> Thanks for giving this your attention Fujii. Attached patch addresses
> your concerns.
Thanks for updating the patch! I have a few comments;
+WaitLatch(volatile Latch *latch, int wakeEvents, long timeout)
+WaitLatchOrSocket(volatile Latch
Tom Lane wrote:
> Bruce Momjian writes:
> > Discussion seems to have ended on this thread without a clear direction.
>
> I still think the right thing is to just use a non-default port number.
> That gets 90% of the benefit for 10% of the work of any other approach
> (except for the ones for whic
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Do we do enough to show which tables are db shared, e.g. pg_database? I
> don't see any indication from psql \dS. Are our docs clear enough?
I don't think \dS should be indicating such a thing. I think it's documented
well enough: if you a
Andrew Dunstan writes:
> Attached is a WIP possible replacement for pgindent. Instead of a shell
> script invoking a mishmash of awk and sed, some of which is pretty
> impenetrable, it uses a single engine (perl) to do all the pre and post
> indent processing.
Hm ... this should offer the chan
On Tue, Jun 21, 2011 at 11:04 PM, Tom Lane wrote:
> Robert Haas writes:
>> Some of the refactoring you've done here seems likely to break things,
>> because you're basically making the relation locking happen later than
>> it does not, and that's going to cause problems.
>> get_object_address_rel
Bruce Momjian writes:
> Discussion seems to have ended on this thread without a clear direction.
I still think the right thing is to just use a non-default port number.
That gets 90% of the benefit for 10% of the work of any other approach
(except for the ones for which the ratio is even worse).
Do we do enough to show which tables are db shared, e.g. pg_database? I
don't see any indication from psql \dS. Are our docs clear enough?
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be t
Robert Haas writes:
> Some of the refactoring you've done here seems likely to break things,
> because you're basically making the relation locking happen later than
> it does not, and that's going to cause problems.
> get_object_address_relobject() is a particularly egregious
> rearrangement. It
On Thu, Jun 9, 2011 at 10:27 PM, Josh Kupershmidt wrote:
> On Wed, Jun 8, 2011 at 6:36 PM, Brar Piening wrote:
>> I tried to look at everything and cover everthing but please consider that
>> this is my first review so please have a second look at it!
>
> I took a look at this as well, and I didn
On 22 June 2011 00:47, Tom Lane wrote:
> Alvaro Herrera writes:
>> Excerpts from Pavel Stehule's message of mar jun 21 00:59:44 -0400 2011:
>>> because >>pamservice<< - is known keyword, but 'pamservice' is some
>>> literal without any mean. You should to use a makro token_is_keyword
>>> more oft
2011/6/17 Shigeru Hanada :
> (2011/06/12 6:43), Noah Misch wrote:
>> On Wed, Mar 30, 2011 at 04:48:26PM -0400, Robert Haas wrote:
>>> Me neither. If making the deadlock timeout PGC_SUSET is independently
>>> useful, I don't object to doing that first, and then we can wait and
>>> see if anyone fee
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > I meant the PGPASSWORD environment variable:
> >
> >
> >PGPASSWORD
> >
> > PGPASSWORD behaves the same as the > linkend="libpq-connect-password"> connection parameter.
> > Use of this environment variable
> >
On Tue, Jun 21, 2011 at 5:50 PM, Alexey Klyukin wrote:
> On Jun 21, 2011, at 9:58 PM, Noah Misch wrote:
>> A pg_regress test needs stable output, so we would do it roughly like this:
>>
>> CREATE TEMP TABLE relstorage AS SELECT 0::regclass AS oldnode;
>> ...
>> UPDATE relstorage
Andrew Dunstan wrote:
>
> Attached is a WIP possible replacement for pgindent. Instead of a shell
> script invoking a mishmash of awk and sed, some of which is pretty
> impenetrable, it uses a single engine (perl) to do all the pre and post
> indent processing. Of course, if your regex-fu and p
On Mon, Jun 20, 2011 at 6:14 AM, Diogo Santos
wrote:
> Hi, I'm used to work with PostgreSQL on Windows but now I've moved to OS X
> and I'm having problems to create a service to auto start a new server
> (instance) of PostgreSQL.
> Firstly I used the PostgreSQL installer to create the first serve
On Mon, Jun 20, 2011 at 5:54 AM, Vlad Arkhipov wrote:
> The behaviour of date_part function is opaque for infinity intervals. For
> example
> date_part('epoch', 'infinity'::date) and date_part('year', 'infinity'::date)
> return zero but is supposed to return 'infinity',
> date_part('day', 'infinit
On Sun, Jun 19, 2011 at 11:10 AM, Kevin Grittner
wrote:
> That does seem better. Thanks.
OK, committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
On Sun, Jun 19, 2011 at 7:40 AM, Kohei KaiGai wrote:
> Sorry, the previous revision did not update regression test part
> towards the latest one.
Some of the refactoring you've done here seems likely to break things,
because you're basically making the relation locking happen later than
it does n
Attached is a WIP possible replacement for pgindent. Instead of a shell
script invoking a mishmash of awk and sed, some of which is pretty
impenetrable, it uses a single engine (perl) to do all the pre and post
indent processing. Of course, if your regex-fu and perl-fu is not up the
scratch t
On Tue, Jun 21, 2011 at 06:51:20PM -0400, Tom Lane wrote:
> I find this to be poor style, and would like to see if there's any
> support for getting rid of the "const" keywords.
I'm in favor of removing them too.
Dan
--
Dan R. K. Ports MIT CSAILhttp://drkp.net/
--
On 21 June 2011 23:51, Tom Lane wrote:
> I notice that the SSI code is rather heavily invested in function
> declarations like this:
>
> extern bool PageIsPredicateLocked(const Relation relation, const BlockNumber
> blkno);
>
> I find this to be poor style, and would like to see if there's any
>
On 21/06/11 02:39, Cédric Villemain wrote:
2011/6/20 Robert Haas:
On Mon, Jun 20, 2011 at 9:15 AM, Cédric Villemain
wrote:
The feature does not work exactly as expected because the write limit
is rounded per 8kB because we write before checking. I believe if one
write a file of 1GB in one pas
I notice that the SSI code is rather heavily invested in function
declarations like this:
extern bool PageIsPredicateLocked(const Relation relation, const BlockNumber
blkno);
I find this to be poor style, and would like to see if there's any
support for getting rid of the "const" keywords. My o
On Jun 21, 2011, at 12:41 PM, Alvaro Herrera wrote:
> On the contrary -- we should support it but not document it.
+1.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
2011/6/21 Alvaro Herrera :
> Excerpts from Pavel Stehule's message of mar jun 21 11:04:11 -0400 2011:
>> 2011/6/21 Tom Lane :
>
>> > AFAICS, this is only important in places where the syntax allows either
>> > a keyword or an identifier. If only a keyword is possible, there is no
>> > value in rej
On Jun 21, 2011, at 9:58 PM, Noah Misch wrote:
>
> A pg_regress test needs stable output, so we would do it roughly like this:
>
> CREATE TEMP TABLE relstorage AS SELECT 0::regclass AS oldnode;
> ...
> UPDATE relstorage SET oldnode =
> (SELECT relfilenode FROM pg
2011/6/21 Steve Singer :
> On 11-06-20 03:44 PM, Pavel Stehule wrote:
>
> Hello
>
> You need to update config.sgml at the same time you update this format.
> You need to append a "," after application name but before constraintName.
> As it stands the CSV log has something like:
> .nbtinsert.c:
On 11-06-14 02:52 AM, Jun Ishiduka wrote:
>> I still think that's headed in the wrong direction.
>> (http://archives.postgresql.org/pgsql-hackers/2011-05/msg01405.php)
> Please check these mails, and teach the reason for content of the wrong
> direction.
> (http://archives.postgresql.org/pgsql-hac
>> 1. Obviously the '@>' has to be used in order to let use the GiST index.
>> Why is the '->' operator not supported by GiST ('->' is actually
>> mentioned in all examples of the doc.)?
There's no way to make the planner recognize something like
(col->'foo' = 'bar')
as being an indexable con
On Sun, Jun 19, 2011 at 8:08 PM, Robert Haas wrote:
> On Sun, Jun 19, 2011 at 11:04 AM, Jeff Shanab wrote:
>> I am wondering If I am missing something obvious. If not, I have a
>> suggestion for plpgsql.
>>
>> Stored procedures can accept rows.
>>
>> Libpq can receive rows (PQResult).
>>
>> Would
On 11-06-20 03:44 PM, Pavel Stehule wrote:
Hello
You need to update config.sgml at the same time you update this format.
You need to append a "," after application name but before constraintName.
As it stands the CSV log has something like:
.nbtinsert.c:433","psql""a_pkey","public","a","a"
On Tue, Jun 21, 2011 at 06:31:44PM +0300, Alexey Klyukin wrote:
> Here is my review of this patch.
Thanks!
> The patch applies cleanly to the HEAD, produces no additional warnings. It
> doesn't include additional regression tests. One can include a test, using the
> commands like the ones includ
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of mar jun 21 11:06:22 -0400 2011:
>> Please note that this position should not be regarded as support for
>> Simon's proposed patch. I still think the right decision is to revert
>> the ALTER TABLE feature, mainly because I do not believe
Excerpts from Tom Lane's message of mar jun 21 11:06:22 -0400 2011:
> Please note that this position should not be regarded as support for
> Simon's proposed patch. I still think the right decision is to revert
> the ALTER TABLE feature, mainly because I do not believe this is the
> last bug in i
On Tue, Jun 21, 2011 at 01:07:17PM -0400, Robert Haas wrote:
> On Mon, Jun 20, 2011 at 5:42 PM, David Fetter wrote:
> > I noticed that we have some nice new speed optimizations (more
> > properly, de-pessimizations) for partitioned tables in 9.1.
>
> /me sticks tongue out at dfetter.
>
> > Anybo
Excerpts from Robert Haas's message of mar jun 21 09:40:16 -0400 2011:
> On Mon, Jun 20, 2011 at 6:55 PM, Simon Riggs wrote:
> > I agree the scope for RELOID errors increased with my 9.1 patch. I'm
> > now happy with the locking patch (attached), which significantly
> > reduces the scope - back to
On Mon, Jun 20, 2011 at 5:42 PM, David Fetter wrote:
> I noticed that we have some nice new speed optimizations (more
> properly, de-pessimizations) for partitioned tables in 9.1.
/me sticks tongue out at dfetter.
> Anybody care to look over the table partitioning stuff on the wiki and
> check i
Excerpts from Pavel Stehule's message of mar jun 21 11:04:11 -0400 2011:
> 2011/6/21 Tom Lane :
> > AFAICS, this is only important in places where the syntax allows either
> > a keyword or an identifier. If only a keyword is possible, there is no
> > value in rejecting it because it's quoted. An
Hi,
On Jun 19, 2011, at 2:10 PM, Noah Misch wrote:
> On Sat, Jun 18, 2011 at 11:32:20PM -0400, Robert Haas wrote:
>> On Sat, Jun 18, 2011 at 11:12 PM, Robert Haas wrote:
>>> On Sat, Jun 18, 2011 at 11:06 PM, Noah Misch wrote:
On Sat, Jun 18, 2011 at 10:57:13PM -0400, Robert Haas wrote:
>>>
Excerpts from Magnus Hagander's message of mar jun 21 11:01:58 -0400 2011:
> On Tue, Jun 21, 2011 at 15:36, Alvaro Herrera
> wrote:
> > If git submodules are so cool that we still want to use them, maybe we
> > still can -- can a submodule be submodule of more than one module? If
> > so, we coul
Simon Riggs writes:
> On Mon, Jun 20, 2011 at 10:56 PM, Tom Lane wrote:
>> The ALTER TABLE patch
>> has greatly expanded the scope of the issue, and that *is* a regression
>> compared to prior releases.
> I agree the scope for RELOID errors increased with my 9.1 patch. I'm
> now happy with the l
Robert Haas writes:
> On Mon, Jun 20, 2011 at 5:56 PM, Tom Lane wrote:
>> Yeah. This behavior has been there since day zero, and there have been
>> very few complaints about it. But note that there's only a risk for
>> pg_class updates, not any other catalog, and there is exactly one kind
>> of
2011/6/21 Tom Lane :
> Alvaro Herrera writes:
>> Excerpts from Pavel Stehule's message of mar jun 21 00:59:44 -0400 2011:
>>> because >>pamservice<< - is known keyword, but 'pamservice' is some
>>> literal without any mean. You should to use a makro token_is_keyword
>>> more often.
>
>> Yeah, I wo
On Tue, Jun 21, 2011 at 15:36, Alvaro Herrera
wrote:
> Excerpts from Magnus Hagander's message of mar jun 21 07:36:05 -0400 2011:
>> On Tue, Jun 21, 2011 at 10:20, Michael Meskes wrote:
>> > On Mon, Jun 20, 2011 at 04:44:20PM -0400, Tom Lane wrote:
>> >> My recollection is that the current setup
Alvaro Herrera writes:
> Excerpts from Pavel Stehule's message of mar jun 21 00:59:44 -0400 2011:
>> because >>pamservice<< - is known keyword, but 'pamservice' is some
>> literal without any mean. You should to use a makro token_is_keyword
>> more often.
> Yeah, I wondered about this too (same w
On Tue, Jun 21, 2011 at 10:15:50AM -0400, Alvaro Herrera wrote:
> Excerpts from Pavel Stehule's message of mar jun 21 10:04:26 -0400 2011:
> > 2011/6/21 Alvaro Herrera :
> > > Excerpts from Pavel Stehule's message of mar jun 21 00:59:44 -0400 2011:
> > >
> > >> yes - it has a sense. Quoting changes
2011/6/21 Alvaro Herrera :
> Excerpts from Pavel Stehule's message of mar jun 21 10:04:26 -0400 2011:
>> 2011/6/21 Alvaro Herrera :
>> > Excerpts from Pavel Stehule's message of mar jun 21 00:59:44 -0400 2011:
>> >
>> >> yes - it has a sense. Quoting changes sense from keyword to literal.
>> >> But
Excerpts from Pavel Stehule's message of mar jun 21 10:04:26 -0400 2011:
> 2011/6/21 Alvaro Herrera :
> > Excerpts from Pavel Stehule's message of mar jun 21 00:59:44 -0400 2011:
> >
> >> yes - it has a sense. Quoting changes sense from keyword to literal.
> >> But then I see a significant inconsis
2011/6/21 Alvaro Herrera :
> Excerpts from Pavel Stehule's message of mar jun 21 00:59:44 -0400 2011:
>
>> yes - it has a sense. Quoting changes sense from keyword to literal.
>> But then I see a significant inconsistency - every know keywords
>> should be only tokens.
>>
>> else if (strcmp
Excerpts from Pavel Stehule's message of mar jun 21 00:59:44 -0400 2011:
> yes - it has a sense. Quoting changes sense from keyword to literal.
> But then I see a significant inconsistency - every know keywords
> should be only tokens.
>
> else if (strcmp(token, "pamservice") == 0)
> -
On Mon, Jun 20, 2011 at 6:55 PM, Simon Riggs wrote:
> I agree the scope for RELOID errors increased with my 9.1 patch. I'm
> now happy with the locking patch (attached), which significantly
> reduces the scope - back to the original error scope, in my testing.
>
> I tried to solve both, but I thin
On Mon, Jun 20, 2011 at 5:56 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Jun 19, 2011 at 5:13 PM, Simon Riggs wrote:
>>> We scan pg_class in two ways: to rebuild a relcache entry based on a
>>> relation's oid (easy fix). We also scan pg_class to resolve the name
>>> to oid mapping. The
Excerpts from Magnus Hagander's message of mar jun 21 07:36:05 -0400 2011:
> On Tue, Jun 21, 2011 at 10:20, Michael Meskes wrote:
> > On Mon, Jun 20, 2011 at 04:44:20PM -0400, Tom Lane wrote:
> >> My recollection is that the current setup was created mainly so that
> >> translators wouldn't need t
On Tue, Jun 21, 2011 at 01:36:05PM +0200, Magnus Hagander wrote:
> AFAIK (but I could be wrong), git submodules requires the files to be
> in *one* subdirectory. Our .po files are distributed all across the
> backend. So we'd have to make (and backpatch) som rather large changes
> in how these thin
On 21.06.2011 05:18, Dan Ports wrote:
The first patch addresses this bug by re-adding SXACT_FLAG_ROLLED_BACK,
in a more limited form than its previous incarnation.
We need to be able to distinguish transactions that have already
called ReleasePredicateLocks and are thus eligible for cleanup from
On Jun 20, 2011, at 6:22 PM, Florian Pflug wrote:
> On Jun20, 2011, at 17:02 , Alexey Klyukin wrote:
>>
>> I don't think it has changed at all. Previously, we did goto cleanup_list (or
>> cleanup_exit in ParseConfigFp) right after the first error, no matter whether
>> that was a postmaster or it
On Tue, Jun 21, 2011 at 10:20, Michael Meskes wrote:
> On Mon, Jun 20, 2011 at 04:44:20PM -0400, Tom Lane wrote:
>> My recollection is that the current setup was created mainly so that
>> translators wouldn't need to be given commit privileges on the main
>> repo. Giving them a separate repo to w
Hi!
On Tue, Jun 21, 2011 at 12:04 PM, Stefan Keller wrote:
> 1. Obviously the '@>' has to be used in order to let use the GiST index.
> Why is the '->' operator not supported by GiST ('->' is actually
> mentioned in all examples of the doc.)?
>
I believe it's an architecture problem. You actual
Hi!
I've created section about testing in project wiki page:
http://wiki.postgresql.org/wiki/Fast_GiST_index_build_GSoC_2011#Testing_results
Do you have any notes about table structure?
As you can see I found that CPU usage might be much higher
with gist_trgm_ops. I believe it's due to relatively
Thanks for giving this your attention Fujii. Attached patch addresses
your concerns.
On 20 June 2011 05:53, Fujii Masao wrote:
> 'hifd' should be initialized to 'selfpipe_readfd' before the above
> 'if' block. Otherwise,
> 'hifd = postmaster_alive_fds[POSTMASTER_FD_WATCH]' might have no effect.
On Mon, 2011-06-20 at 13:43 -0400, Tom Lane wrote:
> The other viable alternative seems to be to require those two properties
> (btree opclass and collation) to be part of a specific range type
> definition. The complaint about that seemed to be that we couldn't
> infer an ANYRANGE type given only
On Mon, 2011-06-20 at 12:54 -0700, Darren Duncan wrote:
> That DOMAIN-based solution ostensibly sounds like a good one then, under the
> circumstances.
It's not bad from a theoretical standpoint, but it does require some
extra type annotation, which is not really the "SQL way".
> What I *don't
On Mon, Jun 20, 2011 at 04:44:20PM -0400, Tom Lane wrote:
> My recollection is that the current setup was created mainly so that
> translators wouldn't need to be given commit privileges on the main
> repo. Giving them a separate repo to work in might be all right, but
> of course whoever does the
Hi,
We did a benchmark comparing a Key-Value-Pairs stored as EAV db schema
versus hstore. The results are promising in favor of hstore but there are some
question which remain.
1. Obviously the '@>' has to be used in order to let use the GiST index.
Why is the '->' operator not supported by GiST
74 matches
Mail list logo
