On Tue, Jul 26, 2011 at 06:04:16PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Tue, Jul 26, 2011 at 05:05:15PM -0400, Tom Lane wrote:
> >> Dirty cache line, maybe not, but what if the assembly code commands the
> >> CPU to load those variables into CPU registers before doing the
> >> compar
Hi,
> Yeah, but I think we need to take that chance. At the very least, we
>> need to support the equivalent of a non-inherited CHECK (false) on
>> parent tables.
>>
>
> Indeed. I usually enforce that with a trigger that raises an exception, but
> of course that doesn't help at all with constra
I found a problem in WAL with this patch. I use simplified insert algorithm
in my patch which don't insert downlink one by one but insert them at once.
Thus FollowRight flag is leaving uncleared when redoing from WAL, because
only one flag can be cleared by one WAL record. Do you think modification
On 27.07.2011 15:29, Alexander Korotkov wrote:
I found a problem in WAL with this patch. I use simplified insert algorithm
in my patch which don't insert downlink one by one but insert them at once.
Thus FollowRight flag is leaving uncleared when redoing from WAL, because
only one flag can be cle
On tis, 2011-07-26 at 15:13 -0700, David Fetter wrote:
> This seems like a mechanical check. Should it be part of what gets
> checked when people push?
It's not really that mechanical, because some libpq functions supply the
newline, so you can't just mechanically add or enforce it everywhere.
On Tue, Jul 26, 2011 at 5:37 PM, Tom Lane wrote:
> Yeb Havinga writes:
>> A few days ago I read Tomas Vondra's blog post about dss tpc-h queries
>> on PostgreSQL at
>> http://fuzzy.cz/en/articles/dss-tpc-h-benchmark-with-postgresql/ - in
>> which he showed how to manually pull up a dss subquery t
On tis, 2011-07-26 at 22:44 +0200, Florian Pflug wrote:
> While reviewing the (now applied) XPATH escaping patches, Radoslaw
> found one
> case where the previous failure of XPATH to escape its return value
> was offset
> by XMLATTRIBUTES insistence to escape all input values, even if
> they're
> a
On 2011-07-27 16:16, Robert Haas wrote:
On Tue, Jul 26, 2011 at 5:37 PM, Tom Lane wrote:
Yeb Havinga writes:
A few days ago I read Tomas Vondra's blog post about dss tpc-h queries
on PostgreSQL at
http://fuzzy.cz/en/articles/dss-tpc-h-benchmark-with-postgresql/ - in
which he showed how to man
On Wed, Jul 27, 2011 at 6:05 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> Dunno, both approaches seem reasonable to me. There's no rule against
> changing WAL record structure across major releases, if that's what you were
> worried about.
>
OK, thanks. I also found beha
Yeb Havinga writes:
> Tom and Robert, thank you both for your replies. I think I'm having some
> blind spots and maybe false assumptions regarding the overal work in the
> optimizer, as it is not clear to me what 'the same sort of query' would
> look like. I was under the impression that using
On Tue, Jul 26, 2011 at 9:21 PM, Josh Kupershmidt wrote:
> On Tue, Jul 26, 2011 at 9:53 AM, Robert Haas wrote:
>> On Mon, Jul 25, 2011 at 10:29 PM, Josh Kupershmidt
>> wrote:
>> I think this is basically the right approach but I found what you did
>> here a bit wordy, so I simplified it, commit
On 27.07.2011 17:43, Alexander Korotkov wrote:
1(l:1) blk: 324 numTuple: 129 free: 2472b(69.71%) rightlink:4294967295
(InvalidBlockNumber)
1(l:2) blk: 242 numTuple: 164 free: 932b(88.58%)
rightlink:4294967295 (InvalidBlockNumber)
2(l:2) blk: 525 numTuple: 121 free: 2824
2011/7/27 Yeb Havinga :
> On 2011-07-22 17:35, Hitoshi Harada wrote:
>>
>> 2011/7/23 Yeb Havinga:
>
> A few days ago I read Tomas Vondra's blog post about dss tpc-h queries on
> PostgreSQL at
> http://fuzzy.cz/en/articles/dss-tpc-h-benchmark-with-postgresql/ - in which
> he showed how to manually p
2011/7/27 Tom Lane :
> Yeb Havinga writes:
>> A few days ago I read Tomas Vondra's blog post about dss tpc-h queries
>> on PostgreSQL at
>> http://fuzzy.cz/en/articles/dss-tpc-h-benchmark-with-postgresql/ - in
>> which he showed how to manually pull up a dss subquery to get a large
>> speed up. In
On Tue, Jul 26, 2011 at 9:57 PM, Robert Haas wrote:
> On Tue, Jul 26, 2011 at 4:38 PM, Noah Misch wrote:
>> No new ideas come to mind, here.
>
> OK, I have a new idea. :-)
>
> 1. Add a new flag to each procState called something like
> "timeToPayAttention".
> 2. Each call to SIGetDataEntries()
Robert Haas writes:
> On Tue, Jul 26, 2011 at 9:57 PM, Robert Haas wrote:
>> 1. Add a new flag to each procState called something like
>> "timeToPayAttention".
>> 2. Each call to SIGetDataEntries() iterates over all the ProcStates
>> whose index is < lastBackend and sets stateP->timeToPayAttenti
Robert Haas wrote:
> There turned out to be a little bit of further subtlety to this,
> but it seems to work. Patch attached.
Stylistic question: Why is stateP->hasMessages set to false in one
place and FALSE and TRUE in others? It seems like it would be less
confusing to be consistent.
A
On Wed, Jul 27, 2011 at 12:34 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jul 26, 2011 at 9:57 PM, Robert Haas wrote:
>>> 1. Add a new flag to each procState called something like
>>> "timeToPayAttention".
>>> 2. Each call to SIGetDataEntries() iterates over all the ProcStates
>>> whos
On Tue, Jul 26, 2011 at 09:57:10PM -0400, Robert Haas wrote:
> On Tue, Jul 26, 2011 at 4:38 PM, Noah Misch wrote:
> > No new ideas come to mind, here.
>
> OK, I have a new idea. :-)
>
> 1. Add a new flag to each procState called something like
> "timeToPayAttention".
> 2. Each call to SIGetDat
On Tue, Jul 26, 2011 at 05:04:28PM -0400, Alvaro Herrera wrote:
> ***
> /home/pgbuildfarm/workdir/HEAD/pgsql.20950/src/test/isolation/expected/fk-deadlock2.out
>Sun Jul 24 08:46:44 2011
> ---
> /home/pgbuildfarm/workdir/HEAD/pgsql.20950/src/test/isolation/results/fk-deadlock2.out
> Sun Ju
On Wed, Jul 27, 2011 at 05:14:58PM +0300, Peter Eisentraut wrote:
> On tis, 2011-07-26 at 15:13 -0700, David Fetter wrote:
> > This seems like a mechanical check. Should it be part of what gets
> > checked when people push?
>
> It's not really that mechanical, because some libpq functions supply
On Wed, Jul 27, 2011 at 12:55 PM, Noah Misch wrote:
> This approach would work if a spinlock release constrained the global stores
> timeline. It makes a weaker guarantee: all stores preceding the lock release
> in program order will precede it globally. Consequently, no processor will
> observe
On Jul27, 2011, at 16:18 , Peter Eisentraut wrote:
> On tis, 2011-07-26 at 22:44 +0200, Florian Pflug wrote:
>> While reviewing the (now applied) XPATH escaping patches, Radoslaw
>> found one
>> case where the previous failure of XPATH to escape its return value
>> was offset
>> by XMLATTRIBUTES in
Normal021false
falsefalseDEX-NONEX-NONE
MicrosoftInternetExplorer4
On Jul27, 2011, at 08:51 , Petro Meier wrote:
> If I use PQescapeByteaConn() for a conenction to a PG9.1 Beta3 server, this
> function returns (e.g.) "\xea2abd8ef31...(and so on.)...".
> Here the problem: there should be a second backslash in the prefix. The SQL
> Statement which uses this strin
On Wed, Jul 27, 2011 at 01:30:47PM -0400, Robert Haas wrote:
> On Wed, Jul 27, 2011 at 12:55 PM, Noah Misch wrote:
> > [wrong objection]
>
> Eh, how can this possibly happen? You have to hold msgNumLock to to
> set maxMsgNum and msgNumLock to read maxMsgNum. If that's not enough
> to guarantee
Excerpts from Petro Meier's message of mié jul 27 02:51:22 -0400 2011:
> If I use PQescapeByteaConn() for a conenction to a PG9.1 Beta3 server,
> this function returns (e.g.) "\xea2abd8ef31...(and so on.)...".
>
> Here the problem: there should be a second backslash in the prefi
On Wed, Jul 27, 2011 at 1:58 PM, Noah Misch wrote:
>> > I think a benchmark is in order, something like 900 idle connections and 80
>> > connections running small transactions that create a few temporary tables.
>> > If
>> > that shows no statistically significant regression, then we're probably
Alvaro Herrera writes:
> Excerpts from Petro Meier's message of mié jul 27 02:51:22 -0400 2011:
>> If I use PQescapeByteaConn() for a conenction to a PG9.1 Beta3 server,
>> this function returns (e.g.) "\xea2abd8ef31...(and so on.)...".
>>
>> Here the problem: there should be a second
On Jul27, 2011, at 20:05 , Alvaro Herrera wrote:
> Excerpts from Petro Meier's message of mié jul 27 02:51:22 -0400 2011:
>
>> If I use PQescapeByteaConn() for a conenction to a PG9.1 Beta3 server,
>> this function returns (e.g.) "\xea2abd8ef31...(and so on.)...".
>>
>>Here the
On Wed, Jul 27, 2011 at 6:39 AM, Nikhil Sontakke
wrote:
>>>
>>> Yeah, but I think we need to take that chance. At the very least, we
>>> need to support the equivalent of a non-inherited CHECK (false) on
>>> parent tables.
>>
>> Indeed. I usually enforce that with a trigger that raises an excepti
Robert Haas writes:
> Well, I don't have anything strongly against the idea of an
> uninherited constraint, though it sounds like Tom does. But I think
> allowing it just in the case of CHECK (false) would be pretty silly.
> And, I'm fairly certain that this isn't going to play nice with
> coninh
On Jul 27, 2011, at 1:08 PM, Tom Lane wrote:
> Yeah. If we're going to allow this then we should just have a concept
> of a non-inherited constraint, full stop. This might just be a matter
> of removing the error thrown in ATAddCheckConstraint, but I'd be worried
> about whether pg_dump will han
On 07/27/2011 04:14 PM, David E. Wheeler wrote:
On Jul 27, 2011, at 1:08 PM, Tom Lane wrote:
Yeah. If we're going to allow this then we should just have a concept
of a non-inherited constraint, full stop. This might just be a matter
of removing the error thrown in ATAddCheckConstraint, but
On lör, 2011-07-16 at 15:01 -0400, Tom Lane wrote:
> Well, as I mentioned in the commit message, I've thought for some time
> that there were use cases for errdetail_internal. Whether these
> particular places in predicate.c use it or not doesn't affect that.
Looking at commit 1af37ec96d97722aeb5
On Wed, Jul 27, 2011 at 4:08 PM, Tom Lane wrote:
> Robert Haas writes:
>> Well, I don't have anything strongly against the idea of an
>> uninherited constraint, though it sounds like Tom does. But I think
>> allowing it just in the case of CHECK (false) would be pretty silly.
>> And, I'm fairly
On lör, 2011-07-16 at 21:55 +0300, Heikki Linnakangas wrote:
> I find it strange to simply leave those strings untranslated. It's
> going
> to look wrong, like someone just forgot to translate them. However, I
> agree it's perhaps a bit too much detail to translate all of those
> messages, and t
Excerpts from Peter Eisentraut's message of mié jul 27 16:19:22 -0400 2011:
> On lör, 2011-07-16 at 15:01 -0400, Tom Lane wrote:
> > Well, as I mentioned in the commit message, I've thought for some time
> > that there were use cases for errdetail_internal. Whether these
> > particular places in p
Hello,
The attached patch changes the location of the dumpUserConfig call in
the dumpRoles function of pg_dumpall.
This is related to this thread:
http://archives.postgresql.org/pgsql-hackers/2011-02/msg02359.php
Currently if you use 'ALTER ROLE rolename SET ROLE', pg_dumpall will
dump an 'ALTER
On ons, 2011-07-27 at 19:37 +0200, Florian Pflug wrote:
> > Per SQL standard, the attribute values may not be of type XML, so
> maybe
> > we should just prohibit it.
>
> We probably should have, but I think it's too late for that. I don't
> believe I'm the only one who uses XPATH results as attrib
On tis, 2011-07-26 at 09:53 -0400, Robert Haas wrote:
> On Mon, Jul 25, 2011 at 10:29 PM, Josh Kupershmidt
> wrote:
> > That seems like a good way to document this; patch for master
> updated.
> > I avoided mucking with the documentation for COMMENT ON RULE and
> > COMMENT ON TRIGGER this time; th
On 07/27/2011 02:05 PM, Alvaro Herrera wrote:
Excerpts from Petro Meier's message of mié jul 27 02:51:22 -0400 2011:
If I use PQescapeByteaConn() for a conenction to a PG9.1 Beta3 server,
this function returns (e.g.) "\xea2abd8ef31...(and so on.)...".
Here the problem: there should
On Jul27, 2011, at 23:08 , Peter Eisentraut wrote:
> Well, offhand I would expect that passing an XML value to XMLATTRIBUTES
> would behave as in
>
> SELECT XMLELEMENT(NAME "t", XMLATTRIBUTES(XMLSERIALIZE(content '&'::XML
> AS text) AS "a"))
With both 9.1 and 9.2 this query returns
xmlelem
Hi
As it stands, we're going to release 9.1, knowing that 9.2 will change the
behavior of XPATH. This brings forth the question whether we should somehow
warn about that in either the release notes or the documentation of 9.1
If we don't, then applications developed on 9.1 might contain workaroun
On Wed, Jul 27, 2011 at 14:08, Tom Lane wrote:
> Yeah. If we're going to allow this then we should just have a concept
> of a non-inherited constraint, full stop. This might just be a matter
> of removing the error thrown in ATAddCheckConstraint, but I'd be worried
> about whether pg_dump will
On Wed, Jul 27, 2011 at 5:19 PM, Peter Eisentraut wrote:
> On tis, 2011-07-26 at 09:53 -0400, Robert Haas wrote:
>> On Mon, Jul 25, 2011 at 10:29 PM, Josh Kupershmidt
>> wrote:
>> > That seems like a good way to document this; patch for master
>> updated.
>> > I avoided mucking with the documenta
On Wed, Jul 27, 2011 at 5:19 PM, Peter Eisentraut wrote:
> I would like to argue for reverting this. If you want to word-smith
> details like this, "relation" doesn't carry any additional meaning. PG
> hackers know that internally, a "relation" is a table, view, index,
> sequence, etc., but for
On Jul27, 2011, at 23:20 , Pavel Stehule wrote:
> this is a refreshed patch. Only constraints and RI is supported now.
> There is about 1000 ereport calls, where a enhanced diagnostics should
> be used, but probably we don't modify all in one time.
I wonder if it wouldn't be better to have somethi
Florian Pflug writes:
> Is there an establishes practice for situations like this, i.e. a behavior-
> changing bug-fix committed to X.Y+1 before X.Y is released?
Generally, we do nothing. It's a bit premature (in fact a lot
premature) to assume that the current behavior of HEAD is exactly what
w
On Jul28, 2011, at 01:28 , Tom Lane wrote:
> Florian Pflug writes:
>> Is there an establishes practice for situations like this, i.e. a behavior-
>> changing bug-fix committed to X.Y+1 before X.Y is released?
>
> Generally, we do nothing. It's a bit premature (in fact a lot
> premature) to assum
Phil Sorber writes:
> Currently if you use 'ALTER ROLE rolename SET ROLE', pg_dumpall will
> dump an 'ALTER ROLE' out right after the 'CREATE ROLE' statement.
I think pg_dumpall is the very least of your problems if you do
something like that. We probably ought to forbid it entirely.
In
http://archives.postgresql.org/message-id/201107270042.22427.jul...@mehnle.net
it's pointed out that pg_restore in direct-to-database mode is pretty
badly broken if standard_conforming_strings=on. The reason is that it
tries to lex SQL commands well enough to find line boundaries, and the
code
My client has been seeing regular instances of the following sort of problem:
...
03:06:09.453 exec_simple_query, postgres.c:900
03:06:12.042 XX000: could not find pg_class tuple for index 2662 at character
13
03:06:12.042 RelationReloadIndexInfo, relcache.c:1740
03:06:12.042 INSERT INTO zzz
On Wed, Oct 20, 2010 at 10:07 PM, Tom Lane wrote:
> I wonder whether we could do something involving WAL properties --- the
> current tuple visibility logic was designed before WAL existed, so it's
> not exploiting that resource at all. I'm imagining that the kernel of a
> snapshot is just a WAL
I wrote:
> While I've not yet done any excavation in the commit logs to confirm
> this, the nearby comments in the code indicate that separation of COPY
> data from SQL commands was adopted in archive format version 1.3, which
> is ancient. In fact, it's so ancient that there was never a productio
2011/7/28 Florian Pflug :
> On Jul27, 2011, at 23:20 , Pavel Stehule wrote:
>> this is a refreshed patch. Only constraints and RI is supported now.
>> There is about 1000 ereport calls, where a enhanced diagnostics should
>> be used, but probably we don't modify all in one time.
>
> I wonder if it
56 matches
Mail list logo
