> | > Placing a restriction on an application that says it must treat the
values
> | > returned from a sequence as if they might not be committed is absurd.
> |
> | Why? The fact that you are not able to rollback sequences does not
> | necessary mean that you are not required to perform commit to
Last year we had a drawn out discussion about this and I created a patch
for it. I never noticed that the patch didn't go in until I installed
7.2 the other day and realised that fe-connect.c never was fixed.
Here is the patch again. It is against CVS 3/16/2002. This time I only
rewrote the
On Fri, 2002-03-15 at 21:45, Lance Ellinghaus wrote:
> The application actually does not want nor need a consistent view of the
> data. It is expecting that records that are locked will not be viewed at
> all. The locks are normally held for VERY short periods of time. The fact
> that the applicat
On Fri, 2002-03-15 at 19:44, Kyle wrote:
[snip]
> Wouldn't Tom's suggestion of riding on top of ssh would give similar
> results? Anyway, it'd probably be a good proof of concept of whether
> or not it's worth the effort. And that brings up the question: how
> would you measure the benefit? I'
The application actually does not want nor need a consistent view of the
data. It is expecting that records that are locked will not be viewed at
all. The locks are normally held for VERY short periods of time. The fact
that the application is expecting locked records not to be viewed is causing
m
Tony Reina wrote:
> I know it's probably a long shot, but has anyone coded statistical
> distributions as functions in PostgreSQL? Specifically, I'm looking
> for a function to calculate the cumulative F distribution.
>
> By the way, I know that I can do /df at the psql command line to list
> the
I do basically the same thing for files. Except I md5 a 4 character
random string, and the sequence ID just incase I get the same one
twice -- as it's never been written in stone that I wouldn't -- not to
mention the high number of requests for returning a sequence ID back
to the pool on a rollba
(userland comment)
On Fri, Mar 15, 2002 at 01:05:33AM -0800, Vadim Mikheev wrote:
| > But sequences should not be under transaction control. Can you
| > safely rollback a sequence? No! The only way to ensure that would
| ...
| > Placing a restriction on an application that says it must treat t
Greg Copeland wrote:
> [cut]
> My current thoughts are to allow for enabled/disabled compression and
> variable compression settings (1-9) within a database configuration.
> Worse case, it may be fun to implement and I'm thinking there may
> actually be some surprises as an end result if it's don
I know it's probably a long shot, but has anyone coded statistical
distributions as functions in PostgreSQL? Specifically, I'm looking
for a function to calculate the cumulative F distribution.
By the way, I know that I can do /df at the psql command line to list
the available functions. Is there
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > Is it worth keeping this password capability in 7.3? It requires
> > 'password' in pg_hba.conf, which is not secure, and I am not sure how
> > many OS's still use crypt in /etc/passwd anyway. Removing the feature
> > would clear up pg_hba.co
Bruce Momjian writes:
> Is it worth keeping this password capability in 7.3? It requires
> 'password' in pg_hba.conf, which is not secure, and I am not sure how
> many OS's still use crypt in /etc/passwd anyway. Removing the feature
> would clear up pg_hba.conf options a little.
Personally, I
On Fri, 2002-03-15 at 18:23, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > AFAIK, current Postgres behavior when processing SELECT queries is like
> > this:
> > (1) for each tuple in the result set, try to get an
> > AccessShareLock on it
>
> Uh, no. There are no
Neil Conway <[EMAIL PROTECTED]> writes:
> AFAIK, current Postgres behavior when processing SELECT queries is like
> this:
> (1) for each tuple in the result set, try to get an
> AccessShareLock on it
Uh, no. There are no per-tuple locks, other than SELECT FOR UPDATE
which doesn
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Right now, we support a secondary password file reference in
> > pg_hba.conf.
> > Is it worth keeping this password capability in 7.3?
>
> I'd not cry if it went away. We could get rid of pg_passwd, which
> is an ugly mess...
Yes,
> There is a problem with epoch as well that was not in the 7.1.3
Hmm. 7.1.x did not implement any date_part() functions for time types.
So the results were obtained from a conversion to interval before
calling date_part()!
7.2 implements date_part() for time with time zone, and converts time
wi
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Right now, we support a secondary password file reference in
> pg_hba.conf.
> Is it worth keeping this password capability in 7.3?
I'd not cry if it went away. We could get rid of pg_passwd, which
is an ugly mess...
regards, to
I had an idea on a possible way to increase performance under query
loads with a lot of short-term locking. I haven't looked at the
implementation of this at all, so if someone could tell me why this
wouldn't work, that would save me some time ;-)
AFAIK, current Postgres behavior when processing
Right now, we support a secondary password file reference in
pg_hba.conf.
If the file contains only usernames, we assume that it is the list of
valid usernames for the connection. If it contains usernames and
passwords, like /etc/passwd, we assume these are the passwords to be
used for the conne
On Fri, 2002-03-15 at 16:24, Neil Conway wrote:
> On Fri, 2002-03-15 at 14:54, Lance Ellinghaus wrote:
> > I know it does not sound like something that would need to be done, but here
> > is why I am looking at doing this...
> >
> > I am trying to replace a low level ISAM database with PostgreSQL
On Fri, 2002-03-15 at 14:54, Lance Ellinghaus wrote:
> I know it does not sound like something that would need to be done, but here
> is why I am looking at doing this...
>
> I am trying to replace a low level ISAM database with PostgreSQL. The low
> level ISAM db allows locking a record during a
Are you trying to do a select for update?
Greg
On Fri, 2002-03-15 at 13:54, Lance Ellinghaus wrote:
> I know it does not sound like something that would need to be done, but here
> is why I am looking at doing this...
>
> I am trying to replace a low level ISAM database with PostgreSQL. The lo
Vince Vielhaber <[EMAIL PROTECTED]> writes:
> On Fri, 15 Mar 2002, Thomas Lockhart wrote:
>> But I *really* don't see the benefit of that (.)
>> syntax. Especially when it cannot (?? we need a counterexample) lead to
>> any additional interesting beneficial behavior.
> The only benefit I can come
I know it does not sound like something that would need to be done, but here
is why I am looking at doing this...
I am trying to replace a low level ISAM database with PostgreSQL. The low
level ISAM db allows locking a record during a read to allow Exclusive
access to the record for that process.
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> It is somewhat complicated by the fact that my code tree is pretty
> massively changed in this area as I implement an int64-based date/time
> storage alternative to the float64 scheme we use now. The alternative
> would be enabled with something like #
Sorry for the previous sarcastic response.
But I *really* don't see the benefit of that (.)
syntax. Especially when it cannot (?? we need a counterexample) lead to
any additional interesting beneficial behavior.
- Thomas
---(end of broadcast)--
Greg Copeland wrote:
> On Thu, 2002-03-14 at 14:03, Arguile wrote:
>
> [snip]
>
> > I'm sceptical of the benefit such compressions would provide in this setting
> > though. We're dealing with sets that would have to be compressed every time
> > (no caching) which might be a bit expensive on a data
On Thu, 2002-03-14 at 19:43, Bruce Momjian wrote:
> Kyle wrote:
> > On the subject on client/server compression, does the server
> > decompress toast data before sending it to the client? Is so, why
> > (other than requiring modifications to the protocol)?
> >
> > On the flip side, does/could th
On Thu, 2002-03-14 at 14:03, Arguile wrote:
[snip]
> I'm sceptical of the benefit such compressions would provide in this setting
> though. We're dealing with sets that would have to be compressed every time
> (no caching) which might be a bit expensive on a database server. Having it
> as a def
> Attached is a patch against current CVS that fixes both of the known
> problems with sequences: failure to flush XLOG after a transaction
Great! Thanks... and sorry for missing these cases year ago -:)
Vadim
---(end of broadcast)---
TIP 1: subsc
> Well, we were gonna release it last weekend, but now it's waiting on
> sequence fixes (currently being tested). And Lockhart may also wish to
> hold it up while he looks at the recently reported timestamp_part
> problem. (Thomas, are you considering backpatching that?) One way
> or another I'
"Thomas F. O'Connell" <[EMAIL PROTECTED]> writes:
> is there any further word on 7.2.1, at this point? haven't seen mention
> of it on the list in a while? is it still waiting on something big?
Well, we were gonna release it last weekend, but now it's waiting on
sequence fixes (currently being t
> > > Looking at the entire message noted
> > > above the list of other dbs that support it is now Oracle, Sybase,
> > > MS-SQL and mysql. If "other dbs" ends up the equivilent of "everything
> > > but PostgreSQL" then which one is non-standard?
The one(s) that intentionally violate or gratuitou
is there any further word on 7.2.1, at this point? haven't seen mention
of it on the list in a while? is it still waiting on something big?
-tfo
Bruce Momjian wrote:
> Applied to current and 7.2.X. Thanks.
>
> (No delay for /contrib commits from maintainers.)
---(end
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Ian Barwick wrote:
> On Thursday 14 March 2002
> There is a problem with epoch as well that was not in the 7.1.3
> 7.1.3# select extract(epoch from '00:00:34'::time), now();
> 7.1.3# 34 2002-03-05 22:13:16 +01
> Is that a bug or I didn't understand the new date/time types ?
Looks like a bug (or at least it looks like it behaves differently t
"'Ben Grimm'" <[EMAIL PROTECTED]> writes:
> On Fri, 15 Mar 2002, Tom Lane wrote:
>> What's bug #3? I don't recall a third issue.
> The problem I was seeing before is that when the postmaster was shutdown
> properly, log_cnt in the sequence record was saved with whatever value it
> had at the t
Tom Lane wrote:
> 2. I renamed XLogCtl->RedoRecPtr to SavedRedoRecPtr, and renamed
> the associated routines to SetSavedRedoRecPtr/GetSavedRedoRecPtr,
> in hopes of reducing confusion.
Good.
> 3. I believe it'd now be possible to remove SavedRedoRecPtr and
> SetSavedRedoRecPtr/GetSavedRedoRecPtr
Tom Lane wrote:
> Attached is a patch against current CVS that fixes both of the known
> problems with sequences: failure to flush XLOG after a transaction
> that only does "SELECT nextval()", and failure to force a new WAL
> record to be written on the first nextval after a checkpoint.
> (The lat
"Lance Ellinghaus" <[EMAIL PROTECTED]> writes:
> Is there an easy way to test the lock on a user level lock without actually
> issuing the lock?
Why would you ever want to do such a thing? If you "test" the lock but
don't actually acquire it, someone else might acquire the lock half a
microsecon
Attached is a patch against current CVS that fixes both of the known
problems with sequences: failure to flush XLOG after a transaction
that only does "SELECT nextval()", and failure to force a new WAL
record to be written on the first nextval after a checkpoint.
(The latter uses Vadim's idea of l
"'Ben Grimm'" <[EMAIL PROTECTED]> writes:
> When these bugs are fixed there is still the issue of bug #3 that I
> came across. The one that I work around by resetting log_cnt to 0 when a
> backend initializes a sequence. It's this third bug that made the other
> two so apparent. Fixing them
On Fri, Mar 15, 2002 at 10:25:09AM +0100, Jean-Paul ARGUDO wrote:
> > You mean ECPG should/could replace a PEPARE statement with a CREATE
> > FUNCTION and then the usage of the cursor with the usage of that
> > function?
> >
> > Should be possible, but needs some work.
>
> Wow Michael, this woul
> > AFAIK some SQL/C type precompilers and other frontend tools for other
> > databases do generate stored procedures for PREPAREd CURSORs.
>
> You mean ECPG should/could replace a PEPARE statement with a CREATE
> FUNCTION and then the usage of the cursor with the usage of that
> function?
>
> S
> But sequences should not be under transaction control. Can you
> safely rollback a sequence? No! The only way to ensure that would
...
> Placing a restriction on an application that says it must treat the values
> returned from a sequence as if they might not be committed is absurd.
Why? The
45 matches
Mail list logo
