> 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
> > 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
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
"'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
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
"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
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
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
"'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
> 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
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
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
> > > 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
"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
> 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'
> 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
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
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
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)--
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 #
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.
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
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
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
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
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
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
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
> 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
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,
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
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
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
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
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
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
(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
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
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
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
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'
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
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
> | > 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
45 matches
Mail list logo
