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?
http://www.post
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
> > syst
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 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
"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
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.
Cl
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, b
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 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
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. #
# L
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 a
"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
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
t
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
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 s
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 a
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 inves
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
"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 ans
-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 on_error_
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
d
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 database
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 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 w
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 p
> > > 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
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
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 :
>
> print_plan(queryDesc->plantree,que
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
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 postgre
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 tak
>> 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 th
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
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 ins
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 PROTECTED][EMAIL
> [ 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?
--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 transactio
37 matches
Mail list logo
