* Tom Lane (t...@sss.pgh.pa.us) wrote:
> On looking closer, though, it's *still* messy and unobvious :-(.
> There is no single place in the parser where we have the complete
> multi-level query tree available in a convenient form for this sort of
> postprocessing.
That's unfortunate. :/
> I've th
KaiGai Kohei writes:
> Stephen Frost wrote:
>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>>> On the whole I think we have to go back to the original plan of
>>> recursively searching the query's expressions after we've finished all
>>> the transformations (and have a completed jointree to refer to).
Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> On the whole I think we have to go back to the original plan of
>> recursively searching the query's expressions after we've finished all
>> the transformations (and have a completed jointree to refer to). This
>> is slightly annoyin
Robert Treat wrote:
> also, I forget which way is proper, but you're inconsistent with your closing
> tags for in that paragraph (using both )
They're both acceptable.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc
On Tuesday 20 January 2009 20:22:10 Bryce Nesbitt wrote:
> This is a proposed patch to document disabling the statistics collector
> pg_dump activity, and give a bit more visibility to the PGOPTIONS
> environment variable supported by libpq.
>
> It is an alternative to the prior patch, which suppli
This is a proposed patch to document disabling the statistics collector
pg_dump activity, and give a bit more visibility to the PGOPTIONS
environment variable supported by libpq.
It is an alternative to the prior patch, which supplied a --no-stats flag.
This is a documentation only patch, not
Josh Berkus wrote:
I'd argue that it is generally desired (or some convenient workaround)
but not urgently so. I'd also argue that if we're going to have a
--no-stats flag, it should exist for the other client ultilites as
well; if I don't want pg_dump showing up, I probably don't want Vacuum
On Tue, 2009-01-20 at 18:37 -0500, Tom Lane wrote:
> Josh Berkus writes:
> > Bruce,
> >> If this is a generally desired feature (and I question that), I think we
> >> need a more general solution.
>
> > I'd argue that it is generally desired (or some convenient workaround)
> > but not urgently s
On Tue, 2009-01-20 at 18:08 -0500, Robert Treat wrote:
> > The patch could benefit further from input from other various hackers,
> > what couldn't? It's time to put this in a shared repository (of some
> > kind) and make further changes to it in a controlled manner.
> >
>
> Yep. I've now got th
Josh Berkus writes:
> Bruce,
>> If this is a generally desired feature (and I question that), I think we
>> need a more general solution.
> I'd argue that it is generally desired (or some convenient workaround)
> but not urgently so.
One person asking for it does not make it "generally desired"
On Friday 16 January 2009 19:16:42 Simon Riggs wrote:
> Bruce asked for 2 more weeks to get patches into shape for commit.
>
> Current patch v8e is attached here. Ready for commit? Up to you.
>
> My overall opinion is that it's in very good shape. Worth the community
> including it in this release
Bruce,
If this is a generally desired feature (and I question that), I think we
need a more general solution.
I'd argue that it is generally desired (or some convenient workaround)
but not urgently so. I'd also argue that if we're going to have a
--no-stats flag, it should exist for the oth
Andrew Chernow wrote:
The only problem is how to detect the first connection. In a threaded
environment you'd have to perform locking in connectdb, which is
probably not going to fly.
Well, if you do an atomic test for a flag being zero, and if so then
enter a critsec, do
the init iff you're t
Bruce Momjian wrote:
Jaime Casanova wrote:
i haven't looked at the patch nor it's functional use... but from the
top of my head jumps a question: is there a reason to not make this
the default behaviour?
If this is a generally desired feature (and I question that), I think we
need a mor
On Tue, 20 Jan 2009, Bryce Nesbitt wrote:
This patch adds another flag to pg_dump, this time to disable statistics
collection.
You can pass session parameters to anything that uses the standard libpq
library using PGOPTIONS. See
http://www.postgresql.org/docs/8.3/static/config-setting.html
Tom Lane wrote:
Peter Eisentraut writes:
The SQL standard uses a recursive-by-default language. For example, the
rules for the DELETE command state:
Actually, I'm not convinced. Take a look at the SELECT WITH HIERARCHY
OPTION stuff in SQL99 and later, in particular this from SQL99
Jaime Casanova wrote:
> On Tue, Jan 20, 2009 at 4:04 PM, Bryce Nesbitt wrote:
> > This patch adds another flag to pg_dump, this time to disable statistics
> > collection. This is useful if your don't want pg_dump activity to show (or
> > clutter) your normal statistics. This may be appropriate f
Simon Riggs escreveu:
> On Tue, 2009-01-20 at 21:51 +0200, Heikki Linnakangas wrote:
>
>> Attached is a simple patch to only start skipping pages after 20
>> consecutive pages marked as visible in the visibility map. This doesn't
>> do any "look-ahead", so it will always scan the first 20 pages
Peter Eisentraut writes:
> The SQL standard uses a recursive-by-default language. For example, the
> rules for the DELETE command state:
Actually, I'm not convinced. Take a look at the SELECT WITH HIERARCHY
OPTION stuff in SQL99 and later, in particular this from SQL99
12.2 :
7) Let
On Tue, Jan 20, 2009 at 4:04 PM, Bryce Nesbitt wrote:
> This patch adds another flag to pg_dump, this time to disable statistics
> collection. This is useful if your don't want pg_dump activity to show (or
> clutter) your normal statistics. This may be appropriate for an
> organization that regu
This patch adds another flag to pg_dump, this time to disable statistics
collection. This is useful if your don't want pg_dump activity to show
(or clutter) your normal statistics. This may be appropriate for an
organization that regularly dumps a database for backup purposes, but
wants to an
On Tue, 2009-01-20 at 21:51 +0200, Heikki Linnakangas wrote:
> Attached is a simple patch to only start skipping pages after 20
> consecutive pages marked as visible in the visibility map. This doesn't
> do any "look-ahead", so it will always scan the first 20 pages of a
> table before it star
Simon Riggs wrote:
I did want you to commit those changes, but that was 8 days ago and much
has changed since then. Now, I'm slightly worried that this may be a
retrograde step. The last 3 days I've been refactoring the code to
account for other requirements, as I have been discussing, and some o
Simon Riggs wrote:
On Tue, 2009-01-20 at 11:03 +0200, Heikki Linnakangas wrote:
- Are there some conditions where whole-table-scanning vacuum is
more
effective than vacuums using visibility map? If so, we should
switch
to full-scan *automatically*, without relying on user
configurations
On Tue, 2009-01-20 at 21:01 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > It would be useful to nibble away at the patch, committing all the
> > necessary refactorings to make the patch work. That will reduce size of
> > eventual commit.
>
> I committed this part now; one less thing t
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> ... btw, what is the reasoning behind the special cases for SELECT FOR
> UPDATE in execMain.c?
Basically, because the original logic allowed SELECT-FOR-UPDATE if you
only had SELECT rights, which wasn't right.
> If there actually is a need to treat SELECT
Simon Riggs wrote:
It would be useful to nibble away at the patch, committing all the
necessary refactorings to make the patch work. That will reduce size of
eventual commit.
I committed this part now; one less thing to review. Please adjust the
patch accordingly.
--
Heikki Linnakangas
E
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> On the whole I think we have to go back to the original plan of
> recursively searching the query's expressions after we've finished all
> the transformations (and have a completed jointree to refer to). This
> is slightly annoying on the grounds of adding
... btw, what is the reasoning behind the special cases for SELECT FOR
UPDATE in execMain.c?
/* Check if this is SELECT-FOR-UPDATE and handle
* accordingly. */
if(remainingPerms & ACL_UPDATE &&
pg_attribute_ac
Hiroshi Inoue wrote:
Magnus Hagander wrote:
Hiroshi Inoue wrote:
Hiroshi Inoue wrote:
Bruce Momjian wrote:
Hiroshi, is this patch still needed?
Yes though it should be slightly changed now.
In what way should it be changed?
One is already committed by you.
[COMMITTERS] pgsql: Use the ne
On Tue, 2009-01-20 at 11:03 +0200, Heikki Linnakangas wrote:
> > - Are there some conditions where whole-table-scanning vacuum is
> more
> > effective than vacuums using visibility map? If so, we should
> switch
> > to full-scan *automatically*, without relying on user
> configurations.
>
> H
Magnus Hagander wrote:
Hiroshi Inoue wrote:
Magnus Hagander wrote:
There still needs to be some error checking added in IsoLocaleName(),
but this is a start.
Can someone please test this? :-)
OK I would check it tonight.
Thanks.
OK seems to works here.
The attached is a test case using lc
On Mon, 2009-01-19 at 19:53 +0300, Teodor Sigaev wrote:
> I see only two guaranteed solution of the problem:
> - after limit is reached, force normal index inserts. One of the motivation
> of
> patch was frequent question from users: why update of whole table with GIN
> index
> is so slow? So t
Stephen Frost writes:
> Attached is an updated patch for column-level privileges.
I'm working on getting this committed. I've run into a major stumbling
block in the parse-time marking of columns for SELECT privileges: the
do-it-as-the-Vars-get-transformed approach basically doesn't work as-is
On Tuesday 20 January 2009 18:09:51 Merlin Moncure wrote:
> On 1/20/09, Peter Eisentraut wrote:
> > integer[] is "array of integer", in the way C deals with arrays. This
> > is also a main reason why composite types and arrays don't mix
> > orthogonally; there is no way to represent that in the
Tom Lane wrote:
> "Pavel Stehule" writes:
> > It's strange, when I repeat tests, I get usually times about 10 ms,
> > but cca cca every 5 test it is about 2ms
>
> Hmm. The theory I'd developed for what I see here is that the "slow"
> timings correspond to when the pgstat code decides it needs a
Bruce Momjian wrote:
Tom Lane wrote:
"Pavan Deolasee" writes:
OTOH I think we can still set PD_ALL_VISIBLE page header flag even
when there are DEAD line pointers.
That would mean the header flag means something different than the
map bit does, which would mean extra tests need to be made bef
Where are we on this? I tested CVS and the problem still seems to
exist.
---
Tom Lane wrote:
> The proximate cause of this complaint:
> http://archives.postgresql.org/pgsql-general/2008-12/msg00283.php
> seems to be that th
Bruce Momjian wrote:
Pavan Deolasee wrote:
On Mon, Dec 8, 2008 at 11:33 AM, Pavan Deolasee wrote:
On Sat, Dec 6, 2008 at 8:08 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
If you see a straightforward way, please submit a patch!
Will do that.
Here is a patch whi
Andrew Chernow wrote:
> Bruce Momjian wrote:
> > Andrew Chernow wrote:
> >> Bruce Momjian wrote:
> >>> Andrew Chernow wrote:
> Bruce Momjian wrote:
> > Ah, OK, so it does its own cleanup on last close, great. I agree a
> > connection option for this would be good.
> >
> What w
Bruce Momjian wrote:
Andrew Chernow wrote:
Bruce Momjian wrote:
Andrew Chernow wrote:
Bruce Momjian wrote:
Ah, OK, so it does its own cleanup on last close, great. I agree a
connection option for this would be good.
What would the option be? "wsainit = [enable | disable]"? Maybe it
should
Tom Lane wrote:
> "Pavan Deolasee" writes:
> > OTOH I think we can still set PD_ALL_VISIBLE page header flag even
> > when there are DEAD line pointers.
>
> That would mean the header flag means something different than the
> map bit does, which would mean extra tests need to be made before
> pro
Pavan Deolasee wrote:
> On Mon, Dec 8, 2008 at 11:33 AM, Pavan Deolasee
> wrote:
>
> >
> >
> > On Sat, Dec 6, 2008 at 8:08 PM, Heikki Linnakangas <
> > heikki.linnakan...@enterprisedb.com> wrote:
> >
> >>
> >> If you see a straightforward way, please submit a patch!
> >>
> >>
> > Will do that.
>
Andrew Chernow wrote:
> Bruce Momjian wrote:
> > Andrew Chernow wrote:
> >> Bruce Momjian wrote:
> >>> Ah, OK, so it does its own cleanup on last close, great. I agree a
> >>> connection option for this would be good.
> >>>
> >> What would the option be? "wsainit = [enable | disable]"? Maybe it
Andrew Dunstan wrote:
>
>
> Andrew Chernow wrote:
> > Andrew Chernow wrote:
> >> Bruce Momjian wrote:
> >>>
> >>> Ah, OK, so it does its own cleanup on last close, great. I agree a
> >>> connection option for this would be good.
> >>>
> >>
> >> What would the option be? "wsainit = [enable | disa
Bruce Momjian wrote:
Andrew Chernow wrote:
Bruce Momjian wrote:
Ah, OK, so it does its own cleanup on last close, great. I agree a
connection option for this would be good.
What would the option be? "wsainit = [enable | disable]"? Maybe it
should allow setting the version to load: "wsa_vers
Andrew Chernow wrote:
Andrew Chernow wrote:
Bruce Momjian wrote:
Ah, OK, so it does its own cleanup on last close, great. I agree a
connection option for this would be good.
What would the option be? "wsainit = [enable | disable]"? Maybe it
should allow setting the version to load: "ws
Andrew Chernow wrote:
> Bruce Momjian wrote:
> >
> > Ah, OK, so it does its own cleanup on last close, great. I agree a
> > connection option for this would be good.
> >
>
> What would the option be? "wsainit = [enable | disable]"? Maybe it
> should allow setting the version to load: "wsa_ver
Andrew Chernow wrote:
Bruce Momjian wrote:
Ah, OK, so it does its own cleanup on last close, great. I agree a
connection option for this would be good.
What would the option be? "wsainit = [enable | disable]"? Maybe it
should allow setting the version to load: "wsa_version = 2.0". Maybe
Bruce Momjian wrote:
Ah, OK, so it does its own cleanup on last close, great. I agree a
connection option for this would be good.
What would the option be? "wsainit = [enable | disable]"? Maybe it
should allow setting the version to load: "wsa_version = 2.0". Maybe
the two should be comb
Jeroen Vermeulen wrote:
Would there be any serious harm in:
1. doing the WSAStartup() when the first connection is opened, but
The only problem is how to detect the first connection. In a threaded
environment you'd have to perform locking in connectdb, which is
probably not going to fly.
Dimitri Fontaine wrote:
-- Start of PGP signed section.
> Le mardi 20 janvier 2009, Bruce Momjian a ?crit?:
> > Robert Haas wrote:
> > > > Here is what I hope is a consensus patch. It adds 'A' to show all
> > > > objects, including system ones. It turns out that this is how 'S'
> > > > works now
Merlin Moncure wrote:
I think init/uninit is the answer. While writing libpqtypes, we noted
that libpq is just plain awkward in a few different ways and probably
deserves a rewrite at some point. not today though
Would there be any serious harm in:
1. doing the WSAStartup() when the fir
On 1/20/09, Peter Eisentraut wrote:
> integer[] is "array of integer", in the way C deals with arrays. This is
> also a main reason why composite types and arrays don't mix orthogonally;
> there is no way to represent that in the system catalogs.
What do you mean by this exactly? We've had a
Peter Eisentraut wrote:
-Wformat-security warns about
printf(var);
but not about
printf(var, a);
I don't understand that; the crash or exploit potential is pretty much the
same in both cases.
Not sure this is the reason, but in the first case any risk is trivially
avoided by usin
Greg Sabino Mullane wrote:
[ There is text before PGP section. ]
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
>
>
> > In thinking last night, I am now wondering if a letter is really the
> > right symbol for this. We already have letter flags which control
> > object type selection,
Alvaro Herrera wrote:
> Bruce Momjian escribi?:
>
> > In thinking last night, I am now wondering if a letter is really the
> > right symbol for this. We already have letter flags which control
> > object type selection, but the system table addition is kind of
> > independent of those flags, like
Magnus Hagander wrote:
> Bruce Momjian wrote:
> > Andrew Chernow wrote:
> >> Bruce Momjian wrote:
> >>> We could have gone with a more elegant init/uninit solution but there is
> >>> a history of slow upstream adoption of libpq API changes.
> >>>
> >>>
> >> If that's the case, adding a connectdb op
Bruce,
* Bruce Momjian (br...@momjian.us) wrote:
> In thinking last night, I am now wondering if a letter is really the
> right symbol for this. We already have letter flags which control
> object type selection, but the system table addition is kind of
> independent of those flags, like '+' now.
Le mardi 20 janvier 2009, Bruce Momjian a écrit :
> Robert Haas wrote:
> > > Here is what I hope is a consensus patch. It adds 'A' to show all
> > > objects, including system ones. It turns out that this is how 'S'
> > > works now in CVS, but 'S' is unclear because it suggests just system
> > > o
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> In thinking last night, I am now wondering if a letter is really the
> right symbol for this. We already have letter flags which control
> object type selection, but the system table addition is kind of
> independent of those flags, like '+'
Bruce Momjian escribió:
> In thinking last night, I am now wondering if a letter is really the
> right symbol for this. We already have letter flags which control
> object type selection, but the system table addition is kind of
> independent of those flags, like '+' now. I am thinking maybe '&'
Robert Haas wrote:
> > Here is what I hope is a consensus patch. It adds 'A' to show all
> > objects, including system ones. It turns out that this is how 'S' works
> > now in CVS, but 'S' is unclear because it suggests just system objects;
> > 'A' for show 'all' objects seems clearer.
>
> I thi
Bruce Momjian wrote:
> Andrew Chernow wrote:
>> Bruce Momjian wrote:
>>> We could have gone with a more elegant init/uninit solution but there is
>>> a history of slow upstream adoption of libpq API changes.
>>>
>>>
>> If that's the case, adding a connectdb option seems like a good
>> alternative.
Hiroshi Inoue wrote:
> Magnus Hagander wrote:
>> There still needs to be some error checking added in IsoLocaleName(),
>> but this is a start.
>>
>> Can someone please test this? :-)
>
> OK I would check it tonight.
Thanks.
> Please note the patch relies on the proper gettext module.
> The heade
On Tue, Jan 20, 2009 at 5:09 AM, Peter Eisentraut wrote:
> This would work much
> better if integer[][] where "array of integer[]", in the same way as
> integer[] is "array of integer", in the way C deals with arrays.
Well the situation in C is substantially more complicated than you
make out. I
Tom Lane wrote:
> Alvaro Herrera writes:
> > But freed memory is clobbered, so if we were to have an assert that
> > checks the node tag, it should show up. In fact, we do have such an
> > assert, but only for compilers other than GCC, because the inline
> > version of palloc() cannot have it fo
ITAGAKI Takahiro wrote:
Gregory Stark wrote:
I don't think we can perfectly capture the meaning of these GUCs in the
name. I think our goal should be to avoid confusion between them.
I was thinking it would be clearer if the options which control *when*
autovacuum fires off a worker consisten
68 matches
Mail list logo
