2012/12/30 Stephen Frost :
> * Peter Geoghegan (pe...@2ndquadrant.com) wrote:
>> On 30 December 2012 03:32, Stephen Frost wrote:
>> > Err. I intended to say "I really don't think what I sketched out, or
>> > something similar, would be that unlikely to happen", or something along
>> > those lines
On Sat, Dec 29, 2012 at 7:16 PM, Daniel Farina wrote:
> On Sat, Dec 29, 2012 at 7:12 PM, Peter Geoghegan
> wrote:
>> On 30 December 2012 02:45, Daniel Farina wrote:
>>> As I recall, the gist of this objection had to do with a false sense
>>> of stability of the hash value, and the desire to enf
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
> On 30 December 2012 03:32, Stephen Frost wrote:
> > Err. I intended to say "I really don't think what I sketched out, or
> > something similar, would be that unlikely to happen", or something along
> > those lines. Apologies for the confusion.
>
On Mon, Dec 24, 2012 at 10:43 AM, Charles Gomes wrote:
> And I had no performance improvements at all.
> Took the same time as with the previous EXECUTE statement;
>
> I don't see what am I doing wrong.
You might not be doing anything wrong. Triggers ARE slow.
If you have "perf" on your system,
On 30 December 2012 04:37, Robert Haas wrote:
> On Sat, Dec 29, 2012 at 10:07 PM, Greg Smith wrote:
>> It is a strange power of two to be appearing there. I can follow your
>> reasoning for why this could be a bit flipping error. There's no sign of
>> that elsewhere though, no other crashes und
On Sat, Dec 29, 2012 at 10:07 PM, Greg Smith wrote:
> It is a strange power of two to be appearing there. I can follow your
> reasoning for why this could be a bit flipping error. There's no sign of
> that elsewhere though, no other crashes under load. I'm using this server
> here because it's
On 30 December 2012 03:32, Stephen Frost wrote:
> Err. I intended to say "I really don't think what I sketched out, or
> something similar, would be that unlikely to happen", or something along
> those lines. Apologies for the confusion.
Almost anything can be misused.
If you're going to insis
On Sat, 2012-12-29 at 08:11 -0500, Robert Haas wrote:
> On Tue, Dec 25, 2012 at 1:42 PM, Dimitri Fontaine
> wrote:
> > Robert Haas writes:
> >>> Also, keep in mind we want the ObjectID in all CREATE, ALTER and DROP
> >>> statements, so my current patch is still some bricks shy of a load… (I
> >>>
On Wed, 2012-12-19 at 15:13 +, Albe Laurenz wrote:
> While playing with LDAP authentication, I discovered
> two documentation bugs.
>
> First, user and password for the first step in the
> two-step authentication mode are "ldapbinddn" and
> "ldapbindpasswd", not "ldapbinduser" and "ldapbinddn"
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
> On 30 December 2012 02:01, Stephen Frost wrote:
> > I really don't think what I sketched out or something similar would
> > happen. I do think it's incredibly frustrating as a user who is trying
> > to develop an application which behaves correct
On Sat, Dec 29, 2012 at 7:12 PM, Peter Geoghegan wrote:
> On 30 December 2012 02:45, Daniel Farina wrote:
>> As I recall, the gist of this objection had to do with a false sense
>> of stability of the hash value, and the desire to enforce the ability
>> to alter it. Here's an option: xor the has
On 30 December 2012 02:45, Daniel Farina wrote:
> As I recall, the gist of this objection had to do with a false sense
> of stability of the hash value, and the desire to enforce the ability
> to alter it. Here's an option: xor the hash value with the
> 'statistics session id', so it's *known* to
On 12/27/12 7:43 AM, Greg Stark wrote:
If it's always the first buffer then it could conceivably still be
some other heap allocated object that always lands before
LocalRefCount. It does seem a bit weird to be storing 1<<30 though --
there are no 1<<30 constants that we might be storing for examp
On Sun, Dec 23, 2012 at 8:41 PM, Tomas Vondra wrote:
> Attached is a patch with fixed handling of temporary relations. I've
> chosen to keep the logic in DropRelFileNodeAllBuffers and rather do a
> local copy without the local relations.
This looks pretty good, although it needs some cleanup for
On 30 December 2012 02:01, Stephen Frost wrote:
> I really don't think what I sketched out or something similar would
> happen. I do think it's incredibly frustrating as a user who is trying
> to develop an application which behaves correctly to be given only half
> the information.
I don't know
On Thu, Dec 27, 2012 at 11:33 AM, Tom Lane wrote:
> Greg Stark writes:
>> On Thu, Dec 27, 2012 at 3:17 AM, Tom Lane wrote:
>>> The thing that this theory has a hard time with is that the buffer's
>>> global refcount is zero. If you assume that there's a bit that
>>> sometimes randomly goes to 1
On Sat, Dec 29, 2012 at 6:37 PM, Peter Geoghegan wrote:
> On 29 December 2012 12:21, Daniel Farina wrote:
>> These were not express goals of the patch, but so long as you are
>> inviting features, attached is a bonus patch that exposes the queryid
>> and also the notion of a "statistics session"
On 29 December 2012 12:21, Daniel Farina wrote:
> These were not express goals of the patch, but so long as you are
> inviting features, attached is a bonus patch that exposes the queryid
> and also the notion of a "statistics session" that is re-rolled
> whenever the stats file could not be read
Peter,
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
> In order for the problem you describe to happen, the user would have
> to ignore the warning in the documentation about constraint_name's
> ability to uniquely identify something, and then have two constraints
> in play at the same time wit
On 29 December 2012 22:57, Stephen Frost wrote:
> So they'll quickly realize that a lookup-table based on constraint name
> would be useful, create it, and then have a primary key on it to make
> sure that they don't have any duplicates.
I don't find that terribly likely. There is nothing broken
Peter,
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
> if (constraint_name == "upc")
> MessageBox("That is not a valid barcode.");
So they'll quickly realize that a lookup-table based on constraint name
would be useful, create it, and then have a primary key on it to make
sure that they do
On 29 December 2012 21:24, Pavel Stehule wrote:
> can we remove CONSTRAINT_NAME from this patch? Minimally TABLE_SCHEMA,
> TABLE_NAME and COLUMN_NAME works as expected.
>
> CONSTRAINT_NAME can be implemented after constraints refactoring
This patch is almost completely pointless without a CONSTRA
On 29 December 2012 20:49, Stephen Frost wrote:
> In the end, I may agree with you- the patch is a nice idea, but it needs
> more to be a complete and working solution and providing something that
> only gets people half-way there would result in developers hacking
> things together which will qui
2012/12/29 Stephen Frost :
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> it is a problem of this patch or not consistent constraints implementation ?
>
> Not sure, but I don't think it matters. You can blame the constraint
> implementation, but that doesn't change my feelings about what we
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> it is a problem of this patch or not consistent constraints implementation ?
Not sure, but I don't think it matters. You can blame the constraint
implementation, but that doesn't change my feelings about what we need
before we can accept a patch
2012/12/29 Stephen Frost :
> * Peter Geoghegan (pe...@2ndquadrant.com) wrote:
>> > Having just constraint_schema and constraint_name feels horribly wrong
>> > as the definition of a constraint also includes a pg_class oid.
>>
>> I think that it's probably sufficient *for error handling purposes*.
>
On 02.10.2012 21:20, Fujii Masao wrote:
On Wed, Oct 3, 2012 at 3:11 AM, Simon Riggs wrote:
but its not high on my radar
right now unless you can explain why it should be higher.
It may not be high, but I'm just worried that we are likely to forget to
apply that change into HEAD if we postpone
The cascading replication patch made a change to the way WAL files
restored from archive are handled. Since then, when a WAL file is
restored from archive, it's copied under the correct filename to
pg_xlog. Aside from supporting cascading replication, this has the
advantage that if the archive
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
> > Having just constraint_schema and constraint_name feels horribly wrong
> > as the definition of a constraint also includes a pg_class oid.
>
> I think that it's probably sufficient *for error handling purposes*.
> Since it is non-trivial to get
Alastair,
* Alastair Turner (b...@ctrlf5.co.za) wrote:
> Patch for the changes discussed in
> http://archives.postgresql.org/pgsql-hackers/2010-10/msg00919.php
> attached (eventually ...)
>
> In summary: If the input file (-f) doesn't exist or the ouput or log
> files (-o and -l) can't be created
On 29 December 2012 19:56, Stephen Frost wrote:
>> - that case is
>> ERRCODE_CHECK_VIOLATION.
>>
>> That's because this SQL could cause ERRCODE_CHECK_VIOLATION:
>>
>> select '123'::upc_barcode;
>
> I'm surprised to see that as a constraint violation rather than a domain
> violation..?
I was tryin
Josh,
* Josh Kupershmidt (schmi...@gmail.com) wrote:
> I assume you meant "-L" instead of "-l" here for specifying psql's log
> file. I don't think that the inability to write to psql's log file
> should be treated as a fatal error, especially since it is not treated
> as such by the current code:
2012/12/29 Stephen Frost :
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> > Having just constraint_schema and constraint_name feels horribly wrong
>> > as the definition of a constraint also includes a pg_class oid.
>>
>> but then TABLE_NAME and TABLE_SCHEMA will be defined.
>
> How are you
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> > Having just constraint_schema and constraint_name feels horribly wrong
> > as the definition of a constraint also includes a pg_class oid.
>
> but then TABLE_NAME and TABLE_SCHEMA will be defined.
How are you going to look up the constraint? U
2012/12/29 Stephen Frost :
> * Peter Geoghegan (pe...@2ndquadrant.com) wrote:
>> So, unless someone adds a constraint name outside of these errcodes (I
>> doubt that would make sense), there is exactly one case where a
>> constraint_name could not have a schema_name (which, as I've said, is
>> almo
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
> So, unless someone adds a constraint name outside of these errcodes (I
> doubt that would make sense), there is exactly one case where a
> constraint_name could not have a schema_name (which, as I've said, is
> almost the same thing as constraint_s
2012/12/29 Peter Geoghegan :
> On 29 December 2012 18:37, Stephen Frost wrote:
>> That's exactly what I was getting at also- in order to do a lookup in
>> the catalog, you need to know certain information to avoid potentially
>> getting multiple records back (which would be an error...).
>
> Well,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> ok, so what is proposed solution?
My recommendation would be to match what glibc's printf does.
> I see two possibilities - a) applying my current patch - although it
> is not fully correct, b) new patch, that do necessary check and raise
> more
On 29 December 2012 18:37, Stephen Frost wrote:
> That's exactly what I was getting at also- in order to do a lookup in
> the catalog, you need to know certain information to avoid potentially
> getting multiple records back (which would be an error...).
Well, Pavel said that since a constraint i
Pavan,
* Pavan Deolasee (pavan.deola...@gmail.com) wrote:
> On Tue, Dec 4, 2012 at 6:01 PM, Pavan Deolasee
> wrote:
> > Thanks Andres. I also read the original thread and I now understand why we
> > are using FATAL here, at least until we have a better solution. Obviously
> > the connection reset
2012/12/29 Stephen Frost :
> Pavel,
>
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> 2012/12/29 Stephen Frost :
>> > This is correct, if we're matching glibc (and SUS, I believe), isn't it?
>> > You're not allowed to mix '%2$s' type parameters and '%s' in a single
>> > format.
>>
>> I am not
* Pavan Deolasee (pavan.deola...@gmail.com) wrote:
> On Fri, Sep 7, 2012 at 6:06 PM, Kevin Grittner
> > That makes sense to me. The reason I didn't make that change when I
> > added the serializable special case to pg_dump was that it seemed
> > like a separate question; I didn't want to complicat
Pavel,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> 2012/12/29 Stephen Frost :
> > This is correct, if we're matching glibc (and SUS, I believe), isn't it?
> > You're not allowed to mix '%2$s' type parameters and '%s' in a single
> > format.
>
> I am not sure, please recheck
According to t
On 30/12/12 05:24, Tom Lane wrote:
Andres Freund writes:
On 2012-12-29 07:23:24 -0500, Peter Eisentraut wrote:
The xlog code uses two different time zone formats at various times.
One is a pg_time_t (stored in pg_control/ControlFileData), the other is
a TimestampTz. Those have completely diff
* Jon Erdman (postgre...@thewickedtribe.net) wrote:
> Oops! Here it is in the proper diff format. I didn't have my env set up
> correctly :(
No biggie, and to get the bike-shedding started, I don't really like the
column name or the values.. :) I feel like something clearer would be
"Runs_As" wi
Hello
2012/12/29 Stephen Frost :
> Pavel,
>
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> I found so we doesn't have functionality for simply text aligning - so
>> I propose support width for %s like printf's behave. glibc
>> implementation knows a rule for precision, that I don't would to
Pavel,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> I found so we doesn't have functionality for simply text aligning - so
> I propose support width for %s like printf's behave. glibc
> implementation knows a rule for precision, that I don't would to
> implement, because it is oriented to by
Peter,
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
> Pavel originally included a
> constraint_schema field, because he figured that the way constraints
> are catalogued necessitated such a field.
That's exactly what I was getting at also- in order to do a lookup in
the catalog, you need to k
2012/12/29 Peter Geoghegan :
> On 29 December 2012 17:43, Stephen Frost wrote:
>> I'd like to see more options for what is logged, as I've mentioned in
>> the past, and I think all of these would be good candidates for logging
>> in some circumstances. The insistence on having one CSV format to r
On 29 December 2012 17:43, Stephen Frost wrote:
> I'd like to see more options for what is logged, as I've mentioned in
> the past, and I think all of these would be good candidates for logging
> in some circumstances. The insistence on having one CSV format to rule
> them all and which doesn't c
* Peter Geoghegan (pe...@2ndquadrant.com) wrote:
> On 28 December 2012 15:57, Tom Lane wrote:
> > I don't think that part's been agreed to at all; it seems entirely
> > possible that it'll get dropped if/when the patch gets committed.
> > I'm not convinced that having these fields in the log is wo
2012/12/29 Tom Lane :
> Peter Geoghegan writes:
>> On 29 December 2012 05:04, Pavel Stehule wrote:
So I'm with Peter G on this: the existing CONTEXT mechanism is good
enough, we do not need to split out selected sub-parts of that as
separate error fields. Moreover, doing so would
2012/12/29 Peter Geoghegan :
> On 29 December 2012 05:04, Pavel Stehule wrote:
>> again - it is reason why I propose ROUTINE_NAME and TRIGGER_NAME - it
>> can be useful for some use cases, where developer should to handle
>> exception when they coming from known functions/triggers and he would
>>
Peter Geoghegan writes:
> On 29 December 2012 05:04, Pavel Stehule wrote:
>>> So I'm with Peter G on this: the existing CONTEXT mechanism is good
>>> enough, we do not need to split out selected sub-parts of that as
>>> separate error fields. Moreover, doing so would provide only an utterly
>>>
Robert Haas writes:
> The other danger here is - what exactly do you mean by "no command has
> been able to run between the user command and our lookup"? Because
> you can do stupid things with functions like set_config(). This would
> only be safe if no user-provided expressions can possibly ge
On 27.12.2012 22:46, Alvaro Herrera wrote:
Heikki Linnakangas wrote:
Might be cleaner to directly assign the correct value to MaxBackends
above, ie. "MaxBackends = MaxConnections + newval + 1 +
GetNumShmemAttachedBgworkers()". With a comment to remind that it
needs to be kept in sync with the
Andres Freund writes:
> On 2012-12-29 07:23:24 -0500, Peter Eisentraut wrote:
>> The xlog code uses two different time zone formats at various times.
> One is a pg_time_t (stored in pg_control/ControlFileData), the other is
> a TimestampTz. Those have completely different code paths for being
> p
On 29 December 2012 05:04, Pavel Stehule wrote:
> again - it is reason why I propose ROUTINE_NAME and TRIGGER_NAME - it
> can be useful for some use cases, where developer should to handle
> exception when they coming from known functions/triggers and he would
> to raise exception, when it was rai
* Andres Freund (and...@2ndquadrant.com) wrote:
> I don't think autonomous transactions are the biggest worry
> here. Transactions essentially already span multiple databases, so thats
> not really a problem in this context. Making it possible to change
> catalogs while still being active in anothe
On 2012-12-29 09:59:49 -0500, Stephen Frost wrote:
> * Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> > It sounds to me like either autonomous transaction with the capability
> > to run the independant transaction in another database, or some dblink
> > creative use case. Another approach would
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> It sounds to me like either autonomous transaction with the capability
> to run the independant transaction in another database, or some dblink
> creative use case. Another approach would be to get plproxy into core
> as a Foreign Data Wrapper fo
On 12/29/2012 08:41 AM, Dimitri Fontaine wrote:
Well, do we have \! in psql in windows at all? does it work in a similar
way to the unix one? I just don't know.
Of course we do, Why ever would you think we don't? The command must be
written in the Windows shell language, but the behaviour i
Stephen Frost writes:
> I disagree. If we're going to have what are essentially 'global' event
> triggers, then they should go into a shared catalog- the user shouldn't
> be required to install them everywhere to get coverage. In addition,
I understand your view point, and if we think we will b
Dimitri,
* Dimitri Fontaine (dimi...@2ndquadrant.fr) wrote:
> I personnaly think that given a good documentation coverage having Event
> Trigger on global objects could be useful enough, even if you would have
> to install them in every database when you want them to fire no matter
> what.
I disa
On Sat, Dec 29, 2012 at 2:05 PM, Greg Stark wrote:
> I can't quite wrap my head around the idea of "LIKE" and collations
> having any meaningful interaction anyways. I certainly can't come up
> with anything better than "lower() like lower()" (or "upper() like
> upper()").
Hm. Maybe I spoke too f
Fabrízio de Royes Mello writes:
> Event triggers don't cover "CREATE DATABASE" statement.
The reason why is because you create Event Triggers in a specific
database and they only get run when you happen to be connected to that
specific database.
So for example say you install your Event Trigger
On Fri, Dec 28, 2012 at 11:41 PM, Tom Lane wrote:
> James Cloos writes:
>> Is there any contraindication to recasting:
>> foo ILIKE 'bar'
>> into:
>> LOWER(foo) LIKE LOWER('bar')
>
> In some locales those are not equivalent, I believe, or at least
> shouldn't be. (What the current code actua
Robert Haas writes:
> OK, I committed this.
Thanks. Please find attached a rebased patch, v6. I think it's looking
more like what you would expect now:
COLUMNS=70 git diff --stat postgres/master..
doc/src/sgml/event-trigger.sgml | 196 +++-
doc/src/sgml/plpgsql.sgml
Robert Haas writes:
> If I thought there were some useful code, I would try to see if we
> could contribute it, but I'm pretty sure there isn't. We have a bunch
Oh. Too bad.
[... description of the tool ...]
> I don't see a way to do the exact kind of testing we need here in a
> cross-platform
On Tue, Dec 25, 2012 at 1:42 PM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>>> Also, keep in mind we want the ObjectID in all CREATE, ALTER and DROP
>>> statements, so my current patch is still some bricks shy of a load… (I
>>> added ObjectID only in the commands I added rewrite support for,
On Sat, Dec 29, 2012 at 4:21 AM, Daniel Farina wrote:
> These were not express goals of the patch, but so long as you are
> inviting features, attached is a bonus patch that exposes the queryid
> and also the notion of a "statistics session" that is re-rolled
> whenever the stats file could not be
On Tue, Dec 25, 2012 at 10:34 AM, Dimitri Fontaine
wrote:
> Thank you for this partial commit, and Simon and Andres to fill in the
> gaps. I should mention that the missing header parts were all in my
> patch, and that headers hacking is proving suprisingly uneasy.
Apologies to all about the miss
On 2012-12-29 07:23:24 -0500, Peter Eisentraut wrote:
> The xlog code uses two different time zone formats at various times.
> Here is an example:
>
> 2012-12-29 07:04:07.338 EST LOG: database system was interrupted; last known
> up at 2012-12-29 06:27:02 EST
> 2012-12-29 07:04:26.347 EST LOG: l
The xlog code uses two different time zone formats at various times.
Here is an example:
2012-12-29 07:04:07.338 EST LOG: database system was interrupted; last known
up at 2012-12-29 06:27:02 EST
2012-12-29 07:04:26.347 EST LOG: last completed transaction was at log time
2012-12-29 06:34:24.39
Attached is a cumulative patch attempting to address the below. One
can see the deltas to get there at https://github.com/fdr/postgres.git
error-prop-pg_stat_statements-v2.
On Fri, Dec 28, 2012 at 9:58 AM, Peter Geoghegan wrote:
> However, with this approach, calls_underest values might appear t
> "TL" == Tom Lane writes:
JC>> Is there any contraindication to recasting:
JC>> foo ILIKE 'bar'
JC>> into:
JC>> LOWER(foo) LIKE LOWER('bar')
TL> In some locales those are not equivalent, I believe, or at least
TL> shouldn't be. (What the current code actually does is a separate
TL> questio
2012/12/28 Gavin Flower :
> On 29/12/12 10:19, Peter Eisentraut wrote:
>
> On 12/28/12 11:22 AM, Pavel Stehule wrote:
>
> I am not sure, but maybe is time to introduce ANSI SQL syntax for
> functions' named parameters
>
> It is defined in ANSI SQL 2011
>
> CALL P (B => 1, A => 2)
>
> instead Postg
77 matches
Mail list logo
