Tom Lane wrote:
> I'm of the opinion that this is a 9.1 problem. It needs more thought
> than we can put into it now --- one obvious question is what about
> monitoring on the slave side? Another is who should be able to see the
> data?
Sure. We should research user's demands for monitoring a
Robert Haas writes:
> ...but I'm still having a hard time wrapping my head around it.
The fundamental point is to be able to force a value to go to NULL
when outer-join logic says it ought to. Consider
CREATE VIEW foo AS SELECT x,y,'zed' FROM bar;
SELECT * FROM baz LEFT JOIN fo
Tom Lane wrote:
Andrew Dunstan writes:
Tom Lane wrote:
Well, having to do a cache lookup already makes it a couple orders of
magnitude more expensive than an OID comparison. However, it's hard to
say how much that matters in terms of total application performance.
We really could do
In pmdie(), we have the following code, which doesn't seem to make
much sense. If the state is PM_RECOVERY at the top of this section it
will get changed to PM_WAIT_BACKENDS and then to PM_WAIT_BACKENDS
again. Either the two "if" statements should be merged (and both bits
should be handled with t
On Mon, Jun 21, 2010 at 9:13 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> So none of the above sounds like desired behavior to me... is that just me?
>
> Yeah, I'm not really thrilled with this.. I mentioned earlier what I
> thought would be a useful feature (basica
* Robert Haas (robertmh...@gmail.com) wrote:
> So none of the above sounds like desired behavior to me... is that just me?
Yeah, I'm not really thrilled with this.. I mentioned earlier what I
thought would be a useful feature (basically, a switch which would
ignore the main psqlrc and turn on th
On Mon, Jun 21, 2010 at 7:51 PM, gabrielle wrote:
> On Thu, 2010-06-17 at 14:50 -0400, Alvaro Herrera asked:
>> How does it play with ON_ERROR_STOP/ROLLBACK?
>
> With ON_ERROR_STOP=ON, psql issues an error when it encounters one,
> stops processing the file that contains the error, and then contin
I've checked on this patch.
As you described at the source code comments as follows,
it is not portable except for Linux due to the getsockopt() API.
+ // TODO: currently Linux-only code, needs to be made
+ // portable; see backend/libpq/auth.c
I expect it shall be fi
On Thu, 2010-06-17 at 14:50 -0400, Alvaro Herrera asked:
> How does it play with ON_ERROR_STOP/ROLLBACK?
With ON_ERROR_STOP=ON, psql issues an error when it encounters one,
stops processing the file that contains the error, and then continues
to process any remaining files.
I'm still investigatin
On 15/06/10 10:31, Heikki Linnakangas wrote:
You could avoid changing the meaning of fn_expr by putting the check in
the parse analysis phase, into transformFuncCall(). That would feel
safer at least for back-branches.
Here's a patch using that approach.
I grepped through PostgreSQL and pgadmi
On Mon, 2010-06-21 at 18:46 +0200, Guillaume Lelarge wrote:
> Today, I tried to cancel the change of a tablespace for a table (ALTER
> TABLE ... SET TABLESPACE). I got the "Cancel request sent" but the query
> continued and finally succeed. It was a big issue for my customer, and I
> wanted to loo
On Mon, Jun 21, 2010 at 5:20 PM, Alexander Korotkov
wrote:
> 1) Make knngist deal with negative values. I think this will make easier
> using knngist just for sorting, not only k-neighbor searching.
It doesn't? I didn't think it was making any assumptions about the
ordering data type beyond the
On Mon, Jun 21, 2010 at 5:42 PM, Robert Haas wrote:
> It seems like you can get more or less the same benefit from a
> multicolumn btree index. On my system, with the individual btree
> indices, the query ran in 7625 ms; with an additional index on (v1,
> v2, v3), it ran in 94 ms. I didn't get
On Jun 21, 2010, at 11:47 AM, Kevin Grittner wrote:
> Yes, although the line endings are Windows format (CR/LF).
The line endings must have gotten changed in transit. My original diff used
just LF. I made it on a Mac.
> The only issue is with the general guideline to make the new code
> blend
On fre, 2010-06-11 at 08:07 -0400, Stephen Frost wrote:
> Having the option wouldn't do much unless users know of it and use it
> and it strikes that will very often not be the case.
That situation is the same as with SSL over TCP/IP with certificate
validation. I don't think we can make either o
I can't find any good documentation of this in the source tree
anywhere. placeholder.c just says:
*PlaceHolderVar and PlaceHolderInfo manipulation routines
and placeholder.h says:
*prototypes for optimizer/util/placeholder.c.
...which is less than informative. The commit mes
Tom, you are right: it is just more complicated.
In fact, I did not pretend to demonstrate that it was easier or faster
using one file per tape.
As you can remember, I just did not understand why you said it was
*impossible* to recycle space in that case.
So, the conclusion is: you can do rec
"mac_man2...@hotmail.it" writes:
> Of course, in this case, output blocks should be placed in the free
> space spread around the various files and we should keep track of this
> placement.
And once you've done that, what benefit have you got over the current
design? None that I can see. It's
Andy Balholm wrote:
> On May 30, 2010, at 6:53 AM, Kevin Grittner wrote:
>> You would then generate a diff in context format and post to the
>> -hackers list with that file as an attachment.
>
> Here it is
=
Submission review
=
* Is the patch in context diff
On 21/06/10 19:41, Marc G. Fournier wrote:
What is the recommended procedure for this?
For instance, normally I would do a dump, upgrade, reload, when dealing
with a single server, just to make sure all my system tables and such
are clean ... but, if I have HS/SR setup to a slave, what is the
re
Robert Haas writes:
> The point was that if you want to bikeshed, please do it on the OTHER
> thread, not this one. :-)
Ouch, asking for bikeshed and understanding what you read around… I
call that a trap ;)
--
dim
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On Jun 21, 2010, at 10:46 AM, Robert Haas wrote:
> I don't much like hstore(hstore, text[]) because it's not strictly a
> constructor. But I could certainly live with something based on the
> word slice. The existing SQL function backing the operator is called
> slice_hstore(), whereas I would p
"David E. Wheeler" writes:
> So, frankly, I'm coming back to what Florian has suggested here. What about
> calling it slice?
> hstore = slice(hstore, text[]);
+1, particularly seeing that our solution for the other two cases also
comes down to "use the function instead".
Robert Haas writes:
> On Mon, Jun 21, 2010 at 1:24 PM, Tom Lane wrote:
>> in particular, s/may/will/ and avoid passive voice in the second sentence.
> Avoiding the passive voice is a good idea, and I like your suggested
> phrasing. I'm reluctant to say what we "will" do in a future release
> be
On Mon, Jun 21, 2010 at 1:46 PM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>
>> By consensus, we have removed the new-to-9.0 operator text[] => text[]
>> and renamed the hstore => text[] operator. (The current name is "%",
>> but there is some discussion of "%>", some yet other name, or gett
On Mon, Jun 21, 2010 at 1:37 PM, David E. Wheeler wrote:
> On Jun 17, 2010, at 1:30 PM, Florian Pflug wrote:
>
>> How about turning it into a function
>> hstore hstore(hstore, text[])
>> instead?
>
> I just searched through the 2008 spec for a slice/subset operator and came up
> empty. It seem
Robert Haas writes:
> By consensus, we have removed the new-to-9.0 operator text[] => text[]
> and renamed the hstore => text[] operator. (The current name is "%",
> but there is some discussion of "%>", some yet other name, or getting
> rid of it altogether; please comment on that thread if you
On Jun 17, 2010, at 1:30 PM, Florian Pflug wrote:
> How about turning it into a function
>hstore hstore(hstore, text[])
> instead?
I just searched through the 2008 spec for a slice/subset operator and came up
empty. It seems to define a bunch of predicates for multisets, but not much for
ar
On Mon, Jun 21, 2010 at 1:24 PM, Tom Lane wrote:
> Robert Haas writes:
>> Barring vigorous objections, I will apply these tomorrow so that we
>> can consider deprecating => as an operator name in 9.1, for better
>> compliance with the SQL standard.
>
> Two documentation comments:
>
> 1. Perhaps,
Robert Haas writes:
> Barring vigorous objections, I will apply these tomorrow so that we
> can consider deprecating => as an operator name in 9.1, for better
> compliance with the SQL standard.
Two documentation comments:
1. Perhaps, rather than
> + The => operator is deprecated and may be r
On Mon, 2010-06-21 at 12:04 -0500, Kevin Grittner wrote:
> Peter Geoghegan wrote:
>
> > In my experience, lookup tables generally have two columns, an
> > integer PK and a description/state.
>
> Eek. If that's what you consider a lookup table, I wouldn't
> advocate their use for anything. Ev
Il 21/06/2010 04:25, Tom Lane ha scritto:
No. You could do that if the rate at which you need to write data to
the file is<= the rate at which you extract it. But for what we
are doing, namely merging runs from several tapes into one output run,
it's pretty much guaranteed that you need new spa
Peter Geoghegan wrote:
> In my experience, lookup tables generally have two columns, an
> integer PK and a description/state.
Eek. If that's what you consider a lookup table, I wouldn't
advocate their use for anything. Ever. Period.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-h
On Mon, Jun 21, 2010 at 12:37 PM, David E. Wheeler wrote:
>> Barring vigorous objections, I will apply these tomorrow so that we
>> can consider deprecating => as an operator name in 9.1, for better
>> compliance with the SQL standard.
>
> So will the CREATE OPERATOR code be updated to issue the w
On Mon, Jun 21, 2010 at 12:40 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of lun jun 21 12:20:59 -0400 2010:
>
>> Barring vigorous objections, I will apply these tomorrow so that we
>> can consider deprecating => as an operator name in 9.1, for better
>> compliance with the SQL
Hi,
Today, I tried to cancel the change of a tablespace for a table (ALTER
TABLE ... SET TABLESPACE). I got the "Cancel request sent" but the query
continued and finally succeed. It was a big issue for my customer, and I
wanted to look more into that issue. So, I got a look at the source code
and
On Sun, Jun 20, 2010 at 5:52 PM, Tom Lane wrote:
>> On a quick read, I think I see a problem with this: if a parameter is
>> specified with a non-zero value and there is no OS support available
>> for that parameter, it's an error. Presumably, for our purposes here,
>> we'd prefer to simply ignor
What is the recommended procedure for this?
For instance, normally I would do a dump, upgrade, reload, when dealing
with a single server, just to make sure all my system tables and such are
clean ... but, if I have HS/SR setup to a slave, what is the recommended
method of doing an upgrade?
Excerpts from Robert Haas's message of lun jun 21 12:20:59 -0400 2010:
> Barring vigorous objections, I will apply these tomorrow so that we
> can consider deprecating => as an operator name in 9.1, for better
> compliance with the SQL standard.
Maybe this is just a matter of semantics, but I tho
On Jun 21, 2010, at 9:20 AM, Robert Haas wrote:
> Per that email, and subsequent concurrence, here is a series of
> patches which does the following:
>
> 1. In CVS HEAD, document the hstore(text, text) function and adjust
> CREATE OPERATOR to throw a warning when => is used as an operator
> name,
Tom Lane wrote:
Adding cache
lookups for the enum rows to the comarison routines made a REINDEX on a
1m row table where the index is on an enum column (the enum has 500
randomly ordered labels) jump from around 10s to around 70s.
Hmmm... that's bad, but I bet it's still less than the c
By consensus, we have removed the new-to-9.0 operator text[] => text[]
and renamed the hstore => text[] operator. (The current name is "%",
but there is some discussion of "%>", some yet other name, or getting
rid of it altogether; please comment on that thread if you wish to
weigh in.) This mean
Andrew Dunstan writes:
> Tom Lane wrote:
>> Well, having to do a cache lookup already makes it a couple orders of
>> magnitude more expensive than an OID comparison. However, it's hard to
>> say how much that matters in terms of total application performance.
>> We really could do with a bit of p
Robert Haas writes:
> Is there really a point to the non-DSN format or should we just use
> the DSN format always?
BTW, didn't have an opinion on that to start with, but after thinking
about it I'd turn it around. psql doesn't deal in DSN format anywhere
else, so why should it do so here? To ma
Tom Lane wrote:
Andrew Dunstan writes:
Another thought: could we add a column to pg_type with a flag that's
true if the oids are in sort order? Then the comparison routines could
just look that up in the type cache and if it's true (as it often will
be) just return the oid comparison.
Robert Haas writes:
> On Sun, Jun 20, 2010 at 10:51 PM, Steve Singer
> wrote:
>> One comment I have on the output format is that values (ie the database
>> name) are enclosed in double quotes but the values being quoted can contain
>> double quotes that are not being escaped.
This is the same a
On Mon, 2010-06-21 at 18:08 +0900, Fujii Masao wrote:
> The problem is not that the master streams non-fsync'd WAL, but that the
> standby can replay that. So I'm thinking that we can send non-fsync'd WAL
> safely if the standby makes the recovery wait until the master has fsync'd
> WAL. That is,
On Mon, Jun 21, 2010 at 5:19 AM, Thom Brown wrote:
> I can't answer this, but is anyone else able to provide Alexander some
> feedback?
It seems like you can get more or less the same benefit from a
multicolumn btree index. On my system, with the individual btree
indices, the query ran in 7625
On Mon, Jun 21, 2010 at 12:20 AM, Ron Mayer
wrote:
> Robert Haas wrote:
>> On Wed, Jun 16, 2010 at 9:56 PM, Tom Lane wrote:
>>> Sorry, I've been a bit distracted by other responsibilities (libtiff
>>> security issues for Red Hat, if you must know). I'll get on it shortly.
>>
>> What? You have o
On Mon, Jun 21, 2010 at 10:40 AM, Heikki Linnakangas
wrote:
> I guess, but you have to be very careful to correctly refrain from applying
> the WAL. For example, a naive implementation might write the WAL to disk in
> walreceiver immediately, but refrain from telling the startup process about
> it
On Mon, Jun 21, 2010 at 4:37 AM, Greg Stark wrote:
> On Mon, Jun 21, 2010 at 4:54 AM, Robert Haas wrote:
>> I feel like we're getting off in the weeds, here. Obviously, the user
>> would ideally like the connection to the master to last forever, but
>> equally obviously, if the master unexpected
On 21/06/10 12:08, Fujii Masao wrote:
On Wed, Jun 16, 2010 at 5:06 AM, Robert Haas wrote:
In 9.0, I think we can fix this problem by (1) only streaming WAL that
has been fsync'd and (2) PANIC-ing if the problem occurs anyway. But
in 9.1, with sync rep and the performance demands that entails,
On 6 June 2010 21:04, Alexander Korotkov wrote:
> Hello hackers,
> I would like to share some my thoughts about usage of multidimensional
> indexes for queries which deal with ordinal unidimensional data types. I
> think that gist indexes (especially with knngist) can produce great benefit
> for c
On Wed, Jun 16, 2010 at 5:06 AM, Robert Haas wrote:
> On Tue, Jun 15, 2010 at 3:57 PM, Josh Berkus wrote:
>>> I wonder if it would be possible to jigger things so that we send the
>>> WAL to the standby as soon as it is generated, but somehow arrange
>>> things so that the standby knows the last
On Mon, Jun 21, 2010 at 4:54 AM, Robert Haas wrote:
> I feel like we're getting off in the weeds, here. Obviously, the user
> would ideally like the connection to the master to last forever, but
> equally obviously, if the master unexpectedly reboots, they'd like the
> slave to notice - ideally w
55 matches
Mail list logo
