Tom Lane wrote:
Robert Haas 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 just thre
On Fri, 2011-07-08 at 12:34 -0700, Darren Duncan wrote:
> Yes, but that would just be in-memory or in temporary places external to
> every
> database. On disk internal to a database there would just be the oid. In
> fact,
> another aspect of the database model I defined is that each "database
Robert Haas 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 just three.
FWIW, I
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
On Fri, Jul 8, 2011 at 9:36 AM, Martin Pihlak 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 commitfest or if
On Thu, Jul 7, 2011 at 5:34 PM, Alvaro Herrera
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:
> http://archives.postgresql.org/message-id/E57A252DFD60C1FCA91731BD@amenophis
>
>
On Fri, Jul 8, 2011 at 5:21 AM, Kyotaro HORIGUCHI
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 Enterprise PostgreSQL Company
--
On Fri, Jul 8, 2011 at 2:21 AM, 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 databa
On Fri, Jul 8, 2011 at 12:58 AM, Jeff Davis 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 applications; it
On Fri, Jul 8, 2011 at 1:45 AM, Ashutosh Bapat
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 two?
Beats me, but I don't see
On Fri, Jul 8, 2011 at 9:06 AM, Kohei KaiGai 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 rebased over those chang
On Fri, Jul 8, 2011 at 4:57 PM, Noah Misch 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 classes of indexes
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
To: bugt...@netspace.org
Subject: Re: KSR[T] Advisory #2: ld.so
Oleg
On Fri, 8
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
On Fri, Jul 8, 2011 at 22:55, Bruce Momjian wrote:
> Tom Lane wrote:
>> Robert Haas 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
On Fri, Jul 08, 2011 at 10:09:54AM +0100, Kohei KaiGai wrote:
> 2011/7/8 Heikki Linnakangas :
> > On 08.07.2011 11:03, Kohei KaiGai wrote:
> >>
> >> 2011/7/7 Noah Misch:
> >>>
> >>> Making a distinction based simply on the call being an operator vs. a
> >>> function
> >>> is a dead end. ?I see thes
Tom Lane wrote:
> Robert Haas 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
> >
On Jul8, 2011, at 22:27 , Stefan Kaltenbrunner wrote:
> On 07/08/2011 04:21 PM, Tom Lane wrote:
>> Florian Pflug 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.
>
On 07/08/2011 04:21 PM, Tom Lane wrote:
> Florian Pflug 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. No
On Fri, Jul 08, 2011 at 09:20:46AM +0100, Kohei KaiGai wrote:
> 2011/7/7 Noah Misch :
> > 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:
> >> > That gets the job done for today, but Defin
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
Robert Haas 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% churn in the set o
On Fri, Jul 8, 2011 at 12:10 PM, Alvaro Herrera 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:
>
> http://herraiz.org/blog/2011/07/07/software-projects-alzheimer-julian-assanges-lost-contributio
On Thu, Jul 7, 2011 at 9:00 PM, Robert Haas wrote:
> 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 backslas
On 8 July 2011 17:10, Heikki Linnakangas
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/
PostgreSQL Development, 24x7 Support, Tra
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 08.07.2011 18:56, Peter Geoghegan wrote:
On 8 July 2011 15:58, Florian Pflug 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 WL_POSTMASTER_DEATH
bit
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 Herre
On Jul8, 2011, at 17:56 , Peter Geoghegan wrote:
> On 8 July 2011 15:58, Florian Pflug 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 necessaril
On Fri, Jul 8, 2011 at 11:57 AM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Tom Lane 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
"Kevin Grittner" writes:
> Tom Lane 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 me.
> I changed the definition to
On 8 July 2011 15:58, Florian Pflug 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.
> */
> WaitLatch(&MyProc->waitLa
On Fri, Jul 8, 2011 at 4:18 AM, Heikki Linnakangas
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 closely, and understand that
> innocent
Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jul 8, 2011 at 10:57 AM, Heikki Linnakangas
>> 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
On 8 July 2011 15:15, Peter Eisentraut 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 these
probl
Robert Haas writes:
> On Fri, Jul 8, 2011 at 10:57 AM, Heikki Linnakangas
> 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 got. If
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 cha
On Fri, Jul 8, 2011 at 10:57 AM, Heikki Linnakangas
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 got. If it's interpreted as
> a larg
On Mon, Jun 6, 2011 at 7:50 AM, Jim Nasby wrote:
> On Jun 4, 2011, at 3:56 AM, Greg Stark wrote:
>> On Thu, Jun 2, 2011 at 8:58 PM, Jim Nasby wrote:
>>>
>>> I'm torn between whether the type should store the original time or the
>>> original time converted to GMT.
>>
>> This is the wrong way to
Tom Lane 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 my daily
tests (i
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 Haas wrote:
> I'm not concerned about the possibility of spurious extra cycles of
> auxiliary process event l
On 08.07.2011 17:29, Tom Lane wrote:
Heikki Linnakangas 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 Jul8, 2011, at 16:21 , Tom Lane wrote:
> Florian Pflug 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.
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 08.07.2011 16:45, Kevin Grittner wrote:
Heikki Linnakangas 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 S
Heikki Linnakangas 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 part of the expression
Florian Pflug 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 versions
Alexander Korotkov 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 of tab1, i.e. tab
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:
http://www.pos
On Wed, Jul 6, 2011 at 17:59, Robert Haas wrote:
> On Wed, Jul 6, 2011 at 10:31 AM, Magnus Hagander 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. This is the repository that was li
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 :-(). Betwee
Heikki Linnakangas 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 didn't have a size limit. You ca
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 wo
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 pipe
On 8 July 2011 13:40, Heikki Linnakangas
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 spurious wakeups. In
> particular, the
On Thu, Jul 7, 2011 at 10:00 PM, Robert Haas 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 brokenness of \dd.
> With
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 08.07.2011 13:58, Florian Pflug wrote:
On Jul8, 2011, at 11:57 , Peter Geoghegan wrote:
On 7 July 2011 19:15, Robert Haas 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 sp
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) / OLDSERXID_ENTR
On Jul8, 2011, at 11:57 , Peter Geoghegan wrote:
> On 7 July 2011 19:15, Robert Haas 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.
On Jul7, 2011, at 18:09 , Robert Haas wrote:
> 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
On 7 July 2011 19:15, Robert Haas 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 !PostmasterIsAlive() from within
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 i
On Thu, Jul 7, 2011 at 02:26, Brar Piening wrote:
> Original Message
> Subject: Re: [HACKERS] Review of VS 2010 support patches
> From: Andrew Dunstan
> To: Brar Piening
> Date: 06.07.2011 22:58
>
>>> I'll remove my versions from the patch (v9 probably) if those files get
>>>
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 tab1
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 w
2011/7/8 Heikki Linnakangas :
> On 08.07.2011 11:03, Kohei KaiGai wrote:
>>
>> 2011/7/7 Noah Misch:
>>>
>>> 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 trus
2011/7/7 Noah Misch :
> 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
>> >>
On 08.07.2011 11:03, Kohei KaiGai wrote:
2011/7/7 Noah Misch:
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 indexes defined on the tab
2011/7/7 Noah Misch :
> 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 unexpect
70 matches
Mail list logo
