On Tue, Mar 08, 2011 at 08:52:41PM -0500, Tom Lane wrote:
> Another interesting item ... I see that you added a collation field to
> TypeName, apparently on the grounds that the SQL spec includes collation
> in . However, it seems to me that that is nonsense up with
> which we should not put. is
On 10.03.2011 06:54, Tom Lane wrote:
Somebody needs to brush up their flex-fu:
make[1]: Entering directory `/home/postgres/pgsql/src/test/isolation'
/usr/local/bin/bison -o specparse.c specparse.y
/usr/local/bin/flex -o'specscanner.c' specscanner.l
specscanner.l:85: warning, -s option given bu
On Wed, Mar 09, 2011 at 10:57:53PM -0500, Robert Haas wrote:
> On Wed, Mar 9, 2011 at 7:32 PM, David Fetter wrote:
> > On Wed, Mar 09, 2011 at 07:05:19PM -0500, Gurjeet Singh wrote:
> >> Good question, I hadn't thought of that either, and thinking
> >> about it a bit I think we'd want to keep the
Somebody needs to brush up their flex-fu:
make[1]: Entering directory `/home/postgres/pgsql/src/test/isolation'
/usr/local/bin/bison -o specparse.c specparse.y
/usr/local/bin/flex -o'specscanner.c' specscanner.l
specscanner.l:85: warning, -s option given but default rule can be matched
make[1]:
Thom Brown wrote:
> On 7 March 2011 22:31, Robert Haas wrote:
> > On Mon, Mar 7, 2011 at 6:16 AM, Thom Brown wrote:
> >> On 7 March 2011 15:27, Thom Brown wrote:
> >>> I've attached a small patch with a bit of clarification and a typo fix
> >>> in the synchronous_standby_names parameter info.
>
Itagaki Takahiro writes:
> I found trivial mistakes in the recently added files.
> Will they fixed by some automated batches, or by manual?
> - "Copyright (c) xxx-*2010*, PostgreSQL Global Development Group"
> in pg_collation.h, pg_foreign_table.h, basebackup.h, syncrep.h,
> pg_backup_directo
On Thu, Mar 10, 2011 at 12:03 AM, Simon Riggs wrote:
> On Wed, 2011-03-09 at 15:37 +0100, Yeb Havinga wrote:
>
>> The current situation is definately unsafe because it forces people
>> that are in this state to do a fast shutdown.. but that fails as well,
>> so they are only left with immediate.
Bruce Momjian writes:
> Michael Meskes wrote:
>> Added new version of ecpg's parser generator script. This one was written by
>> Andy Colson .
> Uh, why are we not just replacing the old script and allowing git to
> preserve the old version?
Yeah, I was wondering that too. There seems no very g
On Thu, Mar 10, 2011 at 12:55, Robert Haas wrote:
> On Wed, Mar 9, 2011 at 8:33 PM, Itagaki Takahiro
> wrote:
>> I found trivial mistakes in the recently added files.
>> Will they fixed by some automated batches, or by manual?
> I think these should be fixed manually. The first might eventually
On Wed, Mar 9, 2011 at 7:32 PM, David Fetter wrote:
> On Wed, Mar 09, 2011 at 07:05:19PM -0500, Gurjeet Singh wrote:
>> Good question, I hadn't thought of that either, and thinking about
>> it a bit I think we'd want to keep the current behaviour of \i and
>> provide new behaviour using a new comm
On Wed, Mar 9, 2011 at 8:33 PM, Itagaki Takahiro
wrote:
> I found trivial mistakes in the recently added files.
> Will they fixed by some automated batches, or by manual?
>
> - "Copyright (c) xxx-*2010*, PostgreSQL Global Development Group"
> in pg_collation.h, pg_foreign_table.h, basebackup.h, s
On Wed, Mar 9, 2011 at 10:07 PM, Andrew Dunstan wrote:
>
> I agree there's a good case for the new feature. I think someone mentioned
> tab completion upthread, and that doesn't make so much sense to me. This
> only makes sense nested in a script - in fact if it's not called from inside
> an incl
On 03/09/2011 09:36 PM, Gurjeet Singh wrote:
If we folded \ir into \i then what would you want `\i 1.sql` to do?
Read 1.sql from $HOME or the one that is main.sql's sibling.
Should stuff break when it has a legitimately accessible path in it
just because that path is relative?
Give
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 is reloaded? Now they keep
>> waiting for the ACK from th
On Wed, Mar 9, 2011 at 7:32 PM, David Fetter wrote:
> On Wed, Mar 09, 2011 at 07:05:19PM -0500, Gurjeet Singh wrote:
> > Good question, I hadn't thought of that either, and thinking about
> > it a bit I think we'd want to keep the current behaviour of \i and
> > provide new behaviour using a new
Simon Riggs wrote:
> On Fri, 2011-03-04 at 23:15 +0900, Fujii Masao wrote:
>
> > postgres=# SELECT application_name, state, sync_priority, sync_state
> > FROM pg_stat_replication;
> > application_name | state | sync_priority | sync_state
> > --+---+---+
On Thu, Mar 10, 2011 at 2:00 AM, Robert Haas wrote:
> On Wed, Mar 9, 2011 at 6:11 AM, Fujii Masao wrote:
>> The attached patch updates replication/README to reflect current
>> walsender/walreceiver behavior. It doesn't include any description
>> about sync rep. That would need to be added later.
I found trivial mistakes in the recently added files.
Will they fixed by some automated batches, or by manual?
- "Copyright (c) xxx-*2010*, PostgreSQL Global Development Group"
in pg_collation.h, pg_foreign_table.h, basebackup.h, syncrep.h,
pg_backup_directory.c and auth_delay.c.
- "IDENTIFICA
Tom Lane wrote:
> Alvaro Herrera writes:
> > I admit I have no idea why these guys seem to run into wraparound
> > problems so much.
>
> > On the other hand, I'm not sure that it would work to try to checkpoint
> > "during" vacuum, because the backend is in a transaction. Maybe it
> > would work
Excerpts from Nikhil Sontakke's message of mié mar 09 20:28:19 -0300 2011:
> While I rummage around the code more, does anyone have any theories on
> the below?
>
> "Other peculiarity in the index file is that we found a lot of zeroed
> out pages. Blocks from #279 to #518 are all completely zeroe
On Wed, Mar 09, 2011 at 07:05:19PM -0500, Gurjeet Singh wrote:
> Good question, I hadn't thought of that either, and thinking about
> it a bit I think we'd want to keep the current behaviour of \i and
> provide new behaviour using a new command.
>
> Say when we are processing a pretty nested file
>
> What does stat say for the index data file? Are the Size and Blocks
> values the same (modulo block size)? Or are these blocks actually not
> allocated?
>
stat 58401
File: `58401'
Size: 4300800 Blocks: 8400 IO Block: 4096 regular file
Device: 801h/2049d Inode: 13901264
On Wed, Mar 9, 2011 at 11:28 PM, Nikhil Sontakke
wrote:
> "Other peculiarity in the index file is that we found a lot of zeroed
> out pages. Blocks from #279 to #518 are all completely zeroed out
> without any signs of even a page header. Any ideas on how we can get
> so many zeroed out blocks? Ap
Good question, I hadn't thought of that either, and thinking about it a bit
I think we'd want to keep the current behaviour of \i and provide new
behaviour using a new command.
Say when we are processing a pretty nested file after multiple \ir commands,
a \i in any of those files should look for
On 3/9/11 10:11 AM, Bruce Momjian wrote:
> If you are storing xml in an xml column just to get it
>> validated, and doing no processing in the DB, then you'd probably
>> prefer our current representation. If you want to build functional
>> indexes on xpath expressions, and then run queries that ex
Hi,
>>> Blocks 519 to 521 are DELETED. They do not have the LEAF flag set,
>>> meaning they could be internal pages, but that is strange since ROOT
>>> page is at level 1. Also importantly their next XID is set FrozenXid,
>>> meaning VACUUM FULL was at play. Maybe due to deletes, we reduced the
>>
New version:
- adds documentation
- adds category RESOURCES_DISK
temp-files-v2.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
db1=# create table t1 (f1 text collate "aa_DJ.utf8",
f2 text collate "an_ES.utf8" );
CREATE TABLE
db1=# select f1 < f2 from t1;
ERROR: collation mismatch between implicit collations "aa_DJ.utf8" and
"an_ES.utf8"
LINE 1: select f1 < f2 from t1;
^
HINT: You can override the c
On 03/09/2011 08:21 PM, Yeb Havinga wrote:
> On 2011-03-09 19:30, Robert Haas wrote:
>> On Wed, Mar 9, 2011 at 1:11 PM, Bruce Momjian wrote:
>>
>>> Robert Haas wrote:
>>>
On Mon, Feb 28, 2011 at 10:30 AM, Tom Lane wrote:
> Well, in principle we could allow them
So I was moving some error checks around and all of a sudden the
regression tests blew up on me, with lots of errors about how type X
didn't support collations (which indeed it didn't). After some
investigation I realized what should have been apparent much earlier:
the collations patch is trying
Being able to include relative paths is a really great feature, but
should it have a UI (well, API) distinct from fixed-path includes? My
first instinct is that it shouldn't, but I haven't really thought it
through thoroughly.
Cheers,
David (the tough coughs as he ploughs the dough)
On Tue, Mar 0
Robert Treat wrote:
> On Mon, Feb 28, 2011 at 3:42 AM, Magnus Hagander wrote:
> > On Mon, Feb 28, 2011 at 06:21, Tom Lane wrote:
> >> Robert Treat writes:
> >>> Did anything ever come of this discussion?
> >>
> >> I think it's a TODO --- nothing done about it as yet, AFAIR.
> >>
> >>> On one of
On 2011-03-09 19:30, Robert Haas wrote:
On Wed, Mar 9, 2011 at 1:11 PM, Bruce Momjian wrote:
Robert Haas wrote:
On Mon, Feb 28, 2011 at 10:30 AM, Tom Lane wrote:
Well, in principle we could allow them to work on both, just the same
way that (for instance) "+" is a standardized operator but w
On Wed, Mar 9, 2011 at 12:56 PM, Magnus Hagander wrote:
> Time will take care of that for you. You just have a coffee and wait...
Time seems to have done the trick (though my coffee would be getting
cold by now). I now see it at:
http://www.postgresql.org/ftp/source/v9.1alpha4/
--
Robert Haa
On Wed, Mar 9, 2011 at 1:11 PM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Mon, Feb 28, 2011 at 10:30 AM, Tom Lane wrote:
>> > Well, in principle we could allow them to work on both, just the same
>> > way that (for instance) "+" is a standardized operator but works on more
>> > than one dat
Robert Haas wrote:
> On Mon, Feb 28, 2011 at 10:30 AM, Tom Lane wrote:
> > Well, in principle we could allow them to work on both, just the same
> > way that (for instance) "+" is a standardized operator but works on more
> > than one datatype. ?But I agree that the prospect of two parallel types
On Wed, Mar 9, 2011 at 18:53, Robert Haas wrote:
> On Wed, Mar 9, 2011 at 12:30 PM, Kevin Grittner
> wrote:
>> Robert Haas wrote:
>>
>>> Files now up at:
>>>
>>> http://developer.postgresql.org/~rhaas/
>>
>> As an initial sanity test I downloaded the bz2 version and its md5
>> file. The md5sum
On Wed, Mar 9, 2011 at 12:30 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> Files now up at:
>>
>> http://developer.postgresql.org/~rhaas/
>
> As an initial sanity test I downloaded the bz2 version and its md5
> file. The md5sum checked out and this all ran as expected:
>
> tar -xjf postgre
Robert Haas wrote:
> Files now up at:
>
> http://developer.postgresql.org/~rhaas/
As an initial sanity test I downloaded the bz2 version and its md5
file. The md5sum checked out and this all ran as expected:
tar -xjf postgresql-9.1alpha4.tar.bz2
cd postgresql-9.1alpha4/
./configure --prefi
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 is reloaded? Now they keep
> waiting for the ACK from the
> standby. But I think that it's more natural for them to
On Wed, Mar 9, 2011 at 6:11 AM, Fujii Masao wrote:
> The attached patch updates replication/README to reflect current
> walsender/walreceiver behavior. It doesn't include any description
> about sync rep. That would need to be added later.
Hrm. What about this hunk?
-Each walsender allocates an
On Wed, Mar 9, 2011 at 10:43 AM, Robert Haas wrote:
> On Wed, Mar 9, 2011 at 10:35 AM, Peter Eisentraut wrote:
>> On ons, 2011-03-09 at 10:12 -0500, Robert Haas wrote:
>>> developer.postgresql.org apparently hates me. After waiting an
>>> insanely long time to copy over the exported tarball to t
On Wed, Mar 9, 2011 at 10:35 AM, Peter Eisentraut wrote:
> On ons, 2011-03-09 at 10:12 -0500, Robert Haas wrote:
>> developer.postgresql.org apparently hates me. After waiting an
>> insanely long time to copy over the exported tarball to that machine,
>
> I run the export on d.p.o.
I can see why
On ons, 2011-03-09 at 10:12 -0500, Robert Haas wrote:
> developer.postgresql.org apparently hates me. After waiting an
> insanely long time to copy over the exported tarball to that machine,
I run the export on d.p.o.
> As Magnus pointed out to me on IM, there must be a usable version of
> autoc
Due to backbranch packaging, and having to support several different
versions of autoconf as a results, its a bit more confusing ...
'k, normally it would be in /usr/local/bin:
developer# ls -lt autoconf-*
-r-xr-xr-x 1 root wheel 14657 Aug 13 2009 autoconf-2.62
-r-xr-xr-x 1 root wheel
On Tue, Mar 8, 2011 at 12:00 PM, Robert Haas wrote:
> Going once, going twice...
>
> I'll go ahead and do this, barring objections or some other volunteer.
developer.postgresql.org apparently hates me. After waiting an
insanely long time to copy over the exported tarball to that machine,
I tried
On Wed, 2011-03-09 at 15:37 +0100, Yeb Havinga wrote:
> The current situation is definately unsafe because it forces people
> that are in this state to do a fast shutdown.. but that fails as well,
> so they are only left with immediate.
All the more reason not to change anything, since we disagre
>> Ouch. Attempting to attach the dotty image again..
>
> I don't understand this graph. What are the arrows? Downlinks or
> sibling pointers?
>
Sorry, they are sibling previous and next pointers. The ROOT is at
level 1, rest all live blocks are at level 0. #524 is the leftmost
page.
Regards,
N
On 2011-03-09 15:10, Simon Riggs wrote:
On Wed, 2011-03-09 at 16:38 +0900, Fujii Masao wrote:
On Wed, Mar 9, 2011 at 2:14 PM, Jaime Casanova wrote:
On Tue, Mar 8, 2011 at 11:58 AM, Robert Haas wrote:
The fast shutdown handling seems fine, but why not just handle smart
shutdown the same way?
Excerpts from Nikhil Sontakke's message of mié mar 09 11:16:22 -0300 2011:
> >> Re-sending without the attachments. Can someone please allow my
> >> attachments through from the previous email?
> >
> > They are not in the moderation queue, so presumably they got eaten by
> > the antispam grue.
>
>
On Wed, 2011-03-09 at 16:38 +0900, Fujii Masao wrote:
> On Wed, Mar 9, 2011 at 2:14 PM, Jaime Casanova wrote:
> > On Tue, Mar 8, 2011 at 11:58 AM, Robert Haas wrote:
> >>
> >> The fast shutdown handling seems fine, but why not just handle smart
> >> shutdown the same way?
> >
> > currently, smart
Excerpts from Nikhil Sontakke's message of mié mar 09 10:51:50 -0300 2011:
> Re-sending without the attachments. Can someone please allow my
> attachments through from the previous email?
They are not in the moderation queue, so presumably they got eaten by
the antispam grue.
> Blocks 519 to 521
Re-sending without the attachments. Can someone please allow my
attachments through from the previous email?
TIA
Nikhils
-- Forwarded message --
From: Nikhil Sontakke
Date: Wed, Mar 9, 2011 at 8:42 PM
Subject: index corruption in PG 8.3.13
To: pgsql-hackers@postgresql.org
Hi,
Excerpts from Adrian von Bidder's message of mié mar 09 09:13:04 -0300 2011:
> On Wednesday 09 March 2011 13.05:55 Magnus Hagander wrote:
> > I see a graylisted email that's in the queue... I'll give it a kick,
> > but normally you jsut have to wait...
>
> Thanks, it arrived.
>
> I'm used to wait
On Wednesday 09 March 2011 13.05:55 Magnus Hagander wrote:
> I see a graylisted email that's in the queue... I'll give it a kick,
> but normally you jsut have to wait...
Thanks, it arrived.
I'm used to wait when I enable greylisting. >4h delay is rare, though.
greets
-- vbi
--
I liken ISPs to
On Wed, Mar 9, 2011 at 13:00, Adrian von Bidder wrote:
> [adding webmaster to cc]
>
> On Tuesday 08 March 2011 21.20:20 Andres Freund wrote:
>> > "create account", ...
>> Its linked on the mainpage: http://www.postgresql.org/community/signup
>
> Hmm. Could it be that this web form doesn't have a
[adding webmaster to cc]
On Tuesday 08 March 2011 21.20:20 Andres Freund wrote:
> > "create account", ...
> Its linked on the mainpage: http://www.postgresql.org/community/signup
Hmm. Could it be that this web form doesn't have a mail queue and thus
doesn't retry to send the mail when the first
On Wed, Mar 9, 2011 at 08:38, Fujii Masao wrote:
> On Wed, Mar 9, 2011 at 2:14 PM, Jaime Casanova wrote:
>> On Tue, Mar 8, 2011 at 11:58 AM, Robert Haas wrote:
>>>
>>> The fast shutdown handling seems fine, but why not just handle smart
>>> shutdown the same way?
>>
>> currently, smart shutdown
Hi,
I just wanted to thank everyone involved in shepherding the PL/Python
patches into the master repo, the testers, reviewers, commenters and
especially Peter, for their help and diligence.
The outstanding tracebacks patch is still being worked on, but
irrelevant of whether it will make it or no
2011/3/9 Vlad Arkhipov :
> 09.03.2011 18:54, Nicolas Barbier:
>>
>> 2011/3/9 Vlad Arkhipov:
>>
>>
>>>
>>> Let there are two transactions that were created with read commited
>>> isolation level. In the first one we're executing a SELECT query:
>>> SELECT * FROM t UNION ALL SELECT * FROM t;
>>>
>>>
09.03.2011 18:54, Nicolas Barbier:
2011/3/9 Vlad Arkhipov:
Let there are two transactions that were created with read commited
isolation level. In the first one we're executing a SELECT query:
SELECT * FROM t UNION ALL SELECT * FROM t;
In the second transaction we're modifying the same tab
Hi,
The attached patch updates replication/README to reflect current
walsender/walreceiver behavior. It doesn't include any description
about sync rep. That would need to be added later.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
replica
2011/3/9 Nicolas Barbier :
> Note that the standard defines things that must never happen in the
> case of READ COMMITTED, it does not specify that one *must* be able to
> see the stuff as committed by previous transactions, for example.
Hmm, make that "stuff as committed by concurrent transactio
2011/3/9 Vlad Arkhipov :
> Let there are two transactions that were created with read commited
> isolation level. In the first one we're executing a SELECT query:
> SELECT * FROM t UNION ALL SELECT * FROM t;
>
> In the second transaction we're modifying the same table:
> INSERT INTO t DEFAULT VALU
Let there are two transactions that were created with read commited
isolation level. In the first one we're executing a SELECT query:
SELECT * FROM t UNION ALL SELECT * FROM t;
In the second transaction we're modifying the same table:
INSERT INTO t DEFAULT VALUES;
COMMIT;
Is it possible that th
On 2011-03-09 08:38, Fujii Masao wrote:
On Wed, Mar 9, 2011 at 2:14 PM, Jaime Casanova wrote:
On Tue, Mar 8, 2011 at 11:58 AM, Robert Haas wrote:
The fast shutdown handling seems fine, but why not just handle smart
shutdown the same way?
currently, smart shutdown means no new connections, wa
66 matches
Mail list logo
