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
On Thu, Jul 07, 2011 at 09:30:47PM -0400, Robert Haas wrote:
On Thu, Jul 7, 2011 at 3:54 PM, Noah Misch n...@2ndquadrant.com 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
2011/7/7 Noah Misch n...@2ndquadrant.com:
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
On 08.07.2011 11:03, Kohei KaiGai wrote:
2011/7/7 Noah Mischn...@2ndquadrant.com:
Making a distinction based simply on the call being an operator vs. a function
is a dead end. I see these options:
1. The user defining a security view can be assumed to trust the operator class
members of
2011/7/7 Noah Misch n...@2ndquadrant.com:
On Thu, Jul 07, 2011 at 03:56:26PM +0100, Kohei KaiGai wrote:
2011/7/7 Noah Misch n...@2ndquadrant.com:
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
---
2011/7/8 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
On 08.07.2011 11:03, Kohei KaiGai wrote:
2011/7/7 Noah Mischn...@2ndquadrant.com:
Making a distinction based simply on the call being an operator vs. a
function
is a dead end. I see these options:
1. The user defining a
On 07.07.2011 22:09, Robert Haas wrote:
Adjust OLDSERXID_MAX_PAGE based on BLCKSZ.
The value when BLCKSZ = 8192 is unchanged, but with larger-than-normal
block sizes we might need to crank things back a bit, as we'll have
more entries per page than normal in that case.
I'm getting a bunch of
I found that results of previous tests with USNOA2 were not fully correct.
Tables for tests with various parameters contained tuples in different
order. I assumed that query
CREATE TABLE tab2 AS (SELECT * FROM tab1);
creates tab2 as exact copy of tab1, i.e. tab2 contain tuples in same order
as
On Thu, Jul 7, 2011 at 02:26, Brar Piening b...@gmx.de wrote:
Original Message
Subject: Re: [HACKERS] Review of VS 2010 support patches
From: Andrew Dunstan and...@dunslane.net
To: Brar Piening b...@gmx.de
Date: 06.07.2011 22:58
I'll remove my versions from the patch (v9
Hello, Could you let me go on with this topic?
It is hard to ignore this glitch for us using CJK - Chinese,
Japanese, and Korean - characters on databse.. Maybe..
Saying on Japanese under the standard usage, about a hundred
characters out of seven thousand make make_greater_string() fail.
This
On 7 July 2011 19:15, Robert Haas robertmh...@gmail.com wrote:
I'm not concerned about the possibility of spurious extra cycles of
auxiliary process event loops - should I be?
A tight loop would be bad, but an occasional spurious wake-up seems harmless.
We should also assert
On Jul7, 2011, at 18:09 , Robert Haas wrote:
On Thu, Jul 7, 2011 at 5:54 AM, Florian Pflug f...@phlo.org 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
On Jul8, 2011, at 11:57 , Peter Geoghegan wrote:
On 7 July 2011 19:15, Robert Haas robertmh...@gmail.com wrote:
I'm not concerned about the possibility of spurious extra cycles of
auxiliary process event loops - should I be?
A tight loop would be bad, but an occasional spurious wake-up seems
Heikki Linnakangas wrote:
I'm getting a bunch of warnings on Windows related to this:
.\src\backend\storage\lmgr\predicate.c(768): warning C4307: '+' :
integral constant overflow
The part of the expression which is probably causing this:
(MaxTransactionId + 1) /
On 08.07.2011 13:58, Florian Pflug wrote:
On Jul8, 2011, at 11:57 , Peter Geoghegan wrote:
On 7 July 2011 19:15, Robert Haasrobertmh...@gmail.com wrote:
I'm not concerned about the possibility of spurious extra cycles of
auxiliary process event loops - should I be?
A tight loop would be
On 08.07.2011 15:22, Kevin Grittner wrote:
Heikki Linnakangas wrote:
I'm getting a bunch of warnings on Windows related to this:
.\src\backend\storage\lmgr\predicate.c(768): warning C4307: '+' :
integral constant overflow
The part of the expression which is probably causing this:
On Thu, Jul 7, 2011 at 10:00 PM, Robert Haas robertmh...@gmail.com wrote:
[review of original, small patch to add another type to \dd's output]
I am inclined to say that we should reject this patch as it stands.
That's totally OK - that original patch was of marginal use given the
larger
On 8 July 2011 13:40, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I put the burden on the callers. Removing the return value from WaitLatch()
altogether just makes life unnecessarily difficult for callers that could
safely use that information, even if you sometimes get
On 08.07.2011 16:11, Peter Geoghegan wrote:
Incidentally, I like that this removes the amDirectChild argument to
PostmasterIsAlive() - an added benefit.
amDirectChild==false has actually been dead code for years. But the new
pipe method would work for a non-direct child too as long as the
On 07/03/2011 05:08 AM, Steve Singer wrote:
Since the original patch was submitted as a WIP patch and this version
wasn't sent until well into the commit fest I am not sure if it
qualifies for a committer during this commitfest or if it needs to wait
until the next one.
If possible I would
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
On 08.07.2011 15:22, Kevin Grittner wrote:
MaxTransactionId / OLDSERXID_ENTRIESPERPAGE
Hmm, that seems more correct to me anyway. We are trying to
calculate which page xid MaxTransactionId would be stored on, if
the SLRU
On sön, 2011-07-03 at 17:02 -0400, Tom Lane wrote:
Yeah. If there were One True Way to create a UUID, I would probably
agree that we should push that functionality into core. But there are
a lot of ways (and the reason for that is that they all suck in one
fashion or another :-(). Between
On Wed, Jul 6, 2011 at 17:59, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jul 6, 2011 at 10:31 AM, Magnus Hagander mag...@hagander.net wrote:
When we did the migration to git, we decided to leave the old
postgresql git repository around for a while, for people who had
clones around it.
On lör, 2011-06-25 at 01:02 +0100, Peter Geoghegan wrote:
I'm glad that you feel we're ready to officially support Clang -
should this be in the 9.1 release notes?
Done
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Alexander Korotkov aekorot...@gmail.com writes:
I found that results of previous tests with USNOA2 were not fully correct.
Tables for tests with various parameters contained tuples in different
order. I assumed that query
CREATE TABLE tab2 AS (SELECT * FROM tab1);
creates tab2 as exact copy
Florian Pflug f...@phlo.org writes:
Patch attached.
Beware that it needs at least GCC 4.1, otherwise it'll use a per-partition
spin lock instead of locked xadd to increment the shared counters.
That's already sufficient reason to reject the patch. Not everyone
uses gcc, let alone very recent
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 08.07.2011 15:22, Kevin Grittner wrote:
Heikki Linnakangas wrote:
I'm getting a bunch of warnings on Windows related to this:
.\src\backend\storage\lmgr\predicate.c(768): warning C4307: '+' :
integral constant overflow
The
On 08.07.2011 16:45, Kevin Grittner wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com wrote:
On 08.07.2011 15:22, Kevin Grittner wrote:
MaxTransactionId / OLDSERXID_ENTRIESPERPAGE
Hmm, that seems more correct to me anyway. We are trying to
calculate which page xid
The attached patch is a revised one; that utilizes untransformRelOptions()
to construct a list of DefElem to be supplied into AT_ResetRelOptions
commands. It enabled me to implement more compact as I expected.
How about this approach to reset existing reloptions?
I'll consolidate part-0, 1 and 2
On Jul8, 2011, at 16:21 , Tom Lane wrote:
Florian Pflug f...@phlo.org writes:
Patch attached.
Beware that it needs at least GCC 4.1, otherwise it'll use a per-partition
spin lock instead of locked xadd to increment the shared counters.
That's already sufficient reason to reject the patch.
On 08.07.2011 17:29, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
On 08.07.2011 15:22, Kevin Grittner wrote:
Heikki Linnakangas wrote:
I'm getting a bunch of warnings on Windows related to this:
.\src\backend\storage\lmgr\predicate.c(768): warning C4307: '+'
On Jul8, 2011, at 14:40 , Heikki Linnakangas wrote:
On 08.07.2011 13:58, Florian Pflug wrote:
On Jul8, 2011, at 11:57 , Peter Geoghegan wrote:
On 7 July 2011 19:15, Robert Haasrobertmh...@gmail.com wrote:
I'm not concerned about the possibility of spurious extra cycles of
auxiliary process
Tom Lane t...@sss.pgh.pa.us wrote:
So, what are the consequences if a compiler allows the expression
to overflow to zero? Does this mean that beta3 is dangerously
broken?
The risk to anyone not using serializable transactions is most
definitely zero. I've been running with this patch in
On Mon, Jun 6, 2011 at 7:50 AM, Jim Nasby j...@nasby.net wrote:
On Jun 4, 2011, at 3:56 AM, Greg Stark wrote:
On Thu, Jun 2, 2011 at 8:58 PM, Jim Nasby j...@nasby.net wrote:
I'm torn between whether the type should store the original time or the
original time converted to GMT.
This is the
On Fri, Jul 8, 2011 at 10:57 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
So if MaxTransactionId+1 overflows to zero, OLDSERXID_MAX_PAGE becomes -1.
Or a very high value, if the result of that is unsigned, as at least MSVC
seems to interpret it given the other warning I
In bug #6097,
http://archives.postgresql.org/pgsql-bugs/2011-07/msg00063.php
Maxim Boguk points out that the postmaster goes south when presented
with a new addition to the postgresql.conf file. The reason is this
code in ProcessConfigFile:
/* In SIGHUP cases in the postmaster, report
Robert Haas robertmh...@gmail.com writes:
On Fri, Jul 8, 2011 at 10:57 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
So if MaxTransactionId+1 overflows to zero, OLDSERXID_MAX_PAGE becomes -1.
Or a very high value, if the result of that is unsigned, as at least MSVC
seems
On 8 July 2011 15:15, Peter Eisentraut pete...@gmx.net wrote:
On lör, 2011-06-25 at 01:02 +0100, Peter Geoghegan wrote:
I'm glad that you feel we're ready to officially support Clang -
should this be in the 9.1 release notes?
Done
Reportedly, LLVM r134697 speeds things up considerably for
Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Jul 8, 2011 at 10:57 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
So if MaxTransactionId+1 overflows to zero, OLDSERXID_MAX_PAGE
becomes -1. Or a very high value, if the result of that is
On Fri, Jul 8, 2011 at 4:18 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
IMHO the situation from DBA's point of view is exactly opposite. Option two
requires deep knowledge of this leaky views issue. The DBA needs to inspect
any function he wants to mark as leak-free
On 8 July 2011 15:58, Florian Pflug f...@phlo.org wrote:
SyncRepWaitForLSN() says
/*
* Wait on latch for up to 60 seconds. This allows us to check for
* postmaster death regularly while waiting. Note that timeout here
* does not necessarily release from loop.
*/
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
At this point I think the actual choice we'd have is to abandon
beta3 and try again next week with a beta4. I'm trying to figure
out whether this bug is serious enough to warrant that, but it's
not clear to
On Fri, Jul 8, 2011 at 11:57 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
At this point I think the actual choice we'd have is to abandon
beta3 and try again next week with a beta4. I'm trying to figure
out
On Jul8, 2011, at 17:56 , Peter Geoghegan wrote:
On 8 July 2011 15:58, Florian Pflug f...@phlo.org wrote:
SyncRepWaitForLSN() says
/*
* Wait on latch for up to 60 seconds. This allows us to check for
* postmaster death regularly while waiting. Note that timeout here
* does not
Hi,
Someone seems to have noticed the commits by Julian Assange and the
discussion about him on pgsql-hackers when we switched from CVS to Git:
http://herraiz.org/blog/2011/07/07/software-projects-alzheimer-julian-assanges-lost-contributions/
Anyone feels in mood for a comment?
--
Álvaro
On 08.07.2011 18:56, Peter Geoghegan wrote:
On 8 July 2011 15:58, Florian Pflugf...@phlo.org wrote:
Also, none of the callers of WaitLatch() seems to actually inspect
the WL_POSTMASTER_DEATH bit of the result. We might want to make
their !PostmasterIsAlive() check conditional on the
On Thu, 2011-07-07 at 23:21 -0700, Darren Duncan wrote:
I think an even better way to support this is would be based on Postgres
having
support for directly using multiple databases within the same SQL session at
once, as if namespaces were another level deep, the first level being the
On 8 July 2011 17:10, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I just committed the v8 of the patch, BTW, after fixing the comment typo you
pointed out. Thanks!
Great, thanks.
Also, thank you Florian and Fujii.
--
Peter Geoghegan http://www.2ndQuadrant.com/
On Thu, Jul 7, 2011 at 9:00 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jun 29, 2011 at 12:15 PM, Merlin Moncure mmonc...@gmail.com 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
On Fri, Jul 8, 2011 at 12:10 PM, Alvaro Herrera alvhe...@alvh.no-ip.org wrote:
Someone seems to have noticed the commits by Julian Assange and the
discussion about him on pgsql-hackers when we switched from CVS to Git:
Robert Haas robertmh...@gmail.com writes:
Anyone feels in mood for a comment?
I see our mailing list archives for pgsql-hackers only go back to
1997, so it's hard to track down what was going on in 1996. But as
for why no one remembers the guy, it's probably because we've had
nearly 100%
Jeff Davis wrote:
On Thu, 2011-07-07 at 23:21 -0700, Darren Duncan wrote:
I think an even better way to support this is would be based on Postgres having
support for directly using multiple databases within the same SQL session at
once, as if namespaces were another level deep, the first level
On Fri, Jul 08, 2011 at 09:20:46AM +0100, Kohei KaiGai wrote:
2011/7/7 Noah Misch n...@2ndquadrant.com:
On Thu, Jul 07, 2011 at 03:56:26PM +0100, Kohei KaiGai wrote:
2011/7/7 Noah Misch n...@2ndquadrant.com:
On Wed, Jul 06, 2011 at 10:25:12PM +0200, Kohei KaiGai wrote:
That gets the
On 07/08/2011 04:21 PM, Tom Lane wrote:
Florian Pflug f...@phlo.org writes:
Patch attached.
Beware that it needs at least GCC 4.1, otherwise it'll use a per-partition
spin lock instead of locked xadd to increment the shared counters.
That's already sufficient reason to reject the patch.
On Jul8, 2011, at 22:27 , Stefan Kaltenbrunner wrote:
On 07/08/2011 04:21 PM, Tom Lane wrote:
Florian Pflug f...@phlo.org writes:
Patch attached.
Beware that it needs at least GCC 4.1, otherwise it'll use a per-partition
spin lock instead of locked xadd to increment the shared counters.
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
Anyone feels in mood for a comment?
I see our mailing list archives for pgsql-hackers only go back to
1997, so it's hard to track down what was going on in 1996. But as
for why no one remembers the guy, it's probably because
On Fri, Jul 08, 2011 at 10:09:54AM +0100, Kohei KaiGai wrote:
2011/7/8 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
On 08.07.2011 11:03, Kohei KaiGai wrote:
2011/7/7 Noah Mischn...@2ndquadrant.com:
Making a distinction based simply on the call being an operator vs. a
On Fri, Jul 8, 2011 at 22:55, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
Anyone feels in mood for a comment?
I see our mailing list archives for pgsql-hackers only go back to
1997, so it's hard to track down what was going on in 1996.
Magnus Hagander wrote:
The spring/summer of 1996 was a time when we were trying to gather all
the scattered work of people who had created patches to Postgres95 but
had not been integrated by Jolly. ?Seems Julian had been in that group
so his patches were quickly applied. ?If he had asked
I have one or two emails from Julian Assange about security in ld-linux.so,
but don't remember any commits to pg source tree. Probably Bruce remember him.
Date: Sat, 19 Jul 1997 00:07:59 +1000
From: Julian Assange pr...@suburbia.net
To: bugt...@netspace.org
Subject: Re: KSR[T] Advisory #2:
On Fri, Jul 8, 2011 at 4:57 PM, Noah Misch n...@2ndquadrant.com wrote:
Note that it does not matter whether we're actually doing an index scan -- a
seq
scan with a filter using only leakproof operators is equally acceptable.
What I
had in mind was to enumerate all operators in operator
On Fri, Jul 8, 2011 at 9:06 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
I definitely agree with this idea. It will enables to eliminate ugly switch
statements for error-messaging reasons.
All right, so please submit a patch that introduces that concept
first, and then resubmit this patch
On Fri, Jul 8, 2011 at 1:45 AM, Ashutosh Bapat
ashutosh.ba...@enterprisedb.com wrote:
I think, tab1 and tab2 are too common names, for anyone to pick up for the
tables. Also, the test alter_table.sql is dropping many other tables (even
those which have undergone renaming), then why not these
On Fri, Jul 8, 2011 at 12:58 AM, Jeff Davis pg...@j-davis.com wrote:
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
On Fri, Jul 8, 2011 at 2:21 AM, Darren Duncan dar...@darrenduncan.net wrote:
I think an even better way to support this is would be based on Postgres
having support for directly using multiple databases within the same SQL
session at once, as if namespaces were another level deep, the first
On Fri, Jul 8, 2011 at 5:21 AM, Kyotaro HORIGUCHI
horiguchi.kyot...@oss.ntt.co.jp wrote:
Points to realize this follows,
Please add your patch to the next CommitFest.
https://commitfest.postgresql.org/action/commitfest_view/open
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The
On Thu, Jul 7, 2011 at 5:34 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
The attached patch introduces pg_constraint rows for NOT NULL
column constraints.
This patch is a heavily reworked version of Bernd Helmle's patch here:
On Fri, Jul 8, 2011 at 9:36 AM, Martin Pihlak martin.pih...@gmail.com wrote:
On 07/03/2011 05:08 AM, Steve Singer wrote:
Since the original patch was submitted as a WIP patch and this version
wasn't sent until well into the commit fest I am not sure if it
qualifies for a committer during this
Robert Haas wrote:
But if that's what you want, just don't put your data in different
databases in the first place. That's what schemas are for.
If for some reason we needed to have tables that happened to be called
x.y.z and a.b.c accessible from a single SQL session, we could allow
that much
Robert Haas robertmh...@gmail.com writes:
If for some reason we needed to have tables that happened to be called
x.y.z and a.b.c accessible from a single SQL session, we could allow
that much more simply by allowing schemas to be nested. Then we could
allow arbitrary numbers of levels, not
70 matches
Mail list logo
