Hi -
I've searched the email archives, and the last I saw INSERT ... RETURNING
referenced was last March. I had two questions:
1) will this feature make it in 8.2?
2) is there a timeline for 8.2?
BTW, while searching for "insert returning", I noticed an invalid hit (the url
goes to a different m
Neil Conway wrote:
> On Tue, 2006-07-25 at 19:00 -0400, Tom Lane wrote:
> > Maybe I'm missing something, but I thought it was fairly common to
> > use "k" for 1000, "K" for 1024, etc (mnemonic: upper case for the
> > larger multiplier).
>
> Well, that only works for K vs. k: the SI prefix for mega
Tom Lane <[EMAIL PROTECTED]> wrote:
> ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> I've applied this but I'm now having some second thoughts about it,
> because I'm seeing an actual *decrease* in pgbench numbers from the
> immediately prior CVS HEAD code.
> Had you done any performance testing
Tom Lane wrote:
> Joshua Reich <[EMAIL PROTECTED]> writes:
> >> The problem is that there are new functions in cube.sql, so the output
> >> is now different and breaks the diff (to state the obvious).
>
> Actually, the new theory on this is that you should explicitly create
> a shell type first:
Joshua Reich <[EMAIL PROTECTED]> writes:
>> The problem is that there are new functions in cube.sql, so the output
>> is now different and breaks the diff (to state the obvious).
Actually, the new theory on this is that you should explicitly create
a shell type first:
CREATE TYPE cube;
Stating the obvious, again - attached is my patch for earthdistance.
Apologies for breaking the build.
Josh
Joshua Reich wrote:
Ok. If I understand this correctly, earthdistance required cube. So,
I'll fix the test for earthdistance to work with the new cube code.
The problem is that there
Ok. If I understand this correctly, earthdistance required cube. So,
I'll fix the test for earthdistance to work with the new cube code.
The problem is that there are new functions in cube.sql, so the output
is now different and breaks the diff (to state the obvious).
Josh Reich
Tom Lane wr
Joshua Reich <[EMAIL PROTECTED]> writes:
> Can you point to me where I can get a regression diff for a failed
> build.
It's all on the webpage, just scroll down ...
regards, tom lane
---(end of broadcast)---
TIP 4: Have you
Can you point to me where I can get a regression diff for a failed
build. For the install-checks that I looked at on the buildfarm, I see:
== running regression test queries==
test cube ... ok
Josh
Tom Lane wrote:
[EMAIL PROTECTED] (Bruce Momji
[EMAIL PROTECTED] (Bruce Momjian) writes:
> Log Message:
> ---
> /contrib/cube improvements:
Should I point out that the buildfarm universally reports failure?
regards, tom lane
---(end of broadcast)---
TIP 1: if pos
David Fetter <[EMAIL PROTECTED]> writes:
> On Mon, Jul 24, 2006 at 11:59:34PM -0400, Tom Lane wrote:
>> The documentation is still in need of help ... in particular, Table
>> B-4 (timezone names) is now out of sync with reality.
> I'll take a whack at that patch this evening PDT or tomorrow evenin
Tom, I ran your tests with fsync off (as you did), and saw numbers
bouncing between 400-700 tps without my patch, and sticking at 700 tps
with my patch.
---
Bruce Momjian wrote:
>
> The attached patch requires the new row t
Tom Lane wrote:
And your point is? Assuming a reasonable datatype like int4, a btree
index on this table would occupy say 20GB (16 bytes per entry plus
fillfactor overhead). The bitmap version would require 10,000 bitmaps
of 1G bits apiece, or 1250GB (not even counting overhead). You need
so
The attached patch requires the new row to fit, and 10% to be free on
the page. Would someone test that?
---
Tom Lane wrote:
> ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> > This is a revised patch originated by Junji TER
On Tue, 2006-07-25 at 19:00 -0400, Tom Lane wrote:
> Maybe I'm missing something, but I thought it was fairly common to use
> "k" for 1000, "K" for 1024, etc (mnemonic: upper case for the larger
> multiplier).
Well, that only works for K vs. k: the SI prefix for mega is M (meaning
10^6), not "m".
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Bort, Paul wrote:
>> [ 1000 vs 1024 ]
> But in this case it's not practical.
Maybe I'm missing something, but I thought it was fairly common to use
"k" for 1000, "K" for 1024, etc (mnemonic: upper case for the larger
multiplier). So I'd vote for acc
Bort, Paul wrote:
> I'm not trying to be pedantic, but the general approach with -hackers
> seems to be towards compliance where practical.
But in this case it's not practical.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)
One of the complaints I had about the bitmap index patch was the extent
to which it wants to modify (and largely create duplicate code paths in)
the existing executor support for bitmap scans. Now maybe I'm missing
something but I don't think that's where the value-add of this patch is.
It strike
Peter Eisentraut wrote:
>
> Memory units are kB, MB, GB. The factor is 1024.
>
Then shouldn't the factor be 1000? If the factor is 1024, then the units
should be KiB, MiB, GiB per IEEE 1541
(http://en.wikipedia.org/wiki/IEEE_1541) and others.
I'm not trying to be pedantic, but the general ap
Ron Mayer <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> If you have to hit one tuple out of four, it's pretty much guaranteed
>> that you will need to fetch every heap page.
> I think it's not uncommon to have data that is more clustered than expected.
Sure, if the data is fairly static ...
On Jul 26, 2006, at 7:12 , Michael Glaesemann wrote:
On Jul 26, 2006, at 6:56 , Peter Eisentraut wrote:
Memory units are kB, MB, GB. The factor is 1024.
Time units are ms, s, min, h, d.
Are units case-sensitive? I've noticed you've been consistent in
your capitalization in these posts,
On Jul 26, 2006, at 6:56 , Peter Eisentraut wrote:
Memory units are kB, MB, GB. The factor is 1024.
Time units are ms, s, min, h, d.
Are units case-sensitive? I've noticed you've been consistent in your
capitalization in these posts, so I'm wondering if you're enforcing
the same case in
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Output from SHOW uses the largest unit that fits as long as the number
> is an integer.
That seems OK for SHOW, which is mainly intended for human consumption,
but what will you do with pg_settings? For programmatic use I think
we want more predicta
It seems everyone likes the units, so here are some details of the
implementation I have prepared.
Memory units are kB, MB, GB. The factor is 1024.
Time units are ms, s, min, h, d.
I intentionally did not support microseconds because that would make the
coding extremely overflow-risky, and th
Tom Lane wrote:
[EMAIL PROTECTED] writes:
Reading 1/4, for a larger table, has a good chance of being faster than
reading 4/4 of the table. :-)
Really?
If you have to hit one tuple out of four, it's pretty much guaranteed
that you will need to fetch every heap page.
I think it's not uncom
Jim C. Nasby wrote:
> Today Pervasive announced that it is stepping away from PostgreSQL
> support and services. There's an open letter to the community at
> http://pervasivepostgresql.com with more info, so I won't really go
> into that. There are a few things I wanted to mention, though.
>
> Fir
Jim C. Nasby wrote:
> On Tue, Jul 25, 2006 at 08:48:34AM +0200, Albe Laurenz wrote:
> > Peter Eisentraut wrote:
> > > So assuming we allowed units in postgresql.conf, how would you
> > > report them with SHOW?
> > >
> > > 1. The way they were set (hard)
> > >
> > > 2. Without units (not user-friend
On Tue, Jul 25, 2006 at 08:48:34AM +0200, Albe Laurenz wrote:
> Peter Eisentraut wrote:
> > So assuming we allowed units in postgresql.conf, how would you report
> > them with SHOW?
> >
> > 1. The way they were set (hard)
> >
> > 2. Without units (not user-friendly)
> >
> > 3. Always in base un
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Point taken, but I'm inclined to convert it to an integer anyway,
> because that will make the units support much easier. The variable is
> only used in exactly one place anyway, so making sure the calculation
> works right should be easy.
Casting
Today Pervasive announced that it is stepping away from PostgreSQL
support and services. There's an open letter to the community at
http://pervasivepostgresql.com with more info, so I won't really go into
that. There are a few things I wanted to mention, though.
First, I'm now officially looking f
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Is it intentional that effective_cache_size is a real (as opposed
> > to integer)?
>
> Yes --- the planner generally does all that stuff in float arithmetic
> to avoid worrying about overflow.
Point taken, but I'm inclined to conve
Josh Berkus writes:
> One particular compelling situation for on-disk bitmaps is for terabyte
> tables where a btree index would not fit into memory. Index
> performance for an index which is 10x or more the size of RAM really
> sucks ... I can come up with some test results if you doubt that
Tom,
On 7/25/06 1:31 PM, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> Yeah, we finally gave up on rtree entirely. I don't want to see any
> other index AMs languishing in the closet like that. If bitmap can
> hold its own to the extent that people are interested in working on
> it/improving it, then
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
>> make them actually worth using, with l
Joachim Wieland <[EMAIL PROTECTED]> writes:
> what do people think about this TODO item:
> o Merge hardwired timezone names with the TZ database; allow either
> kind everywhere a TZ name is currently taken
> I think it is kind of done.
Not quite --- SET TIMEZONE doesn't take the
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> Is there a chance that the locking variant will be replaced by
> non-locking variant,
No, I don't think so. Given that the concurrent form is much slower
(extra table scan) and can't be wrapped into a transaction block,
it'll always be a special option.
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 object much if this functionality was added for 8.2 ?
It's the last
On 7/25/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Csaba Nagy <[EMAIL PROTECTED]> writes:
>> Strictly speaking, however, it would have to be NOLOCKLY in that case. :-)
> In this case CREATE INDEX CONCURRENTLY ... sounds better to me, although
> the whole feature sounds nice any way you will finally
Hi,
what do people think about this TODO item:
o Merge hardwired timezone names with the TZ database; allow either
kind everywhere a TZ name is currently taken
I think it is kind of done. The hardwired timezone names are no longer
hardwired and the "America/New_York" syntax is
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> This is a revised patch originated by Junji TERAMOTO for HEAD.
> [BTree vacuum before page splitting]
> http://archives.postgresql.org/pgsql-patches/2006-01/msg00301.php
> I think we can resurrect his idea because we will scan btree pages
> at-atim
-Original Message-
From: "Andrew Dunstan" <[EMAIL PROTECTED]>
To: "Dave Page"
Cc: "Gevik Babakhani" <[EMAIL PROTECTED]>; "pgsql-hackers"
Sent: 25/07/06 17:21
Subject: Re: [HACKERS] root/administartor user check option.
Dave Page wrote:
> -Original Message-
> From: "Gevik Babak
[EMAIL PROTECTED] (Tom Lane) writes:
> Chris Browne <[EMAIL PROTECTED]> writes:
>> Unfortunately (perhaps) standards_conforming_strings does not appear
>> to be exported, so I'm not sure how to do this otherwise.
>
> Perhaps your problem is one of spelling? It's
> "standard_conforming_strings", an
>
> Which user does it switch to? I was under the impression that Gevik
> wanted not to have to create any extra users.Or does it abandon
> privileges without switching personality (if that's possible)?
>
Correct, With the bypass option I had in mind, I wouldn't need to create
an extra user. Just
Tom,
> (I'm also wondering whether this
doesn't overlap the use-case for GIN.)
It does not. GIN is strictly for multi-value fields. I can think of
applications where either GIN or Bitmaps would be an option, but for the
majority, they wouldn't.
One particular compelling situation for on-
Ühel kenal päeval, T, 2006-07-25 kell 13:06, kirjutas Tom Lane:
> "Luke Lonergan" <[EMAIL PROTECTED]> writes:
> > I think we do know, have you reviewed the results in the briefing?
>
> I find those results moderately unconvincing, primarily because they
> are based on choosing the least efficient
Peter,
I wonder whether platforms with INT64_IS_BROKEN can address more than 2GB of
memory anyway.
To be quite frank, current PostgreSQL can't effectively use more than
256mb of work_mem anyway. We'd like to fix that, but it's not fixed yet
AFAIK.
--Josh
---(end
Ühel kenal päeval, T, 2006-07-25 kell 12:49, kirjutas Jim C. Nasby:
> On Sun, Jul 23, 2006 at 05:35:37PM -0700, Luke Lonergan wrote:
> > We presented them at the Postgres Anniversary summit talk (Bruce M. was
> > there) and the reaction was let's get this into 8.2 because many people
> > there (mor
Jim Nasby wrote:
>
> Why is it being hard-coded? I think it makes a lot more sense to allow
> pg_bench options to be specified in the buildfarm config. Even better
> yet would be specifying them on the command line, which would allow
> members to run a more rigorous test once a day/week (I'm think
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> I think we can resurrect his idea because we will scan btree pages
> at-atime now; the missing-restarting-point problem went away.
> Have I missed something? Comments welcome.
I was thinking for awhile just now that this would break the interlock
tha
On Sun, Jul 23, 2006 at 11:52:14PM -0400, Bort, Paul wrote:
> -hackers,
>
> With help from Andrew Dunstan, I'm adding the ability to do a pgbench
> run after all of the other tests during a buildfarm run.
>
> Andrew said I should solicit opinions as to what parameters to use. A
> cursory search
On Sun, Jul 23, 2006 at 05:35:37PM -0700, Luke Lonergan wrote:
> We presented them at the Postgres Anniversary summit talk (Bruce M. was
> there) and the reaction was let's get this into 8.2 because many people
> there (more than 5) really wanted to use it as a standard feature.
>
> A version of t
Chris Browne <[EMAIL PROTECTED]> writes:
> Unfortunately (perhaps) standards_conforming_strings does not appear
> to be exported, so I'm not sure how to do this otherwise.
Perhaps your problem is one of spelling? It's
"standard_conforming_strings", and it's certainly a global variable.
You still
From: "Andrew Dunstan"
> Hiroshi Saito wrote:
> > Hmm, It seems to be the bug of very unpleasant Microsoft.:D
> > I think that the following is desirable as an evasion measure to add.
> >
> > #if defined(_MSC_VER) && _MSC_VER == 1400
> >
> > To be sure, it was only VS2005.
> >
>
>
> Why is t
"Luke Lonergan" <[EMAIL PROTECTED]> writes:
> I think we do know, have you reviewed the results in the briefing?
I find those results moderately unconvincing, primarily because they
are based on choosing the least efficient possible data representation
(viz char(n)), and thus the btree indexes suf
[EMAIL PROTECTED] (Peter Eisentraut) writes:
> Chris Browne wrote:
>> In support of PG 8.2, we need to have the log trigger function do the
>> following:
>> - Save value of standards_conforming_string
>> - Set value of standards_conforming_string to FALSE
>> - proceed with saving data to sl_l
On Jul 21, 2006, at 9:03 AM, Tom Lane wrote:
One
possibility is that early freeze is at 1B transactions and we push
forced-freeze back to 1.5B transactions (the current forced-freeze
at 1B
transactions seems rather aggresive anyway, now that the server will
refuse to issue new commands rather
* Bruce Momjian ([EMAIL PROTECTED]) wrote:
> Tom Lane wrote:
> > You are assuming here that the continuous archiving process is identical
> > to the WAL part of the base-backup process. If what you want is an
> > identifiable self-contained base backup then you copy off the WAL files
> > along wit
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Another possibility would be allowing users to specify certain GUC
> settings for backends that match certain criteria when they're spawned,
> such as what IP the client is connecting from, or what user it's
> authenticating as.
ALTER USER SET ...
Hiroshi Saito wrote:
> Hmm, It seems to be the bug of very unpleasant Microsoft.:D
> I think that the following is desirable as an evasion measure to add.
>
> #if defined(_MSC_VER) && _MSC_VER == 1400
>
> To be sure, it was only VS2005.
>
Why is this better than:
#if _MSC_VER == 1400
Sur
Tom Lane wrote:
>> The point is until that last WAL file is backed up, the whole backup
is
>> useless. It isn't good policy to have a backup's value be contingent
on
>> some future event.
>
> You are assuming here that the continuous archiving process is
identical
> to the WAL part of the base-bac
On Wed, Jul 19, 2006 at 01:35:16PM -0400, Tom Lane wrote:
> > 1) I think the most straightforward way to load an instrumentation
> > plugin is to define a new custom GUC variable (using the
> > custom_variable_classes mechanism).
>
> This seems a bit messy and special-purpose. I see no good rea
Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Assuming such a case, would it be possible to have two functions?
>
> > pg_stop_backup()
> > pg_stop_backup(boolean); --parameter says log switch or not
>
> Well, it seems everyone but me thinks that pg_stop_backup should
> force a WAL
Hi.
"William ZHANG" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
> When I tried to compile pgsql-8.2devel with VS.Net 2005 and do regression
> tests,
> I found the problem. It's a bug inVS.Net 2005:
> http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=9
Simon Riggs <[EMAIL PROTECTED]> writes:
> Assuming such a case, would it be possible to have two functions?
> pg_stop_backup()
> pg_stop_backup(boolean); --parameter says log switch or not
Well, it seems everyone but me thinks that pg_stop_backup should
force a WAL switch, so I'll yield on that p
Simon Riggs wrote:
> On Tue, 2006-07-25 at 11:57 -0400, Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Simon Riggs <[EMAIL PROTECTED]> writes:
> > > > I was planning to add a new GUC
> > > > archive_timeout (integer) = max # secs between log file switches
> > >
> > > That's fine, but featu
> > The problems I see with this is if in this case the normal postgres
> > WAL
> > archiving won't conflict with this streaming ?
>
> You are not forced to use it if your shell scripts do conflict.
>
> What I envisioned, was that the current WAL archiving shell script would
> just do some CRC c
Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Tue, 2006-07-25 at 11:31 -0400, Tom Lane wrote:
> >> My point here is that forcing the current segment to archive is a
> >> function of whatever your continuous-archiving process is, and it's
> >> not necessarily tied to backups. We
> Ultimately, I really think we need something akin to CPAN so that we
> don't have to bundle all kinds of stuff in the core package. In the
> meantime, adding PLs that we can is better than not, but we do need to
> be mindful of the impression it might leave on users. A page that lists
> the stat
Dave Page wrote:
-Original Message-
From: "Gevik Babakhani" <[EMAIL PROTECTED]>
To: "pgsql-hackers"
Sent: 25/07/06 11:27
Subject: [HACKERS] root/administartor user check option.
I would like to start a discussion about having an extra option in PG
which makes possible to bypass (or
"William ZHANG" <[EMAIL PROTECTED]> writes:
> When I tried to compile pgsql-8.2devel with VS.Net 2005 and do regression
> tests,
> I found the problem. It's a bug inVS.Net 2005:
> http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=99694
So why don't you use the fixed
On Tue, 2006-07-25 at 11:57 -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> > > I was planning to add a new GUC
> > > archive_timeout (integer) = max # secs between log file switches
> >
> > That's fine, but feature freeze is in a week and we don't eve
Ühel kenal päeval, T, 2006-07-25 kell 17:52, kirjutas Csaba Nagy:
> > OK, "offset" added to TODO item. What would the offset give us?
>
> The last offset could be remembered by the external program, and it
> only
> has to transfer from the last offset to the new one. It allows
> incremental strea
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Tue, 2006-07-25 at 11:31 -0400, Tom Lane wrote:
>> My point here is that forcing the current segment to archive is a
>> function of whatever your continuous-archiving process is, and it's
>> not necessarily tied to backups. We should not prejudge when p
On Tue, 2006-07-25 at 11:45 -0400, Tom Lane wrote:
> there are scenarios in which you don't need a WAL
> switch at the end of a backup.
My mind's blank today, so forgive me that I cannot see what that might
be.
Assuming such a case, would it be possible to have two functions?
pg_stop_backup()
p
Ühel kenal päeval, T, 2006-07-25 kell 11:48, kirjutas Bruce Momjian:
> Hannu Krosing wrote:
> > ?hel kenal p?eval, T, 2006-07-25 kell 11:27, kirjutas Bruce Momjian:
> > > Hannu Krosing wrote:
> > > > ?hel kenal p?eval, T, 2006-07-25 kell 10:51, kirjutas Bruce Momjian:
> > > > > Where are we on thes
On Tue, 2006-07-25 at 11:53 -0400, Tom Lane wrote:
> That's fine, but feature freeze is in a week and we don't even have
> the
> basic function for manually doing a log file switch. Let's get that
> done first and then think about automatic switches.
Agreed.
--
Simon Riggs
Ente
OK, makes sense. That is much more sophisticated that I imagined.
---
Csaba Nagy wrote:
> > OK, "offset" added to TODO item. What would the offset give us?
>
> The last offset could be remembered by the external program,
> OK, "offset" added to TODO item. What would the offset give us?
The last offset could be remembered by the external program, and it only
has to transfer from the last offset to the new one. It allows
incremental streaming of the WAL files... of course the external program
will be a lot more com
Simon Riggs wrote:
> On Tue, 2006-07-25 at 11:31 -0400, Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > For example, if you do pg_stop_backup(), in what cases would you not
> > > also call pg_finish_wal_segment()? I can't think of one.
> >
> > I can't see why you would need to
* Simon Riggs ([EMAIL PROTECTED]) wrote:
> On Tue, 2006-07-25 at 11:20 -0400, Bruce Momjian wrote:
> > Yes, perhaps, though I can envision a GUC that does regularly partial
> > archiving. I will add a question mark to the item.
>
> I was planning to add a new GUC
>
> archive_timeout (inte
Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > I was planning to add a new GUC
> > archive_timeout (integer) = max # secs between log file switches
>
> That's fine, but feature freeze is in a week and we don't even have the
> basic function for manually doing a log file switch.
Simon Riggs <[EMAIL PROTECTED]> writes:
> I was planning to add a new GUC
> archive_timeout (integer) = max # secs between log file switches
That's fine, but feature freeze is in a week and we don't even have the
basic function for manually doing a log file switch. Let's get that
done first
Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Tue, 2006-07-25 at 11:07 -0400, Tom Lane wrote:
> >> I see no need for that to be "automatic". I'd vote for a simple
> >> function pg_finish_wal_segment() or something like that, which you
> >> call just after pg_stop_backup() if you
On Tue, 2006-07-25 at 11:31 -0400, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > For example, if you do pg_stop_backup(), in what cases would you not
> > also call pg_finish_wal_segment()? I can't think of one.
>
> I can't see why you would need to, unless your intention is not
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Tue, 2006-07-25 at 11:07 -0400, Tom Lane wrote:
>> I see no need for that to be "automatic". I'd vote for a simple
>> function pg_finish_wal_segment() or something like that, which you
>> call just after pg_stop_backup() if you want this behavior. Tryi
Hannu Krosing wrote:
> ?hel kenal p?eval, T, 2006-07-25 kell 11:27, kirjutas Bruce Momjian:
> > Hannu Krosing wrote:
> > > ?hel kenal p?eval, T, 2006-07-25 kell 10:51, kirjutas Bruce Momjian:
> > > > Where are we on these TODO items:
> > > >
> > >
> > > > o Add reporting of the current
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> ISTM that before long someone will want to use more than 2 GB for work_mem.
> Currently, you can't set more because it overflows the variable.
Yes you can, because the value is measured in KB.
Now, if you were to redefine it as being measured in by
Ühel kenal päeval, T, 2006-07-25 kell 11:27, kirjutas Bruce Momjian:
> Hannu Krosing wrote:
> > ?hel kenal p?eval, T, 2006-07-25 kell 10:51, kirjutas Bruce Momjian:
> > > Where are we on these TODO items:
> > >
> >
> > > o Add reporting of the current WAL file, perhaps as part of
> > >
> Tom Lane wrote:
>
> psql could actually tell these apart if it worked just a bit harder.
> CLUSTER with no arguments is the one case, CLUSTER with
> anything after it is the other. Not sure why we couldn't be
> bothered to get that right in psql the first time :-(.
>
Should this go on the
Gevik Babakhani wrote:
> > Removing or disabling the test without removing some of the dangerous
> > capabilities would be a major security hole. For example: postgres can
> > deliver to any authenticated user the contents of any text file on the
> > system that the database user can read. Do yo
-Original Message-
From: "Gevik Babakhani" <[EMAIL PROTECTED]>
To: "pgsql-hackers"
Sent: 25/07/06 11:27
Subject: [HACKERS] root/administartor user check option.
> I would like to start a discussion about having an extra option in PG
> which makes possible to bypass (or not check) whethe
On Tue, 2006-07-25 at 11:07 -0400, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Where are we on these TODO items:
>
> > o Allow point-in-time recovery to archive partially filled
> > write-ahead logs [pitr]
>
> I believe we'd agreed that the necessary infr
Ühel kenal päeval, T, 2006-07-25 kell 11:26, kirjutas Tom Lane:
> Csaba Nagy <[EMAIL PROTECTED]> writes:
> >> Strictly speaking, however, it would have to be NOLOCKLY in that case. :-)
>
> > In this case CREATE INDEX CONCURRENTLY ... sounds better to me, although
> > the whole feature sounds nice
On Tue, 2006-07-25 at 11:20 -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Where are we on these TODO items:
> >
> > > o Allow point-in-time recovery to archive partially filled
> > > write-ahead logs [pitr]
> >
> > I believ
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Dienstag, 25. Juli 2006 09:13 schrieb jkzhao:
>> I am a PostgreSQL lover at China, I'd like to know when the
>> column-level privilege can be added to a release version of PostgreSQL? and
>> is there someone who is working on the problem?
> It woul
Bruce Momjian <[EMAIL PROTECTED]> writes:
> For example, if you do pg_stop_backup(), in what cases would you not
> also call pg_finish_wal_segment()? I can't think of one.
I can't see why you would need to, unless your intention is not to run
PITR at all but only to make a filesystem backup inste
Hannu Krosing wrote:
> ?hel kenal p?eval, T, 2006-07-25 kell 10:51, kirjutas Bruce Momjian:
> > Where are we on these TODO items:
> >
>
> > o Add reporting of the current WAL file, perhaps as part of
> > partial log file archiving
>
> It would be nice to have a function tha
Csaba Nagy <[EMAIL PROTECTED]> writes:
>> Strictly speaking, however, it would have to be NOLOCKLY in that case. :-)
> In this case CREATE INDEX CONCURRENTLY ... sounds better to me, although
> the whole feature sounds nice any way you will finally call it ;-)
That reads well to me too. We'd nee
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I assumed we would have a function like pg_finish_wal_segment(), and
> > server stop and stop_backup would call it too,
>
> That idea is *exactly* what I'm objecting to.
>
> > the reason being, it
> > would greatly simplify our docum
Am Dienstag, 25. Juli 2006 09:13 schrieb jkzhao:
> I am a PostgreSQL lover at China, I'd like to know when the
> column-level privilege can be added to a release version of PostgreSQL? and
> is there someone who is working on the problem?
It would certainly be a welcome feature, but there are
1 - 100 of 126 matches
Mail list logo
