Hi folks,
As I said on -PATCHES, I've been working on an utility to get
a b-tree index information. I'm happy to introduce
my new functions to you.
pgstattuple module provides a `pgstatindex()`, and other small
functions, which allow you to get b-tree internal information.
I believe this module w
On Jul 28, 2006, at 12:37 , ISHIDA Akio wrote:
| SJIS サーバの符号化方式としてはサポートしていません。
Just to confirm, it does look like there's a discrepancy between what
is in the documentation and the actual behavior of the server. The
documentation indicates that SJIS is a valid server encoding:
http://ww
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> nonInVacuumXmin seems useless ... perhaps a vestige of some earlier
> >> version of the computation?
>
> > Hmm, not useless at all really -- only a bug of mine. Turns out the
> > notInVacuumXmin stuff is essenti
Alvaro:
In effect I published the file pgpass.conf and I added the following line:
localhost:5432:*:postgres:kklliu
However. I continued my instruction and follows without working to me. Exists the way to invoke psql that is not of interactive way so that It alters password of a us
Another idea Jan had today was whether we could vacuum more rows if a
long-running backend is in serializable mode, like pg_dump.
---
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> nonI
* Phil Frost ([EMAIL PROTECTED]) wrote:
> Granted, I can't think of too many ways one could store sensitive
> information in a sequence. I think it's more important to consider what
> it implies about the system behind the issue. When I revoke some
> privilege, I expect it to be enforced regardless
On Thu, Jul 27, 2006 at 05:01:37PM -0400, Andrew Dunstan wrote:
> Tom Lane wrote:
>
> >Alvaro Herrera <[EMAIL PROTECTED]> writes:
> >>What we should really do is have lastval() fail if the user does not
> >>have appropiate permissions on the schema. Having it not fail is a bug,
> >>and documentin
On Thu, Jul 27, 2006 at 04:40:45PM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > What we should really do is have lastval() fail if the user does not
> > have appropiate permissions on the schema. Having it not fail is a bug,
> > and documenting a bug turns it not into a
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> nonInVacuumXmin seems useless ... perhaps a vestige of some earlier
>> version of the computation?
> Hmm, not useless at all really -- only a bug of mine. Turns out the
> notInVacuumXmin stuff is essential, so I put it back.
Uh, why
Ühel kenal päeval, N, 2006-07-27 kell 19:29, kirjutas Alvaro Herrera:
>
> We could either add it anew, beside nonInVacuumXmin, or replace
> nonInVacuumXmin. The difference will be whether we will have something
> to be used to vacuum shared relations or not. I think in general,
> shared relatio
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Hannu Krossing asked me about his patch to ignore transactions running
> > VACUUM LAZY in other vacuum transactions. I attach a version of the
> > patch updated to the current sources.
>
> nonInVacuumXmin seems useless ... perhaps a
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> +1 on both of those. I think that pg_settings should actually show
>> "pages" as the native unit for shared_buffers et al. The current
>> "8kb" display isn't a valid unit --- consider what happens if a
>> program does select settin
Sergey's recent patch for the SQL2003 binary aggregates implements each
of them three times: in float4, float8, and numeric arithmetic. This
seems like vast overkill. The float4 versions certainly ought to go,
as they won't perform noticeably better than float8 and will likely be
subject to terri
Tom Lane wrote:
> +1 on both of those. I think that pg_settings should actually show
> "pages" as the native unit for shared_buffers et al. The current
> "8kb" display isn't a valid unit --- consider what happens if a
> program does select setting || unit from pg_settings ...
Physicists know tha
Yippee!
--- Begin Message ---
Log Message:
---
Aggregate functions now support multiple input arguments.
...
Original patch by Sergey Koposov; review, documentation, simple regression
tests, pg_dump and psql support by moi.
--- End Message ---
--
Gregory Stark
EnterpriseDB
Martijn van Oosterhout writes:
> My main problem with the kibi, mibi, etc is that they're basically
> unknown.
Frankly the main problem is that they're idiotic.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)--
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I notice that cube_2.out hasn't been updated. Was that intentional?
> Well, I was going to wait to see a buildfarm member that needed the
> alternative exponent representation, and use the regression diff as a
> template
I've had
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> ... The question is whether we want to have kB mean
> 1000 bytes instead of 1024 bytes.
> In my mind, that goes against current practice.
I concur. Most of the places where we are using these units, they are
for specifying memory sizes, and *everyo
Jim Nasby <[EMAIL PROTECTED]> writes:
> First, when it comes to page values, perhaps we should allow pages/
> blocks as a valid unit. That would allow people who want to to
> specify things in pages and still be explicit about what they mean.
> Second, lack of interest or no, I feel forcing spe
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Maybe we need to try to stress test the comparison routines a bit to
make sure they really are deterministic.
Eyeball inspection shows that cube_cmp is wrong: it's doing
PG_RETURN_INT16 where it should say PG_RETURN_INT32.
Jim Nasby wrote:
> On Jul 27, 2006, at 7:30 AM, Tom Lane wrote:
> > Susanne Ebrecht <[EMAIL PROTECTED]> writes:
> >> ... We could provide the mixed update syntax and leave the
> >> typed row value expression for the next release. Do you agree?
> >
> > I don't really see the point --- the patch won'
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Maybe we need to try to stress test the comparison routines a bit to
> make sure they really are deterministic.
Eyeball inspection shows that cube_cmp is wrong: it's doing
PG_RETURN_INT16 where it should say PG_RETURN_INT32.
As best I can tell, the co
Jim Nasby <[EMAIL PROTECTED]> writes:
> Even if we stopped right there it would still be a huge win in many (most?)
> cases. How often do the indexes on a table comprise even 50% of the table's
> size?
I would say they're usually roughly comparable actually. It depends on how
wide your table
On Thu, Jul 27, 2006 at 05:56:15PM +0200, Peter Eisentraut wrote:
> Jim Nasby wrote:
> > The truth is, virtually no one, even highly technical people, ever
> > picks nits between kB vs KiB vs KB.
>
> The question isn't so much whether to allow KiB and such -- that would
> obviously be trivial. T
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Just noticed these:
Yeah, I complained about that before: the unportability is the least of
that code's problems. There's a patch in the queue that I trust fixes
it.
regards, tom lane
---(end of broadca
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
What we should really do is have lastval() fail if the user does not
have appropiate permissions on the schema. Having it not fail is a bug,
and documenting a bug turns it not into a feature, but into a "gotcha".
I'm unconvin
Joshua Reich wrote:
I just updated to the latest HEAD, so I assume I have the cube_1.out
that you changed. If you look at the order of the results expected in
cube.out and cube_1.out, they are different. So I don't think we have
a problem with the code, we just need to fix the ordering in cube
Just noticed these:
0 $ make
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g -fpic
-I/pgsql//source/12vacuum/contrib/pgstattuple -I../../src/include
-I/pgsql//source/12vacuum/src/include -D_GNU_SOURCE -c -o pgsta
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> What we should really do is have lastval() fail if the user does not
> have appropiate permissions on the schema. Having it not fail is a bug,
> and documenting a bug turns it not into a feature, but into a "gotcha".
I'm unconvinced that it's either a
Marc Munro <[EMAIL PROTECTED]> writes:
>> The attached patch provides add-ins with the means to register for
>> shared memory and LWLocks. This greatly improves the ease with which
>> shared memory may be used from add-ins, while blah blah blah
> I have tried to be patient but this is my firs
Mónica Ivonne Herrera Alonso wrote:
Hi,
> However. I continued my instruction and follows without working to me.
> Exists the way to invoke psql that is not of interactive way so that It
> alters password of a user with no need to be in psql?
>
> With the commando psql - S ALTER USER
it
Peter Eisentraut wrote:
Jim Nasby wrote:
The truth is, virtually no one, even highly technical people, ever
picks nits between kB vs KiB vs KB.
The question isn't so much whether to allow KiB and such -- that would
obviously be trivial. The question is whether we want to have kB mean
1000 b
I just updated to the latest HEAD, so I assume I have the cube_1.out
that you changed. If you look at the order of the results expected in
cube.out and cube_1.out, they are different. So I don't think we have a
problem with the code, we just need to fix the ordering in cube_1.out.
The same pro
Indeed. I am going to revert it.
The trouble is we currently have several orthogonal variations, which is
a worry on its own:
. negative zero
. exponent format, and
. result ordering
Looking closer, the result ordering certainly does seem odd, as you say.
Surely with ORDER BY it should be d
I am uncomfortable with the fact that the ordering is different on
different architectures. AFAIK, all I did was port the ordering function
from V0 to V1.
Short of me continually submitting patches until I fix it, is there an
easier way, or some pointers as to what I should be looking for in t
On Tuesday 25 July 2006 22:05, Marko Kreen wrote:
> On 7/24/06, Nicolai Petri <[EMAIL PROTECTED]> wrote:
> > I'm in the need for my custom written replication engine to obtain the
> > current transaction id from a trigger function. As far as I'm told it's
> > not possible today. Would people objec
I think this will cause breakage for other people.
Right now I think the order is unique to AIX for some reason.
Recent buildfarm run of gazelle should have matched the -0 variant
(cube_1.out), but did not.
Also, what is worrisome is that there is an ORDER BY on the result set
that is failing on
I wrote:
I have applied this and made an attempt to fix
cube/expected/cube_1.out - we will still need to keep an eye on the
various cube tests.
It looks like with the current tests we will need at least one more
possible results file (gazelle and asp on buildfarm agree about negative
ze
Peter Eisentraut wrote:
>
> I didn't say Oracle, I said anyone. It could be Microsoft or
> Samba or
> Red Hat or NetBSD or my VoIP phone.
>
OK, I did some further digging, and
(http://members.optus.net/alexey/prefBin.xhtml) has a list at the end of
the page of software that the author claims
Jim Nasby wrote:
> On Jul 25, 2006, at 3:31 PM, Tom Lane wrote:
> >Hannu Krosing <[EMAIL PROTECTED]> writes:
> >>What would be the use-case for hash indexes ? And what should be
> >>done to make them faster than btree ?
> >
> >If we knew, we'd do it ;-) But no one's put enough effort into it
> >t
Phil Frost wrote:
> On Thu, Jul 27, 2006 at 06:36:30PM +0200, Peter Eisentraut wrote:
> > I'm sure some people agree that there is a problem. It would help,
> > however, if you were not talking about two different things at once.
> > And it would help if you actually proposed a change that would
Phil Frost wrote:
> What two things are there?
Well, the subject says "lastval exposes information that currval does
not" while you are talking about schema permissions. I still don't
know what you're really after. One of your posts stated that you have
repeatedly demonstrated ways to overcom
On Thu, Jul 27, 2006 at 06:36:30PM +0200, Peter Eisentraut wrote:
> I'm sure some people agree that there is a problem. It would help,
> however, if you were not talking about two different things at once.
> And it would help if you actually proposed a change that would improve
> matters.
What
Bort, Paul wrote:
> So we'll look at it when Oracle does it?
I didn't say Oracle, I said anyone. It could be Microsoft or Samba or
Red Hat or NetBSD or my VoIP phone.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)
Phil Frost wrote:
> All right, I give up. I guess no one seems to want to admit this is a
> bad security policy, or accurately document it. Does that make it an
> easter egg?
I'm sure some people agree that there is a problem. It would help,
however, if you were not talking about two different t
Peter Eisentraut wrote:
>
> This consideration would become much more interesting if
> *any* software
> product actually made use of this newer proposed convention,
> but so far
> I haven't seen one yet.
>
So we'll look at it when Oracle does it?
I think we should be leading this charge, ra
On 7/26/06 11:50 PM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> "Jie Zhang" <[EMAIL PROTECTED]> writes:
>> On 7/26/06 10:14 PM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
>>> ... A nonuniform distribution would probably mean that some
>>> of the bitmaps compress better-than-expected and others worse. I
Actually, -general would be the place. -hackers is for back-end hacking.
On Jul 26, 2006, at 1:18 PM, Redefined Horizons wrote:
Is this an appropriate place for questions about implementing user
defined functions and custom data types in the C programming language?
I didn't want to "dirty" the
On Thu, 2006-07-27 at 17:57, Peter Eisentraut wrote:
> Florian G. Pflug wrote:
> > Rounding up would have the advantage that you could just specify "0"
> > in the config file, and have postgres use the smallest value
> > possible.
>
> In most algebras, dividing zero by something is still zero, so
Peter Eisentraut wrote:
Florian G. Pflug wrote:
Rounding up would have the advantage that you could just specify "0"
in the config file, and have postgres use the smallest value
possible.
In most algebras, dividing zero by something is still zero, so there'd
be no need to round anything.
I
On Jul 25, 2006, at 3:31 PM, Tom Lane wrote:
Hannu Krosing <[EMAIL PROTECTED]> writes:
Ühel kenal päeval, T, 2006-07-25 kell 13:06, kirjutas Tom Lane:
The reason I have such high sales resistance is that we've
carried the
hash and rtree AMs for years, hoping that someone would do the
work to
Florian G. Pflug wrote:
> Rounding up would have the advantage that you could just specify "0"
> in the config file, and have postgres use the smallest value
> possible.
In most algebras, dividing zero by something is still zero, so there'd
be no need to round anything.
--
Peter Eisentraut
http
Jim Nasby wrote:
> The truth is, virtually no one, even highly technical people, ever
> picks nits between kB vs KiB vs KB.
The question isn't so much whether to allow KiB and such -- that would
obviously be trivial. The question is whether we want to have kB mean
1000 bytes instead of 1024 byt
On Jul 26, 2006, at 10:29 AM, Tom Lane wrote:
Gregory Stark <[EMAIL PROTECTED]> writes:
... Well it's not like the existing vacuum checks for this.
Right, that's exactly why the patch works at all. But the point
here is
that the existing vacuum does not rely on re-computing index keys; all
Tom Lane wrote:
Susanne Ebrecht <[EMAIL PROTECTED]> writes:
... We could provide the mixed update syntax and leave the
typed row value expression for the next release. Do you agree?
I don't really see the point --- the patch won't provide any new
functionality in anything like its current form
On Wednesday 26 July 2006 14:27, Darcy Buskermolen wrote:
> On Wednesday 26 July 2006 14:03, Tom Lane wrote:
> > Darcy Buskermolen <[EMAIL PROTECTED]> writes:
> > >> The question though is if we did that, would Slony actually use it?
> > >
> > > If it made sence to do it, then yes we would do it. T
Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Peter's not said exactly how he plans to deal with
this, but I suppose it'll round off one way or the other ...
It'll get truncated by integer division. I wouldn't mind if someone
proposed a patch to create a warni
On Jul 26, 2006, at 4:29 PM, Hannu Krosing wrote:
Well the desire for it comes from a very well established need
for dealing
with extremely large tales with relatively small hot spots. The
basic problem
being that currently the cost of vacuum is proportional to the
size of the
table rather t
[snip]
> Forcing people to use a specific casing scheme is just going to lead
> to confusion and user frustration. If there's not a very solid
I guess nobody will force people to use the units at all.
> *functional* argument for it, we shouldn't do it. Wanting to enforce
> a convention that
All right, I give up. I guess no one seems to want to admit this is a
bad security policy, or accurately document it. Does that make it an
easter egg?
On Thu, Jul 20, 2006 at 01:59:43PM -0400, Bruce Momjian wrote:
>
> OK, text again updated:
>
>For schemas, allows access to objects conta
On Jul 27, 2006, at 7:30 AM, Tom Lane wrote:
Susanne Ebrecht <[EMAIL PROTECTED]> writes:
... We could provide the mixed update syntax and leave the
typed row value expression for the next release. Do you agree?
I don't really see the point --- the patch won't provide any new
functionality in a
On Jul 27, 2006, at 9:16 AM, Bort, Paul wrote:
Peter Eisentraut wrote:
I have committed it using the 1024 multiplier, but if you want to
propose changing all uses of kB, MB, and GB in PostgreSQL to
the other
system, now would be the time to do it.
I think it would be a good idea. I know I do
Bort, Paul wrote:
> Peter Eisentraut wrote:
> >
> > I have committed it using the 1024 multiplier, but if you want to
> > propose changing all uses of kB, MB, and GB in PostgreSQL to
> > the other
> > system, now would be the time to do it.
> >
>
> I think it would be a good idea. I know I do
Peter Eisentraut wrote:
>
> I have committed it using the 1024 multiplier, but if you want to
> propose changing all uses of kB, MB, and GB in PostgreSQL to
> the other
> system, now would be the time to do it.
>
I think it would be a good idea. I know I don't have time to do it for
8.2.
I
Joshua Reich <[EMAIL PROTECTED]> writes:
> I'm not sure exactly what to do here. I tried simply doing
> CREATE TYPE cube;
> But I still get NOTICE's to the effect of "return type cube is only a
> shell" or "argument type cube is only a shell".
Hmm ... I remembered that we'd discussed suppressing
I'm not sure exactly what to do here. I tried simply doing
CREATE TYPE cube;
But I still get NOTICE's to the effect of "return type cube is only a
shell" or "argument type cube is only a shell".
I'm not sure how to do this to get zero NOTICES.
Advice appreciated.
Josh Reich
Tom Lane wrote:
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> UPDATE mytab SET (foo, bar, baz) =
> >> (SELECT alpha, beta, gamma FROM othertab WHERE key = mytab.key);
>
> > That UPDATE example is interesting because I remember when using
> > Informix that I had to do a separ
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> UPDATE mytab SET (foo, bar, baz) =
>> (SELECT alpha, beta, gamma FROM othertab WHERE key = mytab.key);
> That UPDATE example is interesting because I remember when using
> Informix that I had to do a separate SELECT statement for each
Tom Lane wrote:
> much anything that can generate a row. The patch as you have it
> provides nothing more than syntactic sugar for something people can do
> anyway. The reason people want this syntax is that they expect to be
> able to write, say,
>
> UPDATE mytab SET (foo, bar, baz) =
>
On Sun, 2006-07-16 at 01:04 +0300, Hannu Krosing wrote:
> Ühel kenal päeval, R, 2006-07-14 kell 17:39, kirjutas Simon Riggs:
> > On Fri, 2006-07-14 at 12:09 -0400, Tom Lane wrote:
> > > "Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> > > > I've now thought about how to fix that without doing that
Mónica Ivonne Herrera Alonso wrote:
Mónica,
> I need to change password of the usuary POSTGRES using the commando "ALTER
> USER". This change I must do it by means of a program .bat in quiet way.
>
> I have the following instruction in .bat program :
>
> psql -S "ALTER USER postgres WI
Good day for You.
I need to change password of the usuary POSTGRES using the commando "ALTER USER". This change I must do it by means of a program .bat in quiet way.
I have the following instruction in .bat program :
psql -S "ALTER USER postgres WITH PASSWORD 'xxtyod';"
But when
Susanne Ebrecht <[EMAIL PROTECTED]> writes:
> ... We could provide the mixed update syntax and leave the
> typed row value expression for the next release. Do you agree?
I don't really see the point --- the patch won't provide any new
functionality in anything like its current form, because you ca
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Peter's not said exactly how he plans to deal with
>> this, but I suppose it'll round off one way or the other ...
> It'll get truncated by integer division. I wouldn't mind if someone
> proposed a patch to create a warning or err
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> The attached patch requires the new row to fit, and 10% to be free on
> the page. Would someone test that?
This is another solution for the same purpose. We can avoid to call
PageIndexMultiDelete() to remove only one tuple. _bt_split() becomes
to ignor
Am Mittwoch, den 26.07.2006, 16:58 -0400 schrieb Tom Lane:
> Susanne Ebrecht <[EMAIL PROTECTED]> writes:
> This is a cute hack, but it does only a small part of what I think the
> spec says.
Thank you for compliment.
>
> In the first place, the SQL syntax is pretty clear that you can combine
> s
Bort, Paul wrote:
> I still think it would be a good idea to use the standard, and that
> this is an opportunity to do so.
I have committed it using the 1024 multiplier, but if you want to
propose changing all uses of kB, MB, and GB in PostgreSQL to the other
system, now would be the time to do
Tom Lane wrote:
> It is. For instance shared_buffers is configured as the number of
> buffers. What we're talking about here is ways to specify the
> intended usage with other units (eg "I want N megabytes of shared
> buffers") but that's not going to magically let you allocate half a
> shared bu
On Jul 27, 2006, at 14:03 , Tom Lane wrote:
What we're talking about here is ways to specify the intended
usage with other units (eg "I want N megabytes of shared buffers") but
that's not going to magically let you allocate half a shared buffer.
Peter's not said exactly how he plans to deal wit
79 matches
Mail list logo
