ITAGAKI Takahiro wrote:
Gregory Stark st...@enterprisedb.com 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
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com 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()
On Tue, Jan 20, 2009 at 5:09 AM, Peter Eisentraut pete...@gmx.net 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
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. Orignally
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 think it's
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 '' is
-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 '+'
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
objects; 'A'
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. I
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 option seems like a good
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 '+' now.
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, but the
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
On 1/20/09, Peter Eisentraut pete...@gmx.net 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?
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
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 in CVS, but
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.
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
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
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.
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:
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:
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 | disable]? Maybe it
should
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 allow setting
Pavan Deolasee wrote:
On Mon, Dec 8, 2008 at 11:33 AM, Pavan Deolasee
pavan.deola...@gmail.comwrote:
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.
Tom Lane wrote:
Pavan Deolasee pavan.deola...@gmail.com 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
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
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 would the option be? wsainit =
Bruce Momjian wrote:
Pavan Deolasee wrote:
On Mon, Dec 8, 2008 at 11:33 AM, Pavan Deolasee pavan.deola...@gmail.comwrote:
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.
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 the
Bruce Momjian wrote:
Tom Lane wrote:
Pavan Deolasee pavan.deola...@gmail.com 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
Tom Lane wrote:
Pavel Stehule pavel.steh...@gmail.com 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
On Tuesday 20 January 2009 18:09:51 Merlin Moncure wrote:
On 1/20/09, Peter Eisentraut pete...@gmx.net 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
Stephen Frost sfr...@snowman.net 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
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 this
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
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.
Hmm, the
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
... 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
* 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
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
* 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
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 to
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
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
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 starts to
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
On Tue, Jan 20, 2009 at 4:04 PM, Bryce Nesbitt bry...@obviously.com 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
Peter Eisentraut pete...@gmx.net 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 grant
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 of a
Jaime Casanova wrote:
On Tue, Jan 20, 2009 at 4:04 PM, Bryce Nesbitt bry...@obviously.com 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
Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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
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
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
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
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
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 and
Josh Berkus j...@agliodbs.com 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
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 this
On Tue, 2009-01-20 at 18:37 -0500, Tom Lane wrote:
Josh Berkus j...@agliodbs.com 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
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
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
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 supplied a
Robert Treat wrote:
also, I forget which way is proper, but you're inconsistent with your closing
tags for application in that paragraph (using both /application and /)
They're both acceptable.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL
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 annoying on the
KaiGai Kohei kai...@ak.jp.nec.com 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
* 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
67 matches
Mail list logo
