Dear Sir,
thanks for the reply.
I tried select now()
but it gives the following error
syntax error near unexpected token `select.
To be specific about my problem, I want to compare one max date with the
current date in my Java servlet
Since nested queries are not possible,
On Thu, 30 Nov 2000, Thomas Lockhart wrote:
> > Is "if" clause support in PG?
> > for example:
> > "drop table aa if exist"
> > "insert into aa values(1) if not exists select * from aa where i=1"
>
> No. afaict it is not in any SQL standard, so is unlikely to get much
> attention from developer
> Is "if" clause support in PG?
> for example:
> "drop table aa if exist"
> "insert into aa values(1) if not exists select * from aa where i=1"
No. afaict it is not in any SQL standard, so is unlikely to get much
attention from developers.
- Thomas
> our server alternatives; at present only PostgreSQL is left, was the most
> reliable of all.
mind i ask on which platform (Operating system) did you do your test,i'm
mostly used to linux but after i paid my computer (still 5 month
remaining),i want to get a used SGI box from reputable system an
Is "if" clause support in PG?
for example:
"drop table aa if exist"
"insert into aa values(1) if not exists select * from aa where i=1"
I would like PG support it.
---
XuYifeng
- Original Message -
From: John Huttley <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, November 2
Yes, it's OK now. I'll remove #ifdef XLOG in other files soon.
>>
>> OK. Shall I do it, or do you want to?
> If you have nothing to change in bufmgr now then I'll
> do it myself today/tomorrow.
OK, I didn't have any other reason to touch those files now.
regards,
"Magnus Naeslund\(f\)" <[EMAIL PROTECTED]> writes:
> Another other problem that is more severe is that the database "crashes"
> (read: stops working), if i run psql and do a select it says
> "001129.07:04:15.688 [25474] FATAL 1: Memory exhausted in AllocSetAlloc()"
> and fails.
That's odd. Does
At 17:39 29/11/00 -0800, Mikheev, Vadim wrote:
>is done. Initdb is required, sorry.
>
>BTW, why SETVAL is called in pg_dump output instead of
>if (called) NEXTVAL? SETVAL is disallowed for sequences
>with cache_value > 1 - ie we can't dump such sequences now.
Can someone explain this to me? It's
> > Yes, it's OK now. I'll remove #ifdef XLOG in other files soon.
>
> OK. Shall I do it, or do you want to?
If you have nothing to change in bufmgr now then I'll
do it myself today/tomorrow.
Vadim
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> Yes, it's OK now. I'll remove #ifdef XLOG in other files soon.
OK. Shall I do it, or do you want to?
regards, tom lane
* Larry Rosenman <[EMAIL PROTECTED]> [001129 19:54]:
> * Tom Lane <[EMAIL PROTECTED]> [001128 23:03]:
> > Larry Rosenman <[EMAIL PROTECTED]> writes:
> > >> We've called that routine s_lock for a *long* time, so it seems
> > >> like there must be some factor involved that I don't see just yet...
>
> server, before we accept MSSQL, we use this method to test if MSSQL can
endure this kind of strik,
> it's OK, all databases are safely recovered, we can continue our work. we
are a stock exchange company,
And how exactly did you test the integrity of your data? Unless every single
record has g
is done. Initdb is required, sorry.
BTW, why SETVAL is called in pg_dump output instead of
if (called) NEXTVAL? SETVAL is disallowed for sequences
with cache_value > 1 - ie we can't dump such sequences now.
Vadim
* Tom Lane <[EMAIL PROTECTED]> [001128 23:03]:
> Larry Rosenman <[EMAIL PROTECTED]> writes:
> >> We've called that routine s_lock for a *long* time, so it seems
> >> like there must be some factor involved that I don't see just yet...
>
> > Didn't your commit message say something about the TAS a
> Would it be OK now to eliminate the separate xlog_bufmgr.c and
> xlog_localbuf.c files, folding that code back into bufmgr.c and
> localbuf.c? It's a real pain to have to make parallel updates
> in two copies of that code...
Yes, it's OK now. I'll remove #ifdef XLOG in other files soon.
Vadim
Would it be OK now to eliminate the separate xlog_bufmgr.c and
xlog_localbuf.c files, folding that code back into bufmgr.c and
localbuf.c? It's a real pain to have to make parallel updates
in two copies of that code...
regards, tom lane
"Joel Burton" <[EMAIL PROTECTED]> writes:
> I think it wasn't just two views pointing at each other (it would, of
> course, be next to impossible to even create those, unless you hand
> tweaked the system tables), but I think was a view-relies-on-a-
> function-relies-on-a-view kind of problem.
Why is a "select * from table1 where field in (select field from table2
where condition )"
is so dramatically bad compared to:
"select * from table1, table2 where table1.field = table2.field and
condition"
I can't understand why the first query isn't optimized better than the
second one. The 'i
> Ah, I see why the data-directory interlock file wasn't helping: it
> wasn't checked until *after* shared memory was set up (read clobbered
> :-(). This was not a very bright choice. I'm still surprised that
> the shared-memory reset should've trashed your database so thoroughly,
> though.
>
>
"Joel Burton" <[EMAIL PROTECTED]> writes:
> On 25 Nov 2000, at 17:35, Tom Lane wrote:
>> Ugh. The reason that removing the socket file allowed a second
>> postmaster to start up is that we use an advisory lock on the socket
>> file as the interlock that prevents two PMs on the same port number.
>
Kevin O'Gorman wrote:
>
> mlw wrote:
> > Many operating systems used a fixed memory block size allocation for
> > their disk cache. They do not allocate a new block for every disk
> > request, they maintain a pool of fixed sized buffer blocks. So if you
> > use fewer bytes than the OS block size
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Red Hat by default cleans out all files under /tmp and subdirectories that
> haven't been accesses for 10 days. I assume other Linux distributions do
> similar things. Red Hat's tmpwatch doesn't ever follow symlinks, though.
Nor remove them?
> T
Tom Lane writes:
> I can only think of one scenario where this is worse than what we have
> now: if someone is running a /tmp-directory-sweeper that is bright
> enough not to remove socket files, it would still zap the interlock
> file, thus potentially allowing a second postmaster to take over t
Adam Haberlach writes:
> How does Windows manage to work?
Windows NT has hard links.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
>> BTW, it also seems like a good idea to reorder the postmaster's
>> startup operations so that the data-directory lockfile is checked
>> before trying to acquire the port lockfile, instead of after. That
>> way, in the common scenario where you
Matthew Kirkwood <[EMAIL PROTECTED]> writes:
> Surely the lock file could easily go somewhere other than
> /tmp, since it won't be breaking existing setups?
Such as where?
Given the fact that the recent UUNET patch allows the DBA to put the
socket files anywhere, it seems simplest to say that th
At 08:31 PM 11/29/00 +0530, Sanjay Arora wrote:
>Well I want to use nested select statements ,is it possible.
In PG 7.0 you can use subselects in the "where" clause.
>Is there any counterpart for 'Sysdate from dual' as in Oracle
You don't need "dual", just "select now()" will work.
If you're
Hello everybody
First of all I wold like to thank you in advance because I am sure
that I would get my answer immediately.
Well I want to use nested select statements ,is it possible.
Is there any counterpart for 'Sysdate from dual' as in Oracle
with Regards
Sanjay Arora
Matthew Kirkwood wrote:
>
> On Tue, 28 Nov 2000, Tom Lane wrote:
>
> > Nathan Myers <[EMAIL PROTECTED]> writes:
> > > In the event of a power outage, the drive will stop writing in
> > > mid-sector.
> >
> > Really? Any competent drive firmware designer would've made sure that
> > can't happen.
On Tue, 28 Nov 2000, Tom Lane wrote:
> That is, if the socket file name is /tmp/.s.PGSQL.5432, we'd create a
> plain file /tmp/.s.PGSQL.5432.lock
> I can only think of one scenario where this is worse than what we have
> now: if someone is running a /tmp-directory-sweeper that is bright
> enough
On Tue, 28 Nov 2000, Tom Lane wrote:
> Nathan Myers <[EMAIL PROTECTED]> writes:
> > In the event of a power outage, the drive will stop writing in
> > mid-sector.
>
> Really? Any competent drive firmware designer would've made sure that
> can't happen. The drive has to detect power loss well b
- Original Message -
From: Zeugswetter Andreas SB <[EMAIL PROTECTED]>
Subject: AW: [HACKERS] beta testing version
>
> > NO, I just tested how solid PgSQL is, I run a program busy inserting record into
>PG table, when I
> > suddenly pulled out power from my machine and restarted P
Kevin O'Gorman wrote:
>
> mlw wrote:
> >
> > Tom Samplonius wrote:
> >
> > > On Tue, 28 Nov 2000, mlw wrote:
> > >
> > > > Tom Samplonius wrote:
> > > > >
> > > > > On Mon, 27 Nov 2000, mlw wrote:
> > > > >
> > > > > > This is just a curiosity.
> > > > > >
> > > > > > Why is the default postgres
I don't have the same luck, sorry to say!
I am running Mandrake linux with OpenWall patched 2.2.17 kernel, dual p3
550Mhz, 1gb memory.
It's a really busy webserver that constantly is running with 10 in load.
Sometime it spikes to ~40-50 in load (the most we had was 114(!)).
I am running postgresq
From: "Ross J. Reedstrom" <[EMAIL PROTECTED]>
> On Tue, Nov 28, 2000 at 05:19:45PM +0100, Zeugswetter Andreas SB wrote:
> > > I guess it depends on what you're using it for -- disk space
> > > is cheap and
> > > abundant anymore, I can see some advantages of having it
> > > computed only once
>
xuyifeng wrote:
>
> NO, I just tested how solid PgSQL is, I run a program busy inserting record into
>PG table, when I
> suddenly pulled out power from my machine and restarted PG, I can not insert any
>record into database
> table, all backends are dead without any respone (not core dump)
> NO, I just tested how solid PgSQL is, I run a program busy inserting record into
>PG table, when I
> suddenly pulled out power from my machine and restarted PG, I can not insert any
>record into database
> table, all backends are dead without any respone (not core dump), note that I am
> BTW, it also seems like a good idea to reorder the postmaster's
> startup operations so that the data-directory lockfile is checked
> before trying to acquire the port lockfile, instead of after. That
> way, in the common scenario where you're trying to start a second
> postmaster in the same
38 matches
Mail list logo
