On 17 June 2012 08:26, Tom Lane wrote:
> (1) In backend_read_statsfile, make an initial attempt to read the stats
> file and then read GetCurrentTimestamp after that. If the local clock
> reading is less than the stats file's timestamp, we know that some sort
> of clock skew or glitch has happen
On Sat, Jun 16, 2012 at 11:15 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> On Sat, Jun 16, 2012 at 12:55 PM, Tom Lane wrote:
>>> It's not obvious to me that we actually *need* anything except the
>>> ability to recognize that a null-encrypted SSL connection probably
>>> shouldn't be treated
On 16 June 2012 23:09, Tom Lane wrote:
> Marko Kreen writes:
>>> Now, looking at the problem with some perspective, the solution
>>> is obvious: when in single-row mode, the PQgetResult() must return
>>> proper PGresult for that single row. And everything else follows that.
>>>
>>> * PQgetRowDat
On Sat, Jun 16, 2012 at 7:58 PM, Marko Kreen wrote:
> So my preference would be to simply remove the callback API
> but keep the processing and provide PQgetRowData() instead.
This is implemented in attached patch. It also
converts dblink to use single-row API.
The patch should be applied on to
IMO, both approaches make sense...
>From temporal point no doubt, referencing should be contained by
referenced table
>From other side could be useful if in master table are elements with
simple data type, but for some set of elements there could be common
properties in another table.. What t
On Sun, Jun 17, 2012 at 2:07 PM, Simon Riggs wrote:
> I prefer the description of Marko's API than the one we have now.
>
> Adopting one API in 9.2 and another in 9.3 would be fairly bad.
> Perhaps we can have both?
I see no reason the keep the (public) callback API around,
except if we don't bot
On 17 June 2012 19:37, Marko Kreen wrote:
> On Sun, Jun 17, 2012 at 2:07 PM, Simon Riggs wrote:
>> I prefer the description of Marko's API than the one we have now.
>>
>> Adopting one API in 9.2 and another in 9.3 would be fairly bad.
>> Perhaps we can have both?
>
> I see no reason the keep the
On 17 June 2012 19:16, Misa Simic wrote:
> IMO, both approaches make sense...
Agreed.
It's also a good reason to do as Peter suggests and come up with a
better description than just EACH.
Do we need something like Exclusion FKs? i.e. the FK partner of
Exclusion Constraints?
--
Simon Riggs
On Sun, Jun 17, 2012 at 12:13 AM, Dimitri Fontaine
wrote:
> Magnus Hagander writes:
>> This is copied from the old documentation. It used to say "It is not
>> necessary to be concerned about the amount of time elapsed between
>> pg_start_backup and the start of the actual backup, nor between the
Simon Riggs wrote:
Misa Simic wrote:
>> IMO, both approaches make sense...
>
> Agreed.
Can someone provide a practical example of a "foreign key with array"
use case? The only situations I'm able to think of right now are the
same cases where you would now use a table with primary keys of tw
2012/6/17 Simon Riggs
>
> Do we need something like Exclusion FKs? i.e. the FK partner of
> Exclusion Constraints?
>
+1
Definatelly it would be something usefull... Today's workaround to achieve
that with additional table, and additional column in Key is a bit
awkward...
>
> --
> Simon Riggs
2012/6/17 Kevin Grittner
>
>
> Can someone provide a practical example of a "foreign key with array"
> use case? The only situations I'm able to think of right now are the
> same cases where you would now use a table with primary keys of two
> tables to provide a many-to-many linkage. Does this
The fly in the ointment for strxfrm() adoption may be the need to be
consistent with this earlier behaviour:
commit 656beff59033ccc5261a615802e1a85da68e8fad
Author: Tom Lane
Date: Thu Dec 22 22:50:00 2005 +
Adjust string comparison so that only bitwise-equal strings are considered
Simon Riggs writes:
> Fine, but please log this as a WARNING system time skew detected, so
> we can actually see it has happened rather than just silently
> accepting the situation.
I think elog(LOG) is more appropriate, same as we have for the existing
messages for related complaints. No one ba
Magnus Hagander writes:
> Is there a reason why we don't have a parameter on the client
> mirroring ssl_ciphers?
Dunno, do we need one? I am not sure what the cipher negotiation process
looks like or which side has the freedom to choose.
> That, or just have DEFAULT as being the default (which
On Sun, Jun 17, 2012 at 11:42 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> Is there a reason why we don't have a parameter on the client
>> mirroring ssl_ciphers?
>
> Dunno, do we need one? I am not sure what the cipher negotiation process
> looks like or which side has the freedom to choose
On Sun, Jun 17, 2012 at 4:45 PM, Magnus Hagander wrote:
> On Sun, Jun 17, 2012 at 11:42 PM, Tom Lane wrote:
>> Magnus Hagander writes:
>>> Is there a reason why we don't have a parameter on the client
>>> mirroring ssl_ciphers?
>>
>> Dunno, do we need one? I am not sure what the cipher negotiat
Peter Geoghegan writes:
> The fly in the ointment for strxfrm() adoption may be the need to be
> consistent with this earlier behaviour:
> if strcoll claims two strings are equal, check it with strcmp, and
> sort according to strcmp if not identical.
> I'm not sure I agree with this deci
On Sun, Jun 17, 2012 at 09:58:17AM -0500, Kevin Grittner wrote:
> Simon Riggs wrote:
> Misa Simic wrote:
>
> >> IMO, both approaches make sense...
> >
> > Agreed.
>
> Can someone provide a practical example of a "foreign key with array"
> use case? The only situations I'm able to think of ri
On Jun16, 2012, at 17:15 , Tom Lane wrote:
> Magnus Hagander writes:
>> On Sat, Jun 16, 2012 at 12:55 PM, Tom Lane wrote:
>>> It's not obvious to me that we actually *need* anything except the
>>> ability to recognize that a null-encrypted SSL connection probably
>>> shouldn't be treated as match
Florian Pflug writes:
> Would we still tell openssl to only negotiate ciphers in the configured
> list of available ciphers + NULL? If not, what happens if a connection
> happens to use a cipher that is actually stronger than any cipher on
> the "list of acceptable ciphers" list? The DBA wouldn't
On 17 June 2012 17:01, Tom Lane wrote:
>> I'm not sure I agree with this decision; why should we presume to know
>> better than the glibc locale what constitutes equality?
>
> The killer reason why it must be like that is that you can't use hash
> methods on text if text equality is some unknown c
Peter Geoghegan writes:
> On 17 June 2012 17:01, Tom Lane wrote:
>> The killer reason why it must be like that is that you can't use hash
>> methods on text if text equality is some unknown condition subtly
>> different from bitwise equality.
> Fair enough, but I doubt that we need to revert the
On 17-06-2012 12:42, Tom Lane wrote:
> If our default isn't the same as the underlying default, I have to
> question why not. But are you sure this "!" notation will work with
> all openssl versions?
>
What is all for you? It seems we don't claim support for an specific version
or later in docs o
On 17-06-2012 12:45, Magnus Hagander wrote:
> Uh. We have the ! notation in our default *now*. What openssl also
> supports is the text "DEFAULT", which is currently the equivalent of
> "ALL!aNULL!eNULL". The question, which is valid of course, should be
> if "DEFAULT" works with all openssl versio
On Sat, Jun 16, 2012 at 9:50 AM, Dean Rasheed wrote:
Then in HEAD:
> EXPLAIN ANALYSE UPDATE fk_table SET b=b+1, c=c+1, d=d+1;
>
> QUERY PLAN
>
>
On 17-06-2012 12:45, Magnus Hagander wrote:
> On Sun, Jun 17, 2012 at 11:42 PM, Tom Lane wrote:
>> Magnus Hagander writes:
>>> Is there a reason why we don't have a parameter on the client
>>> mirroring ssl_ciphers?
>>
>> Dunno, do we need one? I am not sure what the cipher negotiation process
>
Gurjeet Singh wrote:
> Dean Rasheed wrote:
> in HEAD:
>> ... (actual time=1390.037..1390.037 rows=0 loops=1)
>> Trigger for constraint fk_table_e_fkey: time=210.184 calls=9
>> Total runtime: 1607.626 ms
>> With this patch:
>> ... (actual time=1489.640..1489.640 rows=0 loops=1)
>> [no trigg
On Sun, 2012-06-17 at 21:10 +0800, Simon Riggs wrote:
> Do we need something like Exclusion FKs? i.e. the FK partner of
> Exclusion Constraints?
Yes, "Inclusion Constraints". I've known we need something like that
since I did Exclusion Constraints, but I haven't gotten further than
that.
Regards,
Gurjeet Singh writes:
> On Sat, Jun 16, 2012 at 9:50 AM, Dean Rasheed wrote:
> I find it interesting that 'actual time' for top level 'Update on fk_table'
> is always higher in patched versions, and yet the 'Total runtime' is lower
> for the patched versions. I would've expected 'Total runtime' to
"Kevin Grittner" writes:
> I figured that the trigger time was counted separately.
Yeah, it is.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Jun 17, 2012 5:50 PM, "Tom Lane" wrote:
>
> Peter Geoghegan writes:
> > On 17 June 2012 17:01, Tom Lane wrote:
> How exactly do you plan to shoehorn that into SQL? You could invent
> some nonstandard "equivalence" operator I suppose, but what will be the
> value? We aren't going to set thin
On Sat, Jun 16, 2012 at 9:00 PM, wrote:
> I've always used -1-f - < file.sql. It is confusing that -1 doesn't warn you
> when it wont work though.
Yeah, I just got bitten by that one. Definitely violates the POLA.
Cheers,
Jeff
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
Simon,
> The "major limitation" was solved by repmgr close to 2 years ago now.
> So while you're correct that the patch to fix that assumed that
> archiving worked as well, it has been possible to operate happily
> without it.
repmgr is not able to remaster using only streaming replication. It
a
> Instead of using re-synchronization (e.g. repmgr in its relation to
> rsync), I intend to proxy and also inspect the streaming replication
> traffic and then quiesce all standbys and figure out what node is
> farthest ahead. Once I figure out the node that is farthest ahead, if
> it is not a no
Peter Geoghegan writes:
> Right, most people won't care. You may or may not want a new
> Operator for equivalency. The regular operator for equality doesn't have to
> and shouldn't change. It is both useful and conceptually clean to not
> guarantee that a compator can be relied upon to indicate eq
On Sun, Jun 17, 2012 at 1:11 PM, Josh Berkus wrote:
>
>> Instead of using re-synchronization (e.g. repmgr in its relation to
>> rsync), I intend to proxy and also inspect the streaming replication
>> traffic and then quiesce all standbys and figure out what node is
>> farthest ahead. Once I figur
I'm giving 9.2-beta2 a test simulating a production workflow.
Everything looks OK except the speed. Most (all?) queries take about
five to six times as long as they do with 9.1.
The configurations are essentially the same, the query plans are the same.
A (hot) example, pulled semi-randomly from
On 17 June 2012 21:26, Tom Lane wrote:
> Sure, and in general we only expect that "=" operators mean equivalency;
> a concrete example is float8 "=", which on IEEE-spec machines will say
> that zero and minus zero are equal.
Right; the spec says that, and we punt to the spec. No one sensible
thin
Hi,
On Monday, June 18, 2012 12:51:51 AM James Cloos wrote:
> I'm giving 9.2-beta2 a test simulating a production workflow.
>
> Everything looks OK except the speed. Most (all?) queries take about
> five to six times as long as they do with 9.1.
>
> The configurations are essentially the same,
On sön, 2012-06-17 at 18:51 -0400, James Cloos wrote:
> I think I recall mention from a previous beta (but goog isn't helping
> me confirm) that there is some extra debugging or such enabled in the
> betas.
That depends on how you built it. Just being a beta by itself doesn't
turn on any extra de
On lör, 2012-06-16 at 16:21 +0800, Quan Zongliang wrote:
> I found that lower case is less than upper case when the db is
> created
> with utf8.
> I tried below
> locale en_US.utf8 'A'<'a' false
> locale ja_JP.utf8 'A'<'a' true
> locale zh_CN.utf8 'A'<'a' fal
On 17 June 2012 23:58, Peter Geoghegan wrote:
> We can decree that equivalency implies equality, or make all this
> internal (which, perversely, I suppose the C++ committee people
> cannot).
Sorry, that should obviously read "equality implies equivalency". We
may not have to decree it, because it
Peter Geoghegan writes:
> ISTM if '=' was really a mere equivalency operator, we'd only every
> check (a < b && b < a) in the btree code.
You're not really making a lot of sense here, or at least I'm not
grasping the distinction you want to draw. btree indexes (and sorting
in general) require th
> "AF" == Andres Freund writes:
AF> Is it possible that you compiled with assertions enabled? That would
roughly
AF> fit that magnitude. SHOW debug_assertions; Should show you whether it was
AF> enabled.
Thanks, but SHOW debug_assertions reports off.
-JimC
--
James Cloos OpenPG
> "PE" == Peter Eisentraut writes:
PE> That depends on how you built it. Just being a beta by itself doesn't
PE> turn on any extra debugging.
OK. So either I misremembered or it was something no longer done.
PE> That depends on how you built it.
Its a Gentoo box; both were build from the
On 12-06-13 01:27 PM, Andres Freund wrote:
The previous mail contained a patch with a mismerge caused by reording
commits. Corrected version attached.
Thanks to Steve Singer for noticing this quickly.
Attached is a more complete review of this patch.
I agree that we will need to identify the
I wrote:
> Anybody have DB2, or something else that might be thought to be pretty
> close to spec-compliant?
Remarkably enough, the DB2 10.1 manuals at www.ibm.com say that it
doesn't support ON UPDATE SET NULL or ON UPDATE SET DEFAULT. I'm
disappointed in them :-(. But anyway it seems that we'l
On 2012/6/18 7:13, Peter Eisentraut wrote:
On lör, 2012-06-16 at 16:21 +0800, Quan Zongliang wrote:
I found that lower case is less than upper case when the db is
created
with utf8.
I tried below
locale en_US.utf8 'A'<'a' false
locale ja_JP.utf8 'A'<'a' true
loc
[Hope it's OK if I move this thread to -hackers, as part of CF review.]
On Sat, Jun 9, 2012 at 2:40 AM, Dean Rasheed wrote:
> Hi,
>
> I noticed this while testing 9.2, but it seems to go back to at least
> 8.3. Tab completion of function arguments doesn't work if the function
> is schema-qualifie
I wrote:
> On balance I think we ought to switch to set-all-the-columns, though
> only in 9.3+ --- a back-patched behavioral change doesn't seem like a
> good idea.
And here is a draft patch for that. I was interested to find that the
documentation already claims that all columns are set in the r
On Fri, Jun 15, 2012 at 8:49 PM, Magnus Hagander wrote:
>> I agree that pg_backup_in_progress() is confusing, if it returns false while
>> you're running pg_basebackup. In the doc changes you proposed, you call the
>> pg_start/stop_backup() a "low level API" for taking backups. That's not
>> suita
52 matches
Mail list logo
