Re: [HACKERS] COPY TABLE TO

SELECT x, y (SELECT 1 AS ord, COUNT(*) as x, NULL AS y FROM tablex UNION SELECT 2, x, y FROM tablex) May be you will have to do some explicit casting depending on the field types. -- Paulo Scardine - Original Message - From: "Paul Punett" <[EMAIL PROTECTED]> To: &

Re: [pgsql-www] [HACKERS] Changes to Contributor List

Emeritus is verbatin from Latin and is really very spread into most Western languages. -- Paulo Scardine > > I think the "Emeritus" word might be too hard for non-native English > speakers, and even for less educated English speakers. -

Re: [HACKERS] Database Kernels and O_DIRECT

r Bill Gates) and ask for it. As wrote in the original post. Regards, -- Paulo Scardine ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

Re: [HACKERS] Killing the backend to cancel a long waiting query

information can I get about the current running backends on the internal structures? Or do I have to ask the OS? Thank you, -- Paulo Scardine - Original Message - From: "Robert Treat" <[EMAIL PROTECTED]> Subject: Re: [HACKERS] Killing the backend to cancel a long waiting

Re: [HACKERS] Killing the backend to cancel a long waiting query

? -- Paulo Scardine - Original Message - From: "Dave Page" <[EMAIL PROTECTED]> > > It would be awesome for phpPGAdmin as well. eg. Superusers would be > > able to cancel sql queries that gumby users are running, etc. > > I'll second that for pgAdmin.

Re: [HACKERS] Killing the backend to cancel a long waiting query

- Original Message - From: "Tom Lane" <[EMAIL PROTECTED]> > ... > I trust when you say "kill", you really mean "send SIGINT" ... > ... I'm sending a SIGTERM. Would SIGINT be more appropriate? Thank you, -- Paulo Scard

[HACKERS] Killing the backend to cancel a long waiting query

etter way to do that? 2) is it safe to kill the backend this way (other than an user killing the wrong postgres owned proccess)? 3) is this useful for anyone else? Regards, -- Paulo Scardine ---(end of broadcast)--- TIP 6: Have you searched ou

Re: [HACKERS] Maximum table size

ces for testing these limits and ask for donations? Some kind of "core-developers-hardware-wish-list"??? If someone is going to handle this amount of data with Postgres, seems they can contribute with some hardware for the dev team. Here in Brazil we have a say: "who don't cry

[HACKERS] Seqscan in MAX(index_column)

I can just do a very fast (SELECT pk FROM foo ORDER BY pk DESC LIMIT 1) instead, but my coleagues are arguing that MAX(indexed_column) seems to be a lot more smarter in MS-SQLServer and I end up without a good response. Thank you, -- Paulo Scardine Brazil ---(end of

Re: [HACKERS] SELECT FOR UPDATE NOWAIT

quire() with dontWait set? By the way, is this kind of question on-topic for pgsql-hackers? TIA, -- Paulo Scardine - Original Message - From: "Bruce Momjian" <[EMAIL PROTECTED]> To: "Tom Lane" <[EMAIL PROTECTED]> Cc: "Paulo Scardine" <[EMAIL PROT

Re: [HACKERS] SELECT FOR UPDATE NOWAIT

riable than in the parser or is some kind of police (SQL compliance, etc.)? - These locks are grant by LockAcquire() or by higher level functions? - Where is the best place to put this? TIA, -- Paulo Scardine --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http

Re: [HACKERS] SELECT FOR UPDATE NOWAIT

d locked rows. Do you see it as something hard to implement? Any advice? Is it just to add an "opt_nowait" to the "FOR UPDATE" clause in the parser and checking for this option when trying to get the lock later? TIA, -- Paulo Scardine - Original Message - From: "

[HACKERS] SELECT FOR UPDATE NOWAIT

My boss is asking for something like Oracle's "SELECT FOR UPDATE NOWAIT". Is there any such feature? If no, should I look forward into implementing this? Any advice? Thank you, -- Paulo Scardine --- Outgoing mail is certified Virus Free. Checked by AVG anti-vir