On 25.01.2011 22:53, Kevin Grittner wrote:
Heikki Linnakangas wrote:
On 25.01.2011 05:30, Kevin Grittner wrote:
The readme says this:
4. PostgreSQL supports subtransactions -- an issue not mentioned
in the papers.
But I don't see any mention anywhere else on how subtransactions
are ha
2011/1/26 Itagaki Takahiro :
> On Mon, Jan 24, 2011 at 20:10, Pavel Stehule wrote:
>> we have to iterate over array's items because it allow seq. access to
>> array's data. I need a global index for function "array_get_isnull". I
>> can't to use a buildin functions like array_slize_size or
>> arra
On Mon, Jan 24, 2011 at 20:10, Pavel Stehule wrote:
> we have to iterate over array's items because it allow seq. access to
> array's data. I need a global index for function "array_get_isnull". I
> can't to use a buildin functions like array_slize_size or
> array_get_slice, because there is high
Hi,
When log_checkpoints is enabled, checkpoint logs the number of
WAL files created/deleted/recycled, but restartpoint doesn't.
This is OK before 9.0 because restartpoint had never created/
deleted/recycled WAL files. But, in 9.0 or later, restartpoint might
do that while walreceiver is running.
On 10-12-23 08:45 AM, Jan Urbański wrote:
Here's a patch implementing a executing SPI in an subtransaction
mentioned in
http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
an incremental patch on top of the plpython-refactor patch sent eariler.
Git branch for this patch:
http
(2011/01/26 12:23), KaiGai Kohei wrote:
>>> Yikes. On further examination, exec_object_restorecon() is pretty
>>> bogus. Surely you need some calls to quote_literal_cstr() in there
>>> someplace.
>>
> Are you concerning about the object name being supplied to
> selabel_lookup_raw() in exec_object
On Wed, Jan 26, 2011 at 12:35:07AM +0200, Peter Eisentraut wrote:
> On tis, 2011-01-25 at 10:14 +0900, Itagaki Takahiro wrote:
> > and I have an almost empty pg_collation catalog with it:
> >
> > =# SELECT * FROM pg_collation;
> > collname | collnamespace | collencoding | collcollate | collctype
(2011/01/24 12:49), Robert Haas wrote:
> On Sun, Jan 23, 2011 at 9:56 PM, Robert Haas wrote:
>> On Sun, Jan 23, 2011 at 8:53 PM, Robert Haas wrote:
>>> 2011/1/21 KaiGai Kohei:
The attached patch is a revised version.
>>>
>>> I've committed this. Cleanup coming...
>>
>> Yikes. On further ex
On Tue, Jan 25, 2011 at 06:40:08PM -0500, Robert Haas wrote:
> On Mon, Jan 24, 2011 at 7:10 PM, Noah Misch wrote:
> > * at1.1-default-composite.patch
> > Remove the error when the user adds a column with a default value to a table
> > whose rowtype is used in a column elsewhere.
>
> Can we fix th
On Wed, Jan 26, 2011 at 02:57, David E. Wheeler wrote:
>>> Other than adminpack, I think it makes sense to say that extensions
>>> are not going into pg_catalog…
>>
>> Given this, we should maybe see about either making adminpack part of
>> PostgreSQL's core distribution (probably a good idea) or
Thanks for the review!
On Wed, Jan 26, 2011 at 3:40 AM, Jeff Janes wrote:
> I believe the new walrcv->receiveStart was introduced to divide up those
> behaviors that should go backwards from those that should not.
Yes.
> The non-retreating value is used in 3 places (via GetWalRcvWriteRecPtr)
>
On Mon, Jan 24, 2011 at 7:10 PM, Noah Misch wrote:
> * at1.2-doc-set-data-type.patch
> The documentation used "ALTER TYPE" when it meant "SET DATA TYPE", a subform
> of
> "ALTER TABLE" or "ALTER FOREIGN TABLE". Fixes just that.
Committed this part. For reasons involving me being tired, I
initi
On Mon, Jan 24, 2011 at 7:10 PM, Noah Misch wrote:
> * at1.1-default-composite.patch
> Remove the error when the user adds a column with a default value to a table
> whose rowtype is used in a column elsewhere.
Can we fix this without moving the logic around quite so much? I'm
worried that could
I had a requirement the other day to support a connection using an SSL
Client certificate. I set this up, and it worked nicely. But there's a
fly in the ointment. While the openssl libraries will ask for a pass
phrase for the key file if required when running psql, this is not
usable in other
On sön, 2011-01-23 at 12:23 -0500, Tom Lane wrote:
> Andy Colson writes:
> > Is there anyway to make bison/yacc/gcc/etc spit out the rule names?
>
> bison -v produces a debug output file that includes nicely cleaned-up
> versions of all the rules. But it includes a lot of other stuff too,
> and
On tis, 2011-01-25 at 10:14 +0900, Itagaki Takahiro wrote:
> On Sat, Jan 15, 2011 at 06:41, Peter Eisentraut wrote:
> > I've been going over this patch with a fine-tooth comb for the last two
> > weeks, fixed some small bugs, added comments, made initdb a little
> > friendlier, but no substantial
Jeff Davis wrote:
> It's OK to leave it to 9.2. But if it's a RO deferrable
> transaction, it's just going to go to sleep in that case anyway;
> so why not look for an opportunity to get a safe snapshot right
> away?
If you're talking about doing this only for DEFERRABLE transactions
it *might
On tis, 2011-01-25 at 16:19 -0500, Tom Lane wrote:
> What would probably be reasonable to do is a one-time run over a lot
> of locales, and then collate the results to see how many distinct
> outputs we see and over what sets of locales. Then we could make some
> reasoned decisions about which cas
Jeff Davis wrote:
> I think just annotating RWConflict.in/outLink and
> PredTranList.available/activeList with the types of things they
> hold would be a help.
>
> Also, you say something about RWConflict and "when the structure
> is not in use". Can you elaborate on that a bit?
Please let me
Andrew Dunstan writes:
> On 01/25/2011 12:30 PM, Tom Lane wrote:
>> It's only a regression if it used to pass in that locale. We can't
>> realistically try to support every possible locale in the tests.
> Maybe someone would like to set up a buildfarm member that tests a whole
> slew of locales
On Tue, Jan 25, 2011 at 02:43:31PM -0500, Andrew Dunstan wrote:
> On 01/25/2011 12:30 PM, Tom Lane wrote:
> >>marcin@skpsms:~/postgresql$ locale
> >>LC_COLLATE="pl_PL.UTF-8"
> >It's only a regression if it used to pass in that locale. We can't
> >realistically try to support every possible locale
Gurjeet Singh writes:
> Attached is the updated patch with doc changes and test cases.
Applied with assorted corrections. Aside from the refactoring I wanted,
there were various oversights.
> I have consciously disallowed the ability to specify storage_parameters
> using the WITH clause, if som
On tis, 2011-01-25 at 12:30 -0500, Tom Lane wrote:
> marcin mank writes:
> > On Tue, Jan 25, 2011 at 5:46 PM, marcin mank wrote:
> >> I did:
> >> git clone git://git.postgresql.org/git/postgresql.git && cd postgresql
> >> && ./configure --prefix=/home/marcin/pg91 --enable-cassert
> >> --enable-de
Heikki Linnakangas wrote:
> On 25.01.2011 05:30, Kevin Grittner wrote:
> The readme says this:
>> 4. PostgreSQL supports subtransactions -- an issue not mentioned
>>in the papers.
>
> But I don't see any mention anywhere else on how subtransactions
> are handled. If a subtransaction aborts,
On 25.01.2011 05:30, Kevin Grittner wrote:
Attached.
The readme says this:
+ 4. PostgreSQL supports subtransactions -- an issue not mentioned
+in the papers.
But I don't see any mention anywhere else on how subtransactions are
handled. If a subtransaction aborts, are its predicate locks i
On Wed, Jan 26, 2011 at 5:31 AM, Tom Lane wrote:
> In the end I think this is mainly an issue of setting appropriate
> expectations in the documentation. I've added the following text to
> the ALTER TABLE manual page:
>
>
> After this command is executed, the index is owned by the
>
Gurjeet Singh writes:
> On Tue, Jan 25, 2011 at 9:01 AM, Tom Lane wrote:
>> One other issue that might be worthy of discussion is that as things
>> stand, execution of the ADD CONSTRAINT USING INDEX syntax will cause
>> the constraint to absorb the index as an INTERNAL dependency. That
>> means
On Tue, Jan 25, 2011 at 16:34, Magnus Hagander wrote:
> On Tue, Jan 25, 2011 at 15:04, Fujii Masao wrote:
>> On Tue, Jan 25, 2011 at 10:28 PM, Fujii Masao wrote:
(the discussed changse above have been applied and pushed to github)
>>>
>>> Thanks! I'll test and review that.
>>
>> WAL file mi
Sorry for not being on top of this.
On Tue, Jan 25, 2011 at 9:01 AM, Tom Lane wrote:
> I wrote:
> > ... If that's the only issue then I don't see any need to wait on
> > the author, so will take this one.
>
> I find myself quite dissatisfied with the way that this patch adds yet
> another bool f
Joshua Tolley wrote:
>> http://www.xtranormal.com/watch/8285377/?listid=20642536
> I foresee a whole new set of animated postgres tutorials...
Seriously, I was thinking the same thing. I threw this together
while waiting to see if DBT-2 could shake out any new problems after
some minor cha
On Sun, Jan 23, 2011 at 07:48:04PM -0600, Kevin Grittner wrote:
> http://www.xtranormal.com/watch/8285377/?listid=20642536
I foresee a whole new set of animated postgres tutorials...
--
Joshua Tolley / eggyknap
End Point Corporation
http://www.endpoint.com
signature.asc
Description: Digital sig
On 01/25/2011 12:30 PM, Tom Lane wrote:
marcin@skpsms:~/postgresql$ locale
LC_COLLATE="pl_PL.UTF-8"
It's only a regression if it used to pass in that locale. We can't
realistically try to support every possible locale in the tests.
Maybe someone would like to set up a b
On Tue, Jan 25, 2011 at 11:15 AM, Josh Berkus wrote:
> For 9.1, what about doing a bug-finding bounty when we get into the 9.1
> beta cycle? Mozilla has been using bug bounties and they've been
> surprisingly successful.
>
This is do-able. We just have to present this in a way that will meet
> However, having a mentee begin work early in the 9.2 commit-fest cycle
> might be advantageous. I imagine that there is less pressure to review
> all of the patches in the early commit-fests. Perhaps this will give
> prospective mentors the ablility to spend more time with mentee's.
For 9.1,
On Tue, Jan 25, 2011 at 9:46 AM, Josh Berkus wrote:
> In several weeks, the review period for 9.1 will be over. Is this a plan
> for 9.2?
Yes. Our timing for this grant is unfortunate as it will likely be issued
too late to be useful for the 9.1 commit-fests. The delay is mostly my
fault.
On Tue, 2011-01-25 at 09:41 -0600, Kevin Grittner wrote:
> Yep. For the visual thinkers out there, the whole concept can be
> understood by looking at the jpeg file that's in the Wiki page:
>
> http://wiki.postgresql.org/images/e/eb/Serialization-Anomalies-in-Snapshot-Isolation.png
Yes, that he
On Mon, Jan 24, 2011 at 11:25 AM, Robert Haas wrote:
> On Thu, Jan 13, 2011 at 2:40 AM, Fujii Masao wrote:
>> On Thu, Jan 13, 2011 at 4:24 PM, Fujii Masao wrote:
>>> So I'm thinking to change pg_last_xlog_receive_location not to
>>> move backwards.
>>
>> The attached patch does that.
>
> It look
On Tue, 2011-01-25 at 11:17 -0600, Kevin Grittner wrote:
> > The heavy use of SHMQueue is quite reasonable, but for some reason
> > I find the API very difficult to read. I think it would help (at
> > least me) quite a lot to annotate (i.e. with a comment in the
> > struct) the various lists and li
On Tue, 2011-01-25 at 14:14 +, Dave Page wrote:
> On Tue, Jan 25, 2011 at 1:39 PM, Richard Broersma
> wrote:
> > On Tue, Jan 25, 2011 at 12:42 AM, Dave Page wrote:
> >>
> >> Will the scheme be open to everyone, or just .USians?
> >
> > I do believe that such grants are limited to members of P
On Mon, Jan 24, 2011 at 07:01:13PM -0500, Tom Lane wrote:
> One other issue that might be worthy of discussion is that as things
> stand, execution of the ADD CONSTRAINT USING INDEX syntax will cause
> the constraint to absorb the index as an INTERNAL dependency. That
> means dropping the constrai
On Jan 25, 2011, at 7:27 AM, David Fetter wrote:
>> Other than adminpack, I think it makes sense to say that extensions
>> are not going into pg_catalog…
>
> Given this, we should maybe see about either making adminpack part of
> PostgreSQL's core distribution (probably a good idea) or moving it
marcin mank writes:
> On Tue, Jan 25, 2011 at 5:46 PM, marcin mank wrote:
>> I did:
>> git clone git://git.postgresql.org/git/postgresql.git && cd postgresql
>> && ./configure --prefix=/home/marcin/pg91 --enable-cassert
>> --enable-debug && make check
>>
>> which gave me the attached regression.
Jeff Davis wrote:
> For starters, the above structures require unlimited memory, while
> we have fixed amounts of memory. The predicate locks are
> referenced by a global shared hash table as well as per-process
> SHMQueues. It can adapt memory usage downward in three ways:
> * increase lock g
On Tue, Jan 25, 2011 at 5:46 PM, marcin mank wrote:
> Hello.
> I did:
> git clone git://git.postgresql.org/git/postgresql.git && cd postgresql
> && ./configure --prefix=/home/marcin/pg91 --enable-cassert
> --enable-debug && make check
>
> which gave me the attached regression.diffs
>
uh, this may
Hello.
I did:
git clone git://git.postgresql.org/git/postgresql.git && cd postgresql
&& ./configure --prefix=/home/marcin/pg91 --enable-cassert
--enable-debug && make check
which gave me the attached regression.diffs
marcin@skpsms:~/postgresql$ gcc -v
Using built-in specs.
Target: x86_64-linux-gn
2011/1/25 Tom Lane :
> Robert Haas writes:
>> On Tue, Jan 25, 2011 at 10:03 AM, Tom Lane wrote:
>>> The arguments that were made against this were about maintenance costs
>>> and code footprint. Claims about performance are not really relevant,
>>> especially when they're entirely unsupported by
On Tue, Jan 25, 2011 at 10:47 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jan 25, 2011 at 10:03 AM, Tom Lane wrote:
>>> The arguments that were made against this were about maintenance costs
>>> and code footprint. Claims about performance are not really relevant,
>>> especially when t
Robert Haas writes:
> On Tue, Jan 25, 2011 at 10:03 AM, Tom Lane wrote:
>> The arguments that were made against this were about maintenance costs
>> and code footprint. Claims about performance are not really relevant,
>> especially when they're entirely unsupported by evidence.
> How much evid
Thanks for the review, Jeff!
Dan Ports wrote:
> On Tue, Jan 25, 2011 at 01:07:39AM -0800, Jeff Davis wrote:
>> At a high level, there is a nice conceptual simplicity. Let me
>> try to summarize it as I understand it:
>> * RW dependencies are detected using predicate locking.
>> * RW dependencies
On Tue, Jan 25, 2011 at 15:04, Fujii Masao wrote:
> On Tue, Jan 25, 2011 at 10:28 PM, Fujii Masao wrote:
>>> (the discussed changse above have been applied and pushed to github)
>>
>> Thanks! I'll test and review that.
>
> WAL file might get recycled or removed while walsender is reading it.
> So
On Tue, Jan 25, 2011 at 10:03 AM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> Detoasting on first usage, ie. exec_eval_datum(), seems the best to me.
>> Compared to detoasting on assignment, it avoids the performance
>> regression if the value is never used, and I don't think checking if the
On Tue, Jan 25, 2011 at 04:23:41PM +0100, Dimitri Fontaine wrote:
> Itagaki Takahiro writes:
> > * Extensions installed in pg_catalog:
> > If we install an extension into pg_catalog,
> > CREATE EXTENSION xxx WITH SCHEMA pg_catalog
> > pg_dump dumps nothing about the extension. We might need spec
2011/1/25 Itagaki Takahiro :
> On Sat, Jan 15, 2011 at 02:25, Hitoshi Harada wrote:
>> The patch overrides client_encoding by the added ENCODING option, and
>> restores it as soon as copy is done.
>
> We cannot do that because error messages should be encoded in the original
> encoding even during
Itagaki Takahiro writes:
> * Extensions installed in pg_catalog:
> If we install an extension into pg_catalog,
> CREATE EXTENSION xxx WITH SCHEMA pg_catalog
> pg_dump dumps nothing about the extension. We might need special care
> for modules that install functions only in pg_catalog.
In src/ba
Heikki Linnakangas writes:
> Detoasting on first usage, ie. exec_eval_datum(), seems the best to me.
> Compared to detoasting on assignment, it avoids the performance
> regression if the value is never used, and I don't think checking if the
> value is toasted at every exec_eval_datum() call ad
On 01/25/2011 09:15 AM, Xiaobo Gu wrote:
Hi Andrew,
The config.log is as following
So what is the declaration of accept at
d:/amber/devtool/rtools/mingw64/lib/gcc/../../x86_64-w64-mingw32/include/winsock2.h:1035:37:
?
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
I've just noticed that we were guilty of very sloppy thinking in
defining pg_class.relhasexclusion. The only place that actually
*uses* that value, rather than jumping through hoops to maintain it,
is BuildIndexInfo --- and what it's looking at is not the pg_class
entry of the table, but the pg_cl
Hi,
Itagaki Takahiro writes:
> Hi, I read the patch and test it in some degree. It works as expected
> generally, but still needs a bit more development in edge case.
Thanks for the review!
> * commands/extension.h needs cleanup.
> - Missing "extern" declarations for create_extension and
> cre
On Tue, Jan 25, 2011 at 1:39 PM, Richard Broersma
wrote:
> On Tue, Jan 25, 2011 at 12:42 AM, Dave Page wrote:
>>
>> Will the scheme be open to everyone, or just .USians?
>
> I do believe that such grants are limited to members of PgUS. Although, I
> should mention that there's no restriction for
On Tue, Jan 25, 2011 at 10:28 PM, Fujii Masao wrote:
>> (the discussed changse above have been applied and pushed to github)
>
> Thanks! I'll test and review that.
WAL file might get recycled or removed while walsender is reading it.
So the WAL file which pg_basebackup seemingly received successf
On 01/25/2011 06:40 AM, Xiaobo Gu wrote:
I also tried 64bit 4.5.2 GCC shipped with Rtools, the same error
checking types of arguments for accept()... configure: error: could not determin
e argument types
I don't have this setup, soi I can't debug it. Neither does anyone else
I know of. I
On Tue, Jan 25, 2011 at 12:42 AM, Dave Page wrote:
>
> Will the scheme be open to everyone, or just .USians?
I do believe that such grants are limited to members of PgUS. Although, I
should mention that there's no restriction for residents of any country
becoming a member of PgUS.
> If the
On Tue, Jan 25, 2011 at 8:21 PM, Magnus Hagander wrote:
>> + elog(DEBUG1, "Going to send wal from %i.%i to %i.%i",
>> + logid, logseg,
>> + endlogid, endlogseg);
>>
>> %u should be used instead of %i. Or how about logging the filename?
>
On Mon, Jan 24, 2011 at 18:22, Dimitri Fontaine wrote:
> Following recent commit of the hstore Makefile cleaning, that I included
> into my extension patch too, I have a nice occasion to push version 27
> of the patch. Please find it enclosed.
Hi, I read the patch and test it in some degree. It
I also tried 64bit 4.5.2 GCC shipped with Rtools, the same error
> checking types of arguments for accept()... configure: error: could not
> determin
> e argument types
On Tue, Jan 25, 2011 at 7:03 PM, Xiaobo Gu wrote:
> Hi,
> I have successfully built 32bit PostgreSQL 9.0.2 using 32bit GCC 4.
On Tue, Jan 25, 2011 at 10:56, Fujii Masao wrote:
> On Tue, Jan 25, 2011 at 12:33 AM, Magnus Hagander wrote:
>> Here's an updated version of the patch:
>>
>> * rebased on the current git master (including changing the switch
>> from -w to -x since -w was used now)
>> * includes some documentation
Hi,
I have successfully built 32bit PostgreSQL 9.0.2 using 32bit GCC 4.5.0
and MinGW packaged by tdm64-gcc-4.5.1 from
http://tdm-gcc.tdragon.net/download.
But for 64bit there is only 4.5.1 GCC, which is not stable now, and
the configure script does not pass.
$ configure --without-zlib
checking bu
Thanks for working your way through this patch. I'm certainly well
aware that that's not a trivial task!
I'm suffering through a bout of insomnia, so I'll respond to some of
your high-level comments in hopes that serializability will help put me
to sleep (as it often does). I'll leave the more det
On Tue, Jan 25, 2011 at 12:33 AM, Magnus Hagander wrote:
> Here's an updated version of the patch:
>
> * rebased on the current git master (including changing the switch
> from -w to -x since -w was used now)
> * includes some documentation
> * use XLogByteToSeg and uint32 as mentioned here
> * re
On Tue, Jan 25, 2011 at 10:32, Fujii Masao wrote:
> On Mon, Jan 24, 2011 at 7:41 AM, Magnus Hagander wrote:
>> Make walsender options order-independent
>>
>> While doing this, also move base backup options into
>> a struct instead of increasing the number of parameters
>> to multiple functions fo
>
> > Here, we've somehow got the first two fields of u_address_type - street
> and
> zip - squashed together into one column named 'street', and all the other
> > columns nulled out.
>
> I think this is the old problem of PL/pgsql having two forms of SELECT
> INTO. You can either say:
>
> SELEC
On Mon, Jan 24, 2011 at 7:41 AM, Magnus Hagander wrote:
> Make walsender options order-independent
>
> While doing this, also move base backup options into
> a struct instead of increasing the number of parameters
> to multiple functions for each new option.
When I read the include-WAL-in-backup
On Mon, 2011-01-24 at 21:30 -0600, Kevin Grittner wrote:
> Attached.
>
> Dan and I have spent many, many hours desk-check and testing,
> including pounding for many hours in DBT-2 at high concurrency
> factors on a 16 processor box. In doing so, we found and fixed a few
> issues. Neither of us
Hi,
I don't know if this is a bug, but at least I haven't found any clear
statement in documentation about; this should be wrote with big and bold
letters.
In any way I think this is bug or big inconsistency, because of, as was
stated in previous mail
test=# CREATE FUNCTION p_enhance_address3
On Tue, Jan 25, 2011 at 2:43 AM, Richard Broersma
wrote:
>
>
> On Mon, Jan 24, 2011 at 5:53 PM, Josh Berkus wrote:
>>
>> On 1/24/11 12:17 PM, Richard Broersma wrote:
>> > PgUS is preparing to fund a grant for PgUS members to learn and
>> > participate in the patch review process. We looking for
75 matches
Mail list logo
