Yes, Thank you!
Tom Lane wrote:
Andrei Kovalevski <[EMAIL PROTECTED]> writes:
2) If I send it as 'PREPARE "SQL_CUR1" AS SELECT 1; SELECT 2; SELECT3;
SELECT4;' and then 'EXECUTE "SQL_CUR1" - I'm getting:
- results for SELECT 1; SELECT2; SELECT 3;
- ReadyForQuery response
- results for SELECT
Andrei Kovalevski <[EMAIL PROTECTED]> writes:
> 2) If I send it as 'PREPARE "SQL_CUR1" AS SELECT 1; SELECT 2; SELECT3;
> SELECT4;' and then 'EXECUTE "SQL_CUR1" - I'm getting:
> - results for SELECT 1; SELECT2; SELECT 3;
> - ReadyForQuery response
> - results for SELECT 4;
> - one more ReadyForQuer
Hello.
I have found an interesting FRONTEND/BACKEND protocol behaviour. Let's
consider following query:
"SELECT 1; SELECT 2; SELECT3; SELECT4;"
1) If I send it as a simple query - I'm getting:
- correct results for SELECT 1; SELECT 2; SELECT3; SELECT4;
- and then one ReadyForQuery response
fro
Simon Riggs wrote:
> On Tue, 2007-11-20 at 14:25 -0500, Bruce Momjian wrote:
> > This has been saved for the 8.4 release:
> >
> > http://momjian.postgresql.org/cgi-bin/pgpatches_hold
> >
>
> It isn't a patch, so isn't being held for later review, nor have you
> added it to the TODO list, so
On Tue, 2007-11-20 at 14:46 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > I notice that there is some variation in the way that different rmgrs
> > use elog levels.
>
> > Heap uses PANIC always
> > BTree uses LOG and PANIC
> > GIN uses ERROR always
> > GIST uses ERROR always
Simon Riggs <[EMAIL PROTECTED]> writes:
> I notice that there is some variation in the way that different rmgrs
> use elog levels.
> Heap uses PANIC always
> BTree uses LOG and PANIC
> GIN uses ERROR always
> GIST uses ERROR always
> Is there a particular reason or benefit for this much variation
On Tue, 2007-11-20 at 14:25 -0500, Bruce Momjian wrote:
> This has been saved for the 8.4 release:
>
> http://momjian.postgresql.org/cgi-bin/pgpatches_hold
>
It isn't a patch, so isn't being held for later review, nor have you
added it to the TODO list, so I'm not sure what this means.
Wo
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Simon Riggs wrote:
> Something Tom Dunstan just mentioned has made me ask the question "Why
> does our full text sear
On Tue, 2007-11-20 at 15:19 +0100, Albe Laurenz wrote:
> "We will fail to restore a consistent database state"
> sounds rather intimidating.
Well, how else should a warning of data loss sound? :-)
It's vaguely possible that the database state could be consistent, if
the server were quiet when yo
"Albe Laurenz" <[EMAIL PROTECTED]> writes:
> wouldn't it be a good thing
> for the startup process to ignore (and rename) the backup_label
> file if no recovery.conf is present?
No, it certainly wouldn't.
I don't see why we should simplify the bizarre case you're talking about
at the price of put
If the postmaster is stopped with 'pg_ctl stop' while an
online backup is in progress, the 'backup_label' file will remain
in the data directory.
There is no recovery.conf file present.
When the server is started again, it attempts to recover from
the checkpoint marked in the backup_label file ev
I notice that there is some variation in the way that different rmgrs
use elog levels.
Heap uses PANIC always
BTree uses LOG and PANIC
GIN uses ERROR always
GIST uses ERROR always
Btree issues a LOG during forget_matching_split(), but does nothing
during forget_matching_deletion().
GIN and GIST
12 matches
Mail list logo
