On Tue, 17 Oct 2000, Alex Pilosov wrote:
> I just ran into a strangest thing: within transaction, select now() will
> always return time when transaction started. Same happens with select
> 'now'::timestamp.
It's feature, not bug. IMHO good feature, an example I use it for rows
identification
> BTW, avoiding writes is base WAL feature, ie - it'll be
> implemented in 7.1.
Wow, great, I thought first step was only to avoid sync :-)
> > No, but rollforward is currently the main feature, no ?
>
> I'm going to rollback changes on abort in 7.1. Seems I've
> mentioned both redo and UNDO (w
> > The Upper- and the lower function don't convert the german
> umlauts (ü.ä.ö.) but leave them in their original condition
>
> Gert (or anyone): what should the result be? I'm German-impaired, so
> you'll need to be more specific. Did you compile with locale
> turned on?
> Multi-byte charact
Hi all
I see heap_tuple_toast_attrs() calls in heapam.c.
When they are called from heap_update/delete()
,a buffer is locked.
OTOH heap_tuple_toast_attrs() calls heap_open(..,
.., RowExclusiveLock). Hmm,try to acquire a
RowExclusiveLock while locking a buffer.
Is there no problem ?
Regards.
Hiros
At 10:38 18/10/00 +0200, Zeugswetter Andreas SB wrote:
>
>We should not call this tx log business "Incremental backup"
>an incremental backup scans all pages, and backs
>them up if they changed in respect to the last higher level backup.
>(full backup, level 1 backup, level 2 backup )
You may
> >We should not call this tx log business "Incremental backup"
> >an incremental backup scans all pages, and backs
> >them up if they changed in respect to the last higher level backup.
> >(full backup, level 1 backup, level 2 backup )
>
> You may be tying implementation too closely to func
Bruce Momjian wrote:
>> Alfred Perlstein wrote:
>> >
>> > I noticed that INHERITS doesn't propogate indecies, It'd be nice
>> > if there was an toption to do so.
>>
>> Yep it would. Are you volunteering?
>>
>
>Added to TODO:
>
> * Allow inherited tables to inherit inde
> Current CVS does this correctly when compiled with --enable-locale,
> so imho we don't have a bug here, since we can't do this sort of thing without
>locale.
Great.
> PS: Thomas, can you please forward to the report originator.
afaict, no. He entered a name only, not a valid email address :(
The following patch was sent to the patches list:
This patch forces the use of 'DROP VIEW' to destroy views.
It also changes the syntax of DROP VIEW to
DROP VIEW v1, v2, ...
to match the syntax of DROP TABLE.
Some error messages were changed so this patch also includes changes to the
appropriat
Tom Lane writes:
> That is what now() is defined to return: transaction start time.
> Perhaps the documentation needs improvement...
Then CURRENT_TIMESTAMP is in violation of SQL.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
* Oliver Elphick <[EMAIL PROTECTED]> [001018 04:59] wrote:
> Bruce Momjian wrote:
> >> Alfred Perlstein wrote:
> >> >
> >> > I noticed that INHERITS doesn't propogate indecies, It'd be nice
> >> > if there was an toption to do so.
> >>
> >> Yep it would. Are you volunteering?
> >>
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> That is what now() is defined to return: transaction start time.
> Then CURRENT_TIMESTAMP is in violation of SQL.
Au contraire, if it did not behave that way it would violate the spec.
See SQL92 6.8 general rule 3:
3) I
On Tue, 17 Oct 2000, Tom Lane wrote:
> > and we have not had a crash on vacuum since that happened. If this
> > sounds consistent with the problem you think Alfred is having,
>
> Yes, it sure does.
>
> The patch I have applies atop a previous change in the REL7_0_PATCHES
> branch, so what I w
Michael J Schout <[EMAIL PROTECTED]> writes:
> ERROR: RelationClearRelation: relation 1668325 modified while in use
> relation 1668325 is a view named "sessions".
Hm. This message is coming out of the relation cache code when it sees
an invalidate-your-cache-for-this-relation message from anoth
Tom Lane writes:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Tom Lane writes:
> >> That is what now() is defined to return: transaction start time.
>
> > Then CURRENT_TIMESTAMP is in violation of SQL.
>
> Au contraire, if it did not behave that way it would violate the spec.
> See SQL92
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> I see heap_tuple_toast_attrs() calls in heapam.c.
> When they are called from heap_update/delete()
> ,a buffer is locked.
Hm. Seems like it would be better to do the tuple toasting before
we lock the target buffer...
regards, t
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> Au contraire, if it did not behave that way it would violate the spec.
>> See SQL92 6.8 general rule 3:
>>
>> 3) If an SQL-statement generally contains more than one reference
>> to one or more s, then all such ref-
>> erences are
I've just successfully completed an out of the box VPATH build of
PostgreSQL (i.e., putting the object files in a different directory
structure than the source files). It should be ready to go within the
next few days.
This is an opportune time to sort out the use of the make variables
CPPFLAGS
> Done. Do you know often the web-based version of the documentation get
> updated?
Should be twice a day. afaik you can go to hub.org:~thomas/CURRENT and
run ./docbuild. Make sure your umask is set to 2 (so I can update files
after that) and you may want to detach the command and log it to a fil
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> This is an opportune time to sort out the use of the make variables
> CPPFLAGS and CFLAGS, which are used interchangeably in some places.
> Unfortunately, this would mean having to fix each of the targets
> dep depend:
> $(CC) -MM $(CFLAGS) *
> (because the preprocessor options like -I and -D would be in CPPFLAGS).
> I can install a hook to make this work specially without need to fix each
> file, but that would require GNU make 3.76 for those using `make depend'.
> I think this should not bother anyone too much, but I'm just letti
Thomas Lockhart <[EMAIL PROTECTED]> writes:
>> Done. Do you know often the web-based version of the documentation get
>> updated?
> Should be twice a day.
Where is this auto-updated copy hiding? The bookmark I have,
http://www.postgresql.org/docs/postgres/index.html
is pointing at files
I'm trying to use the php/postgresql interface via my apache server.
When I try and load a page containing:
(both the database and owner are valid and tested via psql)
apache complains:
/usr/libexec/ld.so: Undefined symbol "_PQconnectdb" called from
httpd:/usr/lib/apache/modules/libphp4.so
Tom Lane writes:
> > dep depend:
> > $(CC) -MM $(CFLAGS) *.c >depend
>
> Why? Shouldn't CFLAGS include CPPFLAGS?
Nope. That's what it does now, but the implicit rule is
%.o: %.c
$(CC) -c $(CPPFLAGS) $(CFLAGS)
so if you set CFLAGS to include CPPFLAGS then you get all of it
double
Bruce Momjian writes:
> > > > First, since when are we in the business of hiding away documentation for
> > > > a supported platform, and second, how does putting installation
> > > > instructions into a file named "FAQ" make it less "obvious"?
> > >
> > > Help, I am losing here. Does anyone wa
Alfred Perlstein wrote:
>* Oliver Elphick <[EMAIL PROTECTED]> [001018 04:59] wrote:
>> Do you mean that inheriting tables should share a single index with their
>> ancestors, or that each descendant should get a separate index on the
>> same pattern as its ancestors'?
>>
>> With the
No. I will turn it into an FAQ, and the item will be "How do I install
PostgreSQL on MS Windows". How's that?
> Bruce Momjian writes:
>
> > > > > First, since when are we in the business of hiding away documentation for
> > > > > a supported platform, and second, how does putting installation
Tom Lane writes:
> So? It also says that the choice of exactly when to evaluate now()
> is implementation-dependent. Doing so at start of transaction is
> an allowed behavior AFAICS.
But it's only talking about statements. You can't reuse things that you
calculated for previous statements unl
At 12:39 PM 10/18/00 -0400, Tom Lane wrote:
>Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> Tom Lane writes:
>>> Au contraire, if it did not behave that way it would violate the spec.
>>> See SQL92 6.8 general rule 3:
>>>
>>> 3) If an SQL-statement generally contains more than one reference
>>>
> > BTW, avoiding writes is base WAL feature, ie - it'll be
> > implemented in 7.1.
>
> Wow, great, I thought first step was only to avoid sync :-)
? If syncs are not required then why to do write call?
> > > No, but rollforward is currently the main feature, no ?
> >
> > I'm going to rollback
> Do we have the info when a page was last modified (in respect
> to a WAL position, not wallclock time) on each page ? This is
> probably an info we will need.
How else one could know was a change applied to page or not?
Vadim
On Wed, 18 Oct 2000, Tom Lane wrote:
> I think what you are advocating is recomputing now() at each statement
> boundary within a transaction, but that's not as simple as it looks
> either. Consider statement boundaries in an SQL function --- the
> function is probably being called from some out
Alex Pilosov <[EMAIL PROTECTED]> writes:
>> Consider statement boundaries in an SQL function --- the
>> function is probably being called from some outer statement, so
>> advancing now() within the function would violate the spec constraint
>> with respect to the outer statement.
> Postgres doesn'
I have removed the new --export-dynamic item from the Solaris FAQ.
Looks like 7.1 has it fixed already.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Chris
Tom Lane wrote:
> Alex Pilosov <[EMAIL PROTECTED]> writes:
> >> Consider statement boundaries in an SQL function --- the
> >> function is probably being called from some outer statement, so
> >> advancing now() within the function would violate the spec constraint
> >> with respect to the outer
Matthew <[EMAIL PROTECTED]> writes:
>> Anyway, any comments? Can anyone else repeat this? I hope this is easy to
>> fix. I guess the quick fix is to disallow multiple users to be specified
>> in the drop user command.
The correct fix is CommandCounterIncrement() in the DROP USER loop,
so that
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
Postgres doesn't have an idea of what a 'top-level' statement is? I.E.
statement as submitted by a client (libpq)?
>>
>> There's never been any reason to make such a distinction.
> There's already a distinction.
> Snapshot is made per top-level
Tom Lane wrote:
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Postgres doesn't have an idea of what a 'top-level' statement is? I.E.
> statement as submitted by a client (libpq)?
> >>
> >> There's never been any reason to make such a distinction.
>
> > There's already a distinction.
>
I notice that ProcessUtility() calls SetQuerySnapshot() for FETCH
and COPY TO statements, and nothing else.
Seems to me this is very broken. Isn't a query snapshot needed for
any utility command that might do database accesses?
regards, tom lane
Does anyone know if there is an operator class that supports the money data
type?
When I issue a command like :
create index "table1_price_idx" on "table" using btree ("price"
"money_ops");
or
create index "table1_price_idx" on "table" using btree ("price"
"float8_ops");
I get errors like :
ERROR:
"Rich Ryan" <[EMAIL PROTECTED]> writes:
> Does anyone know if there is an operator class that supports the money data
> type?
There is not.
Type money is on its way out anyway, at least in its current
incarnation, because it's (a) nonstandard, (b) doesn't support
a reasonable number of digits, a
41 matches
Mail list logo