--On Freitag, Oktober 27, 2006 11:00:07 +0530 Gurjeet Singh
[EMAIL PROTECTED] wrote:
I was thinking of recommending this to someone, but wanted to try it on
my own first; good thing that I did. I think it is broken as of now.
I assume that the error thrown for 'select 1', inside a
[ Memo to hackers: why is it that log_min_error_statement = error
isn't the default? ]
To avoid spamming the logs with every failed SQL statement?
Yours,
Laurenz Albe
---(end of broadcast)---
TIP 4: Have you searched our list archives?
Thanks ...but case-sensitivity (even without quotes or d-quotes) is the last thing I'd expect in a SQL compliant software. This was highly unexpected. May I dare to raise a bug to eliminate case-sensitivity in psql variables? Will I get support from the community?
Regards,-- [EMAIL
On Fri, 2006-10-27 at 09:23, Albe Laurenz wrote:
[ Memo to hackers: why is it that log_min_error_statement = error
isn't the default? ]
To avoid spamming the logs with every failed SQL statement?
And it would be hurting applications where query failure is taken as a
valid path (as
Gurjeet Singh wrote:
Thanks ...
but case-sensitivity (even without quotes or d-quotes) is the last thing
I'd
expect in a SQL compliant software. This was highly unexpected. May I dare
to raise a bug to eliminate case-sensitivity in psql variables? Will I get
support from the community?
In the WAL we just need to be able to detect torn pages and stop
reading WAL at that point. That's easier and doesn't really need a
CRC. We could just adopt the Sybase strategy of storing a unique id
number every 512 bytes throughout the WAL page. If those numbers
don't
match then we
Csaba Nagy wrote:
On Fri, 2006-10-27 at 09:23, Albe Laurenz wrote:
[ Memo to hackers: why is it that log_min_error_statement = error
isn't the default? ]
To avoid spamming the logs with every failed SQL statement?
And it would be hurting applications where query failure is taken as a
Hi,I want to print the query-plan that will be used before the execution of the query. Therefore put this line at the beginning of the ExecutorStart() function located in execMain.c :print_plan(queryDesc-plantree,queryDesc-parsetree);However, it did not work. What I want to ask is:1. Does
On Fri, 2006-10-27 at 10:54 +0200, Zeugswetter Andreas ADI SD wrote:
In the WAL we just need to be able to detect torn pages and stop
reading WAL at that point. That's easier and doesn't really need a
CRC. We could just adopt the Sybase strategy of storing a unique id
number every 512
On Fri, Oct 27, 2006 at 01:58:21AM -0700, dakotali kasap wrote:
Hi,
I want to print the query-plan that will be used before the execution
of the query. Therefore put this line at the beginning of the
ExecutorStart() function located in execMain.c :
On Fri, Oct 27, 2006 at 10:11:08AM +0100, Simon Riggs wrote:
Putting xl_prev to the end helps only for direct IO WAL sync methods,
else we would need it on every page.
[There is already an XLogRecPtr on each 8k page.]
Given that hardware sector size is still 512 bytes, should there be a
Putting xl_prev to the end helps only for direct IO WAL sync
methods, else we would need it on every page.
[There is already an XLogRecPtr on each 8k page.]
Given that hardware sector size is still 512 bytes, should
there be a way of detecting a missing 512 byte block in the
I understand that psql commands are not SQL, but since psql is used to interact with SQL database, then the assumption of case-insensitivity in psql also comes naturally to the user.\ds and \dS are commands (first token on the line) so it is acceptable that they be case-sensitive. But a command's
Hi, I want to print the query-plan that will be used before the execution of the query. Therefore put this line at the beginning of the ExecutorStart() function located in execMain.c : print_plan(queryDesc-plantree,queryDesc-parsetree); print_plan writes to stdout, did you check where that is
Try your logfile... the one specified by the '-l' option while starting the server.On 10/27/06, dakotali kasap
[EMAIL PROTECTED] wrote:
But how can I find where stout is redirected to?
Baran
-- [EMAIL PROTECTED][EMAIL PROTECTED] gmail | hotmail | yahoo }.com
Hi,
I'm using postgresql 8.1-407 jdbc driver with postgresql 7.4.13 database and
it seems like there is an issue when the driver is used in jdbc
transactions. I'm using this version of the jdbc driver, cause I haven't
came across any fixes for the 8.1.4 security issuse for the 7.4.13
This belongs on the jdbc driver list
On 27-Oct-06, at 6:29 AM, lasitha weerasinghe wrote:
Hi,
I'm using postgresql 8.1-407 jdbc driver with postgresql 7.4.13
database and it seems like there is an issue when the driver is
used in jdbc transactions. I'm using this version of the jdbc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This is documented clearly on the psql man page, so it is simply not a
bug, and changing this would probably break lots of legacy scripts.
In a general sense, perhaps, but in this *particular* case, I don't
see what harm allowing \set
Albe Laurenz [EMAIL PROTECTED] writes:
[ Memo to hackers: why is it that log_min_error_statement = error
isn't the default? ]
To avoid spamming the logs with every failed SQL statement?
Certainly there are people who will turn it off, but that's why it's
configurable. I've had to answer how
Am Donnerstag, 26. Oktober 2006 19:47 schrieb Neil Conway:
Note that this patch breaks the translations of these strings, so I
haven't applied it yet. Should I apply it now, or wait for 8.3 to
branch?
I appreciate this effort, but I think it's better to hold the patch.
--
Peter Eisentraut
Am Dienstag, 17. Oktober 2006 11:59 schrieb Hannu Krosing:
Several of the failures appear to be a simple change in error reporting;
I haven't investigated why import_succeed() failed.
Should python 2.5 work with plpython?
This is about pl_python ?
Forwarding to Sven to investigate
Any
bruce wrote:
FYI, I am leaving Friday for a two-week trip for EnterpriseDB. I am
going to Tokyo, Islamabad (Pakistan), and Pune (India). I return on
Friday, November 10. I will have Internet connectivity, but of course I
will not be online as frequently as usual.
My plans have changed and
On Fri, 2006-10-27 at 15:59 +0200, Peter Eisentraut wrote:
I appreciate this effort, but I think it's better to hold the patch.
Sure, I'll wait for 8.3 to branch.
-Neil
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please
On Fri, 2006-10-27 at 03:50 -0500, Andrew Dunstan wrote:
psql variables and commands are not SQL, and are case sensitive. For
example, \ds and \dS are not at all the same.
This is documented clearly on the psql man page, so it is simply not a
bug
It may be documented, but \set still has a
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
I would've liked to give freezing a new opcode,
but we've ran out of them (see htup.h).
Hardly ... we have plenty of unused rmgr id's still.
Good point.
The real issue that still has to be resolved is the interaction of all
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think it's premature to start writing
patches until we've decided how this really needs to work.
Not logging hint-bit updates seems safe to me. As long as we have the
clog, the hint-bit is just a hint. The problem with freezing
Gurjeet Singh wrote:
\ds and \dS are commands (first token on the line) so it is
acceptable that they be case-sensitive. But a command's
parameters/arguments should not be case sensitive, unless quoted.
This distinction has not basis in SQL syntax.
If it is documented that psql commands are
since rev. 1.105 of include/port.h all files that inlcude postgres_fe.h
are forced to use pg_qsort() instead of qsort. Was that intended?
Jan
--
#==#
# It's easier to get forgiveness for being wrong than for being right. #
#
On Wed, 25 Oct 2006, Bruce Momjian wrote:
...snip...
Data partitioning is often done within a single database on a single
server and therefore, as a concept, has nothing whatsoever to do with
different servers. Similarly, the second paragraph of this section is
Uh, why would someone
Jan Wieck [EMAIL PROTECTED] writes:
since rev. 1.105 of include/port.h all files that inlcude postgres_fe.h
are forced to use pg_qsort() instead of qsort. Was that intended?
Is it a problem? If you really want the platform qsort you can #undef
qsort, but I don't entirely see why you would.
On 10/27/2006 3:47 PM, Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
since rev. 1.105 of include/port.h all files that inlcude postgres_fe.h
are forced to use pg_qsort() instead of qsort. Was that intended?
Is it a problem? If you really want the platform qsort you can #undef
qsort,
Jan Wieck [EMAIL PROTECTED] writes:
On 10/27/2006 3:47 PM, Tom Lane wrote:
Is it a problem? If you really want the platform qsort you can #undef
qsort, but I don't entirely see why you would.
It forces client programs to link against libpgport, which they didn't
have to before.
Client
Simon Riggs [EMAIL PROTECTED] writes:
[I've just coded the relcache invalidation WAL logging patch also.]
What? That doesn't make any sense to me.
regards, tom lane
---(end of broadcast)---
TIP 3: Have you checked our
On Fri, 2006-10-27 at 12:01 -0400, Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think it's premature to start writing
patches until we've decided how this really needs to work.
Not logging hint-bit updates seems safe to me. As long as we have the
On Wed, 2006-10-18 at 15:56 +0100, Simon Riggs wrote:
On Tue, 2006-10-17 at 22:29 -0400, Tom Lane wrote:
The answer that ultimately emerged was that they'd been running a
nightly maintenance script that did REINDEX SYSTEM (among other things
I suppose). The PITR base backup included
On Fri, 2006-10-27 at 22:19 +0100, Simon Riggs wrote:
So we definitely have a nasty problem here.
VACUUM FREEZE is just a loaded gun right now.
Maybe it's OK to say that during WAL replay we keep it
all the way back to the freeze horizon, but I'm not sure how we keep the
system from
Neil,
Sure, I'll wait for 8.3 to branch.
I have some cleanup I want to do for 8.3 too.
Josh Berkus
PostgreSQL @ Sun
San Francisco 415-752-2500
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
37 matches
Mail list logo
