On Thu, Jul 07, 2011 at 09:30:47PM -0400, Robert Haas wrote:
> On Thu, Jul 7, 2011 at 3:54 PM, Noah Misch wrote:
> > Yes. DDL-DDL concurrency is a much smaller practical concern, but it is a
> > quality-of-implementation hole.
>
> Agreed, although I'm not too pleased about the fact that this doe
Jeff Davis wrote:
On Thu, 2011-07-07 at 20:56 -0700, Darren Duncan wrote:
When you create a temporary table, PostgreSQL needs to add rows in
pg_class, pg_attribute, and probably other system catalogs. So there are
writes, which aren't possible in a read-only transaction. Hence the
error. And no,
On Thu, Jul 7, 2011 at 9:41 PM, Robert Haas wrote:
> On Thu, Jul 7, 2011 at 3:05 AM, Ashutosh Bapat
> wrote:
> > I noticed that the test alter_table.sql is creating two tables tab1 and
> tab2
> > and it's not dropping it. Any test which follows this test and tries to
> > create tables with names
On Thu, 2011-07-07 at 20:56 -0700, Darren Duncan wrote:
> > When you create a temporary table, PostgreSQL needs to add rows in
> > pg_class, pg_attribute, and probably other system catalogs. So there are
> > writes, which aren't possible in a read-only transaction. Hence the
> > error. And no, ther
On Thu, 2011-07-07 at 12:36 -0400, Robert Haas wrote:
> I think it's probably too late to go fiddling with the behavior of 9.0
> at this point. If we change the text of error messages, there is a
> chance that it might break applications; it would also require those
> messages to be re-translated,
Hello all,
a lazy deep SQL validation inside plpgsq functions is interesting
attribute. It allows to work with temporary tables and it make testing
and debugging harder, because lot of errors in embedded queries are
detected too late. I wrote a simple module that can to help little
bit. It is base
Guillaume Lelarge wrote [on pgsql-general]:
On Thu, 2011-07-07 at 16:01 +, mike beeper wrote [on pgsql-general]:
I have a function that creates a temp table, populate it with results
during intermediate processing, and reads from it at the end. When
the transaction is marked as read only, i
On Wed, Jun 29, 2011 at 12:15 PM, Merlin Moncure wrote:
>> I was kind of hoping to avoid dealing with this can of worms with this
>> simple patch, which by itself seems uncontroversial. If there's
>> consensus that \dd and the other backslash commands need further
>> reworking, I can probably devo
On Thu, Jul 7, 2011 at 3:54 PM, Noah Misch wrote:
> Yes. DDL-DDL concurrency is a much smaller practical concern, but it is a
> quality-of-implementation hole.
Agreed, although I'm not too pleased about the fact that this doesn't
fix nextval(). That seems like a fairly significant hole (but one
> As you proposed, adding new field which stores the backup end location
> taken from minRecoveryPoint, into pg_control sounds good idea.
Update patch.
Regards.
Jun Ishizuka
NTT Software Corporation
TEL：045-317-7018
E-Mail: ishizuka@po.ntts.co.jp
Original Message
Subject: Re: [HACKERS] Review of VS 2010 support patches
From: Craig Ringer
To: Brar Piening
Date: 07.07.2011 16:44
Frankly, I suggest leaving these tests for the buildfarm to sort out.
I don't see any sign of build process issues; they all build fine, and
On Sun, Jul 03, 2011 at 11:41:47AM +0200, Kohei KaiGai wrote:
> The simplified version of fix-leaky-view patch. The part of reloptions
> for views got splitted out
> into the part-0 patch, so it needs to be applied prior to this patch.
> Rest of logic to prevent unexpected pushing down across secur
I wrote:
> Peter Eisentraut writes:
>> I was adding gcc printf attributes to more functions in obscure places,
>> and now I'm seeing this in pg_upgrade:
>> relfilenode.c:72:2: warning: zero-length gnu_printf format string
>> [-Wformat-zero-length]
> Shouldn't it be prep_status("\n")? If not, w
Peter Eisentraut writes:
> I was adding gcc printf attributes to more functions in obscure places,
> and now I'm seeing this in pg_upgrade:
> relfilenode.c:72:2: warning: zero-length gnu_printf format string
> [-Wformat-zero-length]
> So the options I can see are either adding the compiler opti
Heikki Linnakangas wrote:
> I'll commit this too..
Thanks much for staying up past midnight to get these into beta3!
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 08.07.2011 00:33, Heikki Linnakangas wrote:
On 08.07.2011 00:21, Dan Ports wrote:
We should also apply the attached patch, which corrects a minor issue
with the conditions for flagging transactions that could potentially
make a snapshot unsafe.
There's a small window wherein a transaction is
On 08.07.2011 00:21, Dan Ports wrote:
We should also apply the attached patch, which corrects a minor issue
with the conditions for flagging transactions that could potentially
make a snapshot unsafe.
There's a small window wherein a transaction is committed but not yet
on the finished list, and
2011/6/24 Mark Kirkwood :
>
> This version moves the check *before* we write the new buffer, so should
> take care of issues about really large write buffers, plugins etc. Also I
> *think* that means there is no need to amend the documentation.
>
> Cheers
>
> Mark
>
> P.s: Hopefully I've got a con
Dan Ports wrote:
> We should also apply the attached patch, which corrects a minor
> issue with the conditions for flagging transactions that could
> potentially make a snapshot unsafe.
>
> There's a small window wherein a transaction is committed but not
> yet on the finished list, and we should
We should also apply the attached patch, which corrects a minor issue
with the conditions for flagging transactions that could potentially
make a snapshot unsafe.
There's a small window wherein a transaction is committed but not yet
on the finished list, and we shouldn't flag it as a potential con
Tom Lane wrote:
> Heikki Linnakangas writes:
>> Kevin and Dan also pointed out that a 2PC transaction can stay
>> in prepared state for a long time, and we could optimize that by
>> setting prepareSeqNo only at the final COMMIT PREPARED. I
>> objected to that, for the reason that it's currently v
On Thu, Jul 07, 2011 at 04:48:55PM -0400, Tom Lane wrote:
> Seems to me there's a more fundamental reason not to do that, which is
> that once you've done PREPARE it is no longer legitimate to decide to
> roll back the transaction to get out of a "dangerous" structure --- ie,
> you have to target o
I was adding gcc printf attributes to more functions in obscure places,
and now I'm seeing this in pg_upgrade:
relfilenode.c:72:2: warning: zero-length gnu_printf format string
[-Wformat-zero-length]
So the options I can see are either adding the compiler option
-Wno-format-zero-length (with con
Heikki Linnakangas writes:
> Kevin and Dan also pointed out that a 2PC transaction can stay in
> prepared state for a long time, and we could optimize that by setting
> prepareSeqNo only at the final COMMIT PREPARED. I objected to that, for
> the reason that it's currently very convenient for t
"Kevin Grittner" writes:
> Tom Lane wrote:
>> Just so everybody's clear --- this isn't making beta3, if it's not
>> going to get committed today.
> Yeah, Heikki let me know that off-list. I thought the last mention
> on the -hackers list of a cutoff date for that was the 11th. Did I
> misunde
On 07.07.2011 21:50, Heikki Linnakangas wrote:
On 07.07.2011 19:41, Kevin Grittner wrote:
Heikki Linnakangas wrote:
On 05.07.2011 20:03, Kevin Grittner wrote:
In reviewing the 2PC changes mentioned in a separate post, both
Dan and I realized that these were dependent on the assumption
that SSI
Tom Lane wrote:
> Just so everybody's clear --- this isn't making beta3, if it's not
> going to get committed today.
Yeah, Heikki let me know that off-list. I thought the last mention
on the -hackers list of a cutoff date for that was the 11th. Did I
misunderstand or was there some later cha
"Kevin Grittner" writes:
> Heikki Linnakangas wrote:
>> That yields a much smaller patch (attached). How does this look to
>> you, am I missing anything?
> Very clever. I'll need to study this and think about it. I'll try
> to post a response before I go to bed tonight. Hopefully Dan can
> w
On tor, 2011-07-07 at 00:22 -0400, Tom Lane wrote:
> Is there a way to persuade gcc to complain about such extensions when
> used in contexts where we don't know they work?
I don't think so.
First of all, the comment in pg_config_manual.h says that we *want* the
compiler to recognize %m as valid,
Peter Eisentraut writes:
> On tor, 2011-07-07 at 13:26 -0400, Tom Lane wrote:
>> OK, so the plan is to move these settings into a separate top-level
>> group "Replication", and sub-divide into master and standby settings,
> Most of the messages use the term "primary" rather than "master". I
> th
I noticed that the 8.4 branch has a file contrib/pg_upgrade/.gitignore
even though that version does not ship pg_upgrade. Apparently, a
few .gitignore files have been backpatched without checking whether they
apply. pg_archivecleanup and unaccent are also affected, and there
might be other direct
On Thu, Jul 07, 2011 at 11:43:30AM -0400, Robert Haas wrote:
> On Wed, Jul 6, 2011 at 10:44 PM, Noah Misch wrote:
> > Attached. I made the counter 64 bits wide, handled the nothing-found case
> > per
> > your idea, and improved a few comments cosmetically. I have not attempted
> > to
> > impro
On tor, 2011-07-07 at 13:26 -0400, Tom Lane wrote:
> OK, so the plan is to move these settings into a separate top-level
> group "Replication", and sub-divide into master and standby settings,
Most of the messages use the term "primary" rather than "master". I
think there was a discussion in 9.0
On Thu, Jul 7, 2011 at 3:21 PM, Noah Misch wrote:
> On Thu, Jul 07, 2011 at 03:06:46PM -0400, Robert Haas wrote:
>> On Thu, Jul 7, 2011 at 2:55 PM, Noah Misch wrote:
>> > CheckIndexCompatible() calls ComputeIndexAttrs() to resolve the new
>> > operator
>> > classes, collations and exclusion oper
On Thu, Jul 07, 2011 at 03:06:46PM -0400, Robert Haas wrote:
> On Thu, Jul 7, 2011 at 2:55 PM, Noah Misch wrote:
> > CheckIndexCompatible() calls ComputeIndexAttrs() to resolve the new operator
> > classes, collations and exclusion operators for each index column. It then
> > checks those against
On Tue, Jul 5, 2011 at 12:03 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> Well, as long as we can verify that OLDSERXID_MAX_PAGE has the
>> same value for BLCKSZ=8K before and after this patch, I don't see
>> any real downside to applying it. If, hypothetically, it's buggy,
>> it's only g
On Thu, Jul 7, 2011 at 2:55 PM, Noah Misch wrote:
> CheckIndexCompatible() calls ComputeIndexAttrs() to resolve the new operator
> classes, collations and exclusion operators for each index column. It then
> checks those against the existing values for the same. I figured that was
> obvious enou
Heikki Linnakangas wrote:
> Let's have two sequence numbers for each transaction: prepareSeqNo
> and commitSeqNo. prepareSeqNo is assigned when a transaction is
> prepared (in PreCommit_CheckForSerializableConflicts), and
> commitSeqNo is assigned when it's committed (in
> ReleasePredicateLocks)
On Thu, Jul 07, 2011 at 02:44:49PM -0400, Robert Haas wrote:
> On Thu, Jul 7, 2011 at 2:43 PM, Robert Haas wrote:
> > On Wed, Jul 6, 2011 at 2:50 PM, Noah Misch wrote:
> >> Drat; fixed in this version. My local branches contain a large test
> >> battery
> >> that I filter out of the diff before
On 07.07.2011 19:41, Kevin Grittner wrote:
Heikki Linnakangas wrote:
On 05.07.2011 20:03, Kevin Grittner wrote:
In reviewing the 2PC changes mentioned in a separate post, both
Dan and I realized that these were dependent on the assumption
that SSI's commitSeqNo is assigned in the order in whic
On Thu, Jul 7, 2011 at 2:43 PM, Robert Haas wrote:
> On Wed, Jul 6, 2011 at 2:50 PM, Noah Misch wrote:
>> Drat; fixed in this version. My local branches contain a large test battery
>> that I filter out of the diff before posting. This time, that filter also
>> removed an essential part of the
On Wed, Jul 6, 2011 at 2:50 PM, Noah Misch wrote:
> Drat; fixed in this version. My local branches contain a large test battery
> that I filter out of the diff before posting. This time, that filter also
> removed an essential part of the patch.
OK, I'm pretty happy with this version, with the
On Thu, Jul 7, 2011 at 1:41 PM, Peter Geoghegan wrote:
> I now think that we shouldn't change the return value format from the
> most recent revisions of the patch (i.e. returning a bitfield). We
> should leave it as-is, while documenting that it's possible, although
> extremely unlikely, for it t
On Thu, Jul 7, 2011 at 1:26 PM, Tom Lane wrote:
> Fujii Masao writes:
>> On Thu, Jun 30, 2011 at 1:34 AM, Josh Berkus wrote:
>>> My preference would be to have:
>>>
>>> # REPLICATION
>>>
>>> # - Master Settings -
>>> # these settings affect the master role in replication
>>> # they will be ignor
On Thu, Jul 7, 2011 at 1:35 PM, Tom Lane wrote:
> Joshua Berkus writes:
>>> I have been attempting to keep somewhat on top of the stuff that has
>>> become Ready for Committer, but there is too much of it for me to
>>> handle by myself.
>
>> Yeah, given that we're still in beta, I expected commit
On Thu, Jul 07, 2011 at 03:56:26PM +0100, Kohei KaiGai wrote:
> 2011/7/7 Noah Misch :
> > On Wed, Jul 06, 2011 at 10:25:12PM +0200, Kohei KaiGai wrote:
> >> *** a/src/backend/commands/view.c
> >> --- b/src/backend/commands/view.c
> >
> >> --- 227,257
> >> atcmd->d
I now think that we shouldn't change the return value format from the
most recent revisions of the patch (i.e. returning a bitfield). We
should leave it as-is, while documenting that it's possible, although
extremely unlikely, for it to incorrectly report Postmaster death, and
that clients therefor
Joshua Berkus writes:
>> I have been attempting to keep somewhat on top of the stuff that has
>> become Ready for Committer, but there is too much of it for me to
>> handle by myself.
> Yeah, given that we're still in beta, I expected committing to be a problem.
> Not a surprise.
Between beta
Magnus Hagander writes:
>> On Thu, Jul 7, 2011 at 17:09, Tom Lane wrote:
>>> http://git.postgresql.org/gitweb/?p=postgresql.git OK
>>> http://git.postgresql.org/gitweb?p=postgresql.git 404
> Should be fixed with a redirect now.
Thanks, my bookmarks seem OK again.
Robert,
> We need to start marking the patches that are "Waiting on Author" as
> "Returned with Feedback", ideally after checking that the status in
> the CF application is in fact up to date. With a week left in the
> CommitFest at this point, anything that has been reviewed and still
> has is
Fujii Masao writes:
> On Thu, Jun 30, 2011 at 1:34 AM, Josh Berkus wrote:
>> My preference would be to have:
>>
>> # REPLICATION
>>
>> # - Master Settings -
>> # these settings affect the master role in replication
>> # they will be ignored on the standby
>>
>> ... settings ...
>>
>> # - Stan
On Thu, Jul 7, 2011 at 10:56 AM, Kohei KaiGai wrote:
> My opinion is ALTER TABLE SET/RESET code should be enhanced to accept
> an operation to reset all the existing options, rather than tricky
> updates of pg_class.
> How about an idea to add AT_ResetAllRelOptions for internal use only?
>
> I'll
On Thu, Jul 7, 2011 at 17:12, Magnus Hagander wrote:
> On Thu, Jul 7, 2011 at 17:09, Tom Lane wrote:
>> Magnus Hagander writes:
>>> This move should now be completed.
>>
>> Something weird seems to have happened to the gitweb service at the same
>> time, which broke some of my bookmarks. On inv
Heikki Linnakangas wrote:
> On 05.07.2011 20:03, Kevin Grittner wrote:
>> In reviewing the 2PC changes mentioned in a separate post, both
>> Dan and I realized that these were dependent on the assumption
>> that SSI's commitSeqNo is assigned in the order in which the
>> transactions became visible
On Tue, Jul 5, 2011 at 12:26 PM, Jeff Davis wrote:
> In the 9.0 version of exclusion constraints, we added an extra check to
> ensure that, when searching for a conflict, a tuple at least found
> itself as a conflict. This extra check is not present in 9.1+.
>
> It was designed to help diagnose ce
On Thu, Jul 7, 2011 at 12:02 AM, Josh Berkus wrote:
> * 1/2 of patches are still pending development: 12 waiting on author,
> and 18 waiting for review. In addition, 7 patches are waiting for a
> committer.
We need to start marking the patches that are "Waiting on Author" as
"Returned with Feedba
On Thu, Jul 7, 2011 at 3:05 AM, Ashutosh Bapat
wrote:
> I noticed that the test alter_table.sql is creating two tables tab1 and tab2
> and it's not dropping it. Any test which follows this test and tries to
> create tables with names tab1 and tab2 will fail (unless it drops those
> tables first, b
On Thu, Jul 7, 2011 at 5:54 AM, Florian Pflug wrote:
> In effect, the resulting thing is an LWLock with a partitioned shared
> counter. The partition one backend operates on for shared locks is
> determined by its backend id.
>
> I've added the implementation to the lock benchmarking tool at
> ht
On 05.07.2011 20:03, Kevin Grittner wrote:
In reviewing the 2PC changes mentioned in a separate post, both Dan
and I realized that these were dependent on the assumption that
SSI's commitSeqNo is assigned in the order in which the transactions
became visible.
This comment in the patch actually
Heikki Linnakangas wrote:
> On 05.07.2011 20:06, Kevin Grittner wrote:
>> In reviewing the recent fix to 2PC coverage in SSI, I found some
>> cases which didn't seem to be covered. Dan bit the bullet and
>> came up with an additional isolation test to rigorously cover all
>> the permutations, t
On Wed, Jul 6, 2011 at 10:44 PM, Noah Misch wrote:
> Attached. I made the counter 64 bits wide, handled the nothing-found case per
> your idea, and improved a few comments cosmetically. I have not attempted to
> improve the search_path interposition case. We can recommend the workaround
> above
On Thu, Jul 7, 2011 at 17:09, Tom Lane wrote:
> Magnus Hagander writes:
>> This move should now be completed.
>
> Something weird seems to have happened to the gitweb service at the same
> time, which broke some of my bookmarks. On investigation, I think it's
> gotten pickier about the local-par
On 05.07.2011 20:06, Kevin Grittner wrote:
[resending after gzip of test patch]
In reviewing the recent fix to 2PC coverage in SSI, I found some
cases which didn't seem to be covered. Dan bit the bullet and came
up with an additional isolation test to rigorously cover all the
permutations, to f
Magnus Hagander writes:
> This move should now be completed.
Something weird seems to have happened to the gitweb service at the same
time, which broke some of my bookmarks. On investigation, I think it's
gotten pickier about the local-part of the URLs. For example
http://git.postgresql.org/gi
2011/7/7 Noah Misch :
> On Wed, Jul 06, 2011 at 10:25:12PM +0200, Kohei KaiGai wrote:
>> *** a/src/backend/commands/view.c
>> --- b/src/backend/commands/view.c
>
>> --- 227,257
>> atcmd->def = (Node *) lfirst(c);
>> atcmds = lappend(a
On 7/07/2011 8:26 AM, Brar Piening wrote:
As before "perltidy_before.patch" has to be applied first and
"VS2010v9.patch" second.
OK, I've gone through builds with way too many versions of the Windows
SDK and have test results to report.
The short version: please commit so I never, ever, ever
HarmeekSingh Bedi writes:
>In a plan where Node 1 is parent {say join) and Node 2 is child
> (say scan) . If node 1 has a expression say foo(column) then scan
> will project 'column' for sure and join will
> evaluate foo(column). Now if the node above join does not need
> column ? how
=?utf-8?q?Rados=C5=82aw_Smogura?= writes:
> Craig Ringer Thursday 07 of July 2011 01:05:48
>> How do you propose to make that reliable, though?
> I want to add IPC layer to postgresql, few approches may be considerable,
> 1. System IPC
> 2. Urgent data on socket
> 3. Sockets (at least descripto
This move should now be completed. If you see any errors still - other
than the change of SSH key - please validate that you have the new IP
address (204.145.120.222) - it could be excessive DNS caching.
If you have verified both the SSH key and the IP address and still see
problems, please let me
New version of patch with readme and some bugfixes.
Some new tests with fast build parameters variations are on the wiki page.
While I doubt to interpret some results of tests, because it looks strange
for me. I particular I can't explain why decrease of buffer size affects
index quality so much (i
On Jul7, 2011, at 03:35 , Robert Haas wrote:
> On Thu, Jun 23, 2011 at 11:42 AM, Robert Haas wrote:
>> On Wed, Jun 22, 2011 at 5:43 PM, Florian Pflug wrote:
>>> On Jun12, 2011, at 23:39 , Robert Haas wrote:
So, the majority (60%) of the excess spinning appears to be due to
SInvalReadLoc
Hello
thank you very much for review.
I cleaned patch and merged your documentation patch
I hope, this is all - a language correction should do some native speaker
Regards
Pavel Stehule
2011/7/6 Shigeru Hanada :
> (2011/06/02 17:39), Pavel Stehule wrote:
>> This patch enhances a GET DIAGNOSTI
Hi .
Apology for the bandwith. Did not know who to ask the question . I
was interested in a brief detail on how postgress does expression
pruning between nodes . The basic question is as follows
Scenerio
In a plan where Node 1 is parent {say join) and Node 2 is child
(say scan) . If node 1
Hi,
I noticed that the test alter_table.sql is creating two tables tab1 and tab2
and it's not dropping it. Any test which follows this test and tries to
create tables with names tab1 and tab2 will fail (unless it drops those
tables first, but that may not work, since tab2.y depends upon tab1 in
alt
74 matches
Mail list logo
