Tom Lane <[EMAIL PROTECTED]> wrote:
> I think the only serious objection to this would be that it'd mean that
> tuples that should have an index entry might not have one.
This can occurs when we do REINDEX after DELETE, because dead tuples are
excluded on REINDEX. So we cannot guarantee that all
I would like to start a discussion about having an extra option in PG
which makes possible to bypass (or not check) whether the current user
has root/administrative privileges especially (or only) for Windows.
The following is the situation:
It would be great to be able to distribute PG as standa
Thank you for your quick answering my question. > Tom.
Tom Lane wrote:
> SAKATA Tetsuo <[EMAIL PROTECTED]> writes:
>> I'll be pleased if someone tell me the reason why
>> when a table is clustered the toast table is not reindexed.
>
> It's not obvious that those two things should be related. You
Am Dienstag, 25. Juli 2006 12:01 schrieb Gevik Babakhani:
> I would like to start a discussion about having an extra option in PG
> which makes possible to bypass (or not check) whether the current user
> has root/administrative privileges especially (or only) for Windows.
This has been shot down
> This has been shot down many times before, and the arguments you are
> presenting are not new.
Has there been a solution found for the arguments/issues. Is there any
history about why at some point we decided to enforce the security
option?
---(end of broadcast)-
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. I'm not
sure a wholesale switch of GUC integers to 64 bit is the solution. Maybe
changing some of the variables to reals would work. Comments?
--
Pet
Dear hackers,
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?
Thanks & Best Regards.
jkzhao
2006-07-25
> 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 you want the responsibility
> of
Gevik Babakhani <[EMAIL PROTECTED]> writes:
>> This has been shot down many times before, and the arguments you are
>> presenting are not new.
> Has there been a solution found for the arguments/issues. Is there any
> history about why at some point we decided to enforce the security
> option?
R
Humm, perhaps it would be great learning curve for me to begin with
something to be like a "Embedded PG for Windows" or "PG Light for
Windows"...(Daydreaming now..)
On Tue, 2006-07-25 at 08:26 -0400, Alvaro Herrera wrote:
> Gevik Babakhani wrote:
> > > Removing or disabling the test wi
Am Dienstag, 25. Juli 2006 14:15 schrieb Tom Lane:
> 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 i
Am Dienstag, 25. Juli 2006 06:55 schrieb Bruce Momjian:
> Or maybe CREATE INDEX x ON tab NOLOCK Having the NOLOCK
> associated with the table name makes sense.
Semantically, NOLOCK (or whatever word) seems most closely associated with
CREATE INDEX, so having it as third word would make sense
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 you want the resp
Where are we on these TODO items:
o Allow point-in-time recovery to archive partially filled
write-ahead logs [pitr]
Currently only full WAL files are archived. This means that the
most recent transactions aren't available for recovery in case
I am looking for assistance in extending the buildfarm web app in two
directions that need expertise that I lack.
First, I want to build a search engine for the log files. I recently
started storing these in a table, one row per log file, rather than as a
single gzipped tar blob per run. Thi
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Dienstag, 25. Juli 2006 14:15 schrieb Tom Lane:
>> I'd be fairly worried about whether that wouldn't mean we fail
>> completely on INT64_IS_BROKEN platforms ...
> I wonder whether platforms with INT64_IS_BROKEN can address more than 2GB of
> memor
Peter Eisentraut wrote:
> Am Dienstag, 25. Juli 2006 06:55 schrieb Bruce Momjian:
> > Or maybe CREATE INDEX x ON tab NOLOCK Having the NOLOCK
> > associated with the table name makes sense.
>
> Semantically, NOLOCK (or whatever word) seems most closely associated with
> CREATE INDEX, so havi
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 infrastructure for this is
just a function to tell the current WAL se
> Semantically, NOLOCK (or whatever word) seems most closely associated with
> CREATE INDEX, so having it as third word would make sense, and it would be
> quite easy to parse for psql.
>
> Strictly speaking, however, it would have to be NOLOCKLY in that case. :-)
In this case CREATE INDEX CONC
Gevik Babakhani wrote:
This has been shot down many times before, and the arguments you are
presenting are not new.
Has there been a solution found for the arguments/issues. Is there any
history about why at some point we decided to enforce the security
option?
There is nothing new
On Mon, Jul 17, 2006 at 10:45:23AM -0700, Neil Conway wrote:
> On Mon, 2006-07-17 at 10:11 -0700, Josh Berkus wrote:
> > On the other hand, if we include PL/Perl, Tcl and Python but exclude Ruby
> > from the main package we are effectively making a statement to Ruby users
> > that their language
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 infrastructure for this is
> just a fun
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 documentation on how to use PITR if t
Ü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 that tells both filename and offset
of c
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> I think the only serious objection to this would be that it'd mean that
>> tuples that should have an index entry might not have one.
> This can occurs when we do REINDEX after DELETE, because dead tuples are
> e
Michael Fuhr <[EMAIL PROTECTED]> writes:
> test=> set timezone_abbreviations to 'India';
> WARNING: time zone abbreviation "ist" is multiply defined
> DETAIL: Time zone file "Default", line 282 conflicts with file "India", line
> 11.
> ERROR: invalid value for parameter "timezone_abbreviations"
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
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
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
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
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
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
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
Ü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: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
-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
> 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
Ü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
> > >
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
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
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
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
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
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:
> > 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]) 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
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
> 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
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,
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
Ü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: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
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
Ü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
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
"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
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
> 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
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
> > 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
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
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
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
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
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:
>> 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
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
"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 ...
* 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
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
[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
"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
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
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
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
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
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
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
Ü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
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 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
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-
>
> 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
[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
-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
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
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
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
"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.
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
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
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
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
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
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
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
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
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
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
1 - 100 of 126 matches
Mail list logo
