pg_get_serial_sequence() does dequoting/downcasing on its relation-name
argument, but not on its column-name argument.
regression=# create table "FOO" ("Ff1" serial);
NOTICE: CREATE TABLE will create implicit sequence "FOO_Ff1_seq" for serial column "FOO.Ff1"
CREATE TABLE
regression=# select pg_ge
pg_get_serial_sequence() does dequoting/downcasing on its relation-name
argument, but not on its column-name argument.
regression=# create table "FOO" ("Ff1" serial);
NOTICE: CREATE TABLE will create implicit sequence "FOO_Ff1_seq" for serial column
"FOO.Ff1"
CREATE TABLE
regression=# select pg_
Hackers,
I'm currently playing with implementing a "shared dependency" catalog,
to keep track of objects pointing to global objects, currently users and
tablespaces. So it is forbidden to drop a user that owns tables (or
whatever objects) on other databases.
So far, it works nicely; it lists obj
Tom Lane wrote:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > So I would suggest using something like 100us as the threshold for
> > determining whether a buffer fetch came from cache.
>
> I see no reason to hardwire such a number. On any hardware, the
> distribution is going to be double-humped,
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Wed, Oct 27, 2004 at 04:21:53PM -0400, Tom Lane wrote:
>> On the other hand, it's also a pretty minor issue, and if it turns out
>> to require a lot of code rejiggering to make it do that, I'd not think
>> it worthwhile.
> Patch attached. It passes
On Wed, Oct 27, 2004 at 04:21:53PM -0400, Tom Lane wrote:
> On the other hand, it's also a pretty minor issue, and if it turns out
> to require a lot of code rejiggering to make it do that, I'd not think
> it worthwhile.
Patch attached. It passes the regression tests. It shouldn't have
secondar
"Jim Buttafuoco" <[EMAIL PROTECTED]> writes:
> I can test Debian Sarge Sparc, Alpha, PowerPC, PA-RISC and M68K if no one else has
> reported on these systems yet.
> Also, with a little work I could test Solaris, Tru64 (or what ever its called these
> days) and IRIX
You should probably wait till
Hackers,
just an fyi, Beta 4 passed ALL tests on Debian Sarge for both MIPS (Indy) and MIPSEL
(Cobalt RAQ)
I can test Debian Sarge Sparc, Alpha, PowerPC, PA-RISC and M68K if no one else has
reported on these systems yet.
Also, with a little work I could test Solaris, Tru64 (or what ever its ca
On Mon, Oct 25, 2004 at 11:34:25AM -0400, Jan Wieck wrote:
> On 10/22/2004 4:09 PM, Kenneth Marshall wrote:
>
> > On Fri, Oct 22, 2004 at 03:35:49PM -0400, Jan Wieck wrote:
> >> On 10/22/2004 2:50 PM, Simon Riggs wrote:
> >>
> >> >I've been using the ARC debug options to analyse memory usage on t
Mark Kirkwood wrote:
I think that bitmap indexes provide a flexible may to get fact access
to the result set
that should be *fast* access tosorry
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.p
Greg Stark wrote:
I think what you're trying to accomplish is better accomplished through
partitioned tables. Then the user can decide which keys to use to partition
the data and the optimizer can use the data to completely exclude some
partitions from consideration. And it wouldn't interfere with
On Wed, 27 Oct 2004, Bruce Momjian wrote:
> Date: Wed, 27 Oct 2004 14:53:26 -0400 (EDT)
> From: Bruce Momjian <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: [HACKERS] Unixware 714 pthreads
>
> [EMAIL PROTECTED] wrote:
> > Dear Bruce,
> >
> > Thanks for your repl
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Oliver Elphick wrote:
>> On Tue, 2004-10-26 at 21:42 -0400, Bruce Momjian wrote:
>>> test=> begin;
>>> BEGIN
>>> test=> commit;
>>> COMMIT
>>> test=> commit;
>>> WARNING: there is no transaction in progress
>>> ROLLBACK
>>
>> It's still a misleading mes
Simon Riggs <[EMAIL PROTECTED]> writes:
> For now, DEBUG1. Longer term, we need to discuss a "performance log" or
> some place to put regularly collected performance statistics, rather
> than site specific ones.
As a data point, with Oracle we often found it useful that Oracle logs all
checkpoin
Reini Urban wrote:
> Magnus Hagander schrieb:
> >>beta4 - cygwin:
> >>postgres.exe fails to build, because __imp__my_exec_path from
> >>src/timezone/pgtz.o cannot be resolved. previously it was not
> >>imported.
> >
> > This could be related to the patch that went in last weekend to fix
> > comp
[EMAIL PROTECTED] wrote:
> Dear Bruce,
>
> Thanks for your reply, I was desperate I did'nt get one!
>
> As I said, I'm quite sure there is a bug in pthread library, Before saying
> this to SCO, I have to prove it. Postgresql is the way to prove it!
>
> What I need is to know where to start from
> >>beta4 - cygwin:
> >>postgres.exe fails to build, because __imp__my_exec_path from
> >>src/timezone/pgtz.o cannot be resolved. previously it was not
> >>imported.
> >
> > This could be related to the patch that went in last weekend to fix
> > compiles on Win32. DLLIMPORT was added to the hea
Magnus Hagander schrieb:
beta4 - cygwin:
postgres.exe fails to build, because __imp__my_exec_path from
src/timezone/pgtz.o cannot be resolved. previously it was not
imported.
This could be related to the patch that went in last weekend to fix
compiles on Win32. DLLIMPORT was added to the header.
Oliver Elphick wrote:
> On Tue, 2004-10-26 at 21:42 -0400, Bruce Momjian wrote:
> > > test=> begin;
> > > BEGIN
> > > test=> commit;
> > > COMMIT
> > > test=> commit;
> > > WARNING: there is no transaction in progress
> > > ROLLBACK
> > >
> > > Is there any reason ROLLBACK and not COMMIT is echoe
Use python's (or another language) CSV reader module which will parse the
quotes for you and write the values in a tab-delimited file. Don't forget
to escape the tabs in the strings... it should be less than 10 lines of
code.
On Mon, 25 Oct 2004 14:45:57 -0700 (PDT), CSN
<[EMAIL PROTECTED
hi.
Please help me. I compiled and install pgadmin 3 version 1.0.2 with
wxGTK 2.4.2_r1 and when i tried to connect to any server this send a
beatiful error Segmentation default o something these. My distribution
is gentoo 2004.2
I don't know how resolve this if you can tell me how i do it.
Sorry
On Mon, Oct 25, 2004 at 05:53:25PM -0400, Tom Lane wrote:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > So I would suggest using something like 100us as the threshold for
> > determining whether a buffer fetch came from cache.
>
> I see no reason to hardwire such a number. On any hardware, the
> d
> beta4 - cygwin:
> postgres.exe fails to build, because __imp__my_exec_path from
> src/timezone/pgtz.o cannot be resolved. previously it was not
> imported.
This could be related to the patch that went in last weekend to fix
compiles on Win32. DLLIMPORT was added to the header. If the Makefile
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> You misunderstood. The 300 secs is not in waiting for unlink() to
> return, it is in waiting for its effects to be seen by rmdir() (i.e. for
> the entry to actually be cleared from the directory). unlink() is
> returning very quickly. If the bgwriter
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> One relatively low-impact workaround would be to force a checkpoint
>> (on Windows only) during DROP DATABASE, just before we actually fire
>> the rmtree() operation. The bgwriter is already coded to close all its
>> open files after
Zeugswetter Andreas DAZ SD wrote:
You misunderstood. The 300 secs is not in waiting for unlink() to
return, it is in waiting for its effects to be seen by
rmdir() (i.e. for
because the bgwriter obviously keeps them open, no ?
Yes.
cheers
andrew
---(end of broadca
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Before I tried anything like that I tried one more thing. I disabled the
background writer and the problem stopped. So now we know the "culprit".
Okay. So what that says is that win32_open's claim to allow unlinking
an open file
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Before I tried anything like that I tried one more thing. I disabled the
> background writer and the problem stopped. So now we know the "culprit".
Okay. So what that says is that win32_open's claim to allow unlinking
an open file is a lie; or at leas
> >>> 300 secs (!) fs timeout is really broken.
> >>> Looks more like a locking or network timeout issue.
> >>> What error codes does unlink(3) return?
> >>
> >
> >> success.
> >
> >
> > Oops! 5min timeout for success is certainly problematic.
> >
> >
>
> You misunderstood. The 300 secs is not in
Andrew Dunstan wrote:
>
>
> Reini Urban wrote:
>
> >>>
> >>> 300 secs (!) fs timeout is really broken.
> >>> Looks more like a locking or network timeout issue.
> >>> What error codes does unlink(3) return?
> >>
> >
> >> success.
> >
> >
> > Oops! 5min timeout for success is certainly problemati
On Tue, 2004-10-26 at 21:42 -0400, Bruce Momjian wrote:
> > test=> begin;
> > BEGIN
> > test=> commit;
> > COMMIT
> > test=> commit;
> > WARNING: there is no transaction in progress
> > ROLLBACK
> >
> > Is there any reason ROLLBACK and not COMMIT is echoed here?
>
> Because the transaction was n
Reini Urban wrote:
300 secs (!) fs timeout is really broken.
Looks more like a locking or network timeout issue.
What error codes does unlink(3) return?
success.
Oops! 5min timeout for success is certainly problematic.
You misunderstood. The 300 secs is not in waiting for unlink() to
return,
Hi,
On Wed, Oct 27, 2004 at 10:13:56AM -0400, Greg Stark wrote:
>
> There's a logical separation between the idea of index methods and table
> storage mechanisms. Trying to implement something like this that breaks that
> abstraction will only make things far more confusing.
>
> I think what you
beta4 - cygwin:
postgres.exe fails to build, because __imp__my_exec_path from
src/timezone/pgtz.o cannot be resolved. previously it was not imported.
dlltool --dllname postgres.exe --output-exp postgres.exp --def postgres.def
gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels
-fno
Andrew Dunstan schrieb:
problem area found. see below.
Reini Urban wrote:
Andrew Dunstan schrieb:
Here is some more info. Below is a trace from dropdb. There is a loop
around the rmdir() calls which I have set to time out at 600 seconds.
The call eventually succeeds after around 300 seconds (I've
Hannu Krosing <[EMAIL PROTECTED]> writes:
> so if I change foo=1 to foo=2 on a tuple that has bar=2 and baz=3 then
> the updated tuple will go to a page for which foo=2, bar=2 and baz=3.
>
> if no such page has enough free space left (found by anding bitmaps for
> foo=2, bar=2 and baz=3 and FSM)
problem area found. see below.
Reini Urban wrote:
Andrew Dunstan schrieb:
Here is some more info. Below is a trace from dropdb. There is a loop
around the rmdir() calls which I have set to time out at 600 seconds.
The call eventually succeeds after around 300 seconds (I've seen this
several time
Dear Bruce,
Thanks for your reply, I was desperate I did'nt get one!
As I said, I'm quite sure there is a bug in pthread library, Before saying
this to SCO, I have to prove it. Postgresql is the way to prove it!
What I need is to know where to start from (I'd like to put elogs where
statement_ti
On K, 2004-10-27 at 00:58, Andre Maasikas wrote:
> Hannu Krosing wrote:
> > the per-page clustering would make sure that all the tuples would be on
> > 1 (or on a few) pages.
>
> I understand that You can cluster on one column, but how do you do it for
> indexes on other columns?
Thanks to Postgr
On Tue, 2004-10-26 at 23:44, Tom Lane wrote:
> In previous releases it was possible to observe whether an automatic
> checkpoint was in progress by looking to see if there was a postmaster
> child process doing one. In 8.0 this will not work because the bgwriter
> is always there. I am thinking t
40 matches
Mail list logo
