"Alvaro Herrera" <[EMAIL PROTECTED]> writes
> Because we can't reuse MultiXactIds at system crash (else we risk taking
> an Id which is already stored in some tuple), we need to XLog it. Not
> at the locking operation, because we don't want to log that one (too
> expensive.) We can log the curre
""Mike G."" <[EMAIL PROTECTED]> writes
>
> If "1663/17269/1677179: Permission denied" refers to a file under the data
directory (I have found a folder 17269 that contains similiar names to
1677179) then it would seem postgres is trying to write data to a file that
does not exist.
>
I don't think
Oliver Jowett <[EMAIL PROTECTED]> writes:
> In fact, the logging for the extended query protocol really sucks:
Without doubt. Someone has to sit down and think about exactly what
we should log, where when and how ... proposals welcome ...
regards, tom lane
--
http://archives.postgresql.org/pgsql-hackers/2005-03/msg00260.php
I don't see any other discussions about it in the archives.
I too get these from time to time on my W2K box. Mostly the permission denied
entries.
If "1663/17269/1677179: Permission denied" refers to a file under the data
dir
Greg Stark wrote:
> Palle Girgensohn <[EMAIL PROTECTED]> writes:
>
>>When setting log_statement = all, and using JDBC PreparedStatements, I get $n
>>in the log where the real arguments used to be in previous versions of
>>postgresql:
> You might want to look into JDBC options to disable use of pr
Oliver Jowett wrote:
Query-level EXECUTE is logged, but Bind/Execute via the V3 extended
query protocol (which is what the JDBC driver does) isn't.
Ah, I see. Yes, that certainly needs to be fixed.
-Neil
---(end of broadcast)---
TIP 8: explain analyze
Neil Conway wrote:
> Christopher Kings-Lynne wrote:
>
>> I think he has a really excellent point. It should log the parameters
>> as well.
>
>
> neilc=# prepare foo(int, int) as select $1 + $2;
> PREPARE
> neilc=# execute foo(5, 10);
> ...
> neilc=# execute foo(15, 20);
> ...
>
> % tail /usr/l
On Thu, Apr 07, 2005 at 12:14:19PM +1000, Neil Conway wrote:
> Christopher Kings-Lynne wrote:
> >I think he has a really excellent point. It should log the parameters
> >as well.
>
> neilc=# prepare foo(int, int) as select $1 + $2;
> PREPARE
> neilc=# execute foo(5, 10);
> ...
> neilc=# execute
At 2005-04-07 12:14:19 +1000, [EMAIL PROTECTED] wrote:
>
> % tail /usr/local/pgsql/postmaster.log
> LOG: statement: prepare foo(int, int) as select $1 + $2;
> LOG: statement: execute foo(5, 10);
> LOG: statement: execute foo(15, 20);
If you send a v3 protocol execute message instead of an SQL E
Christopher Kings-Lynne wrote:
I think he has a really excellent point. It should log the parameters
as well.
neilc=# prepare foo(int, int) as select $1 + $2;
PREPARE
neilc=# execute foo(5, 10);
...
neilc=# execute foo(15, 20);
...
% tail /usr/local/pgsql/postmaster.log
LOG: statement: prepare f
Hackers,
Again I come back to this topic. Now I have a better hold on an idea
that is hopefully implementable and doesn't have expensive performance
penalties.
Forget the idea of using the regular lock manager directly on tuples.
It's folly because we can't afford to have that many locks. Inste
postgres[30059]: [97-1] LOG: statement: INSERT INTO group_data (this_group_id,
item_text, link_path) VALUES ($1, $2, $3)
I really need to know the *real* arguments... How can I get them? Is it a bug?
The bug was that prepared statements didn't work properly in the past. That is
the statement you'
On Wed, 2005-04-06 at 18:09 -0400, Tom Lane wrote:
> I wrote:
> > Arjen van der Meijden <[EMAIL PROTECTED]> writes:
> >> SELECT COUNT(*) FROM
> >> data_main AS dm,
> >> postcodes AS p
> >> WHERE dm.range BETWEEN p.range_from AND p.range_till
>
> > Planner error ... because it doesn't have any good
John A Meinel <[EMAIL PROTECTED]> writes:
> Actually, I think he was saying do a nested loop, and for each item in
> the nested loop, re-evaluate if an index or a sequential scan is more
> efficient.
> I don't think postgres re-plans once it has started, though you could
> test this in a plpgsql f
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Wed, Apr 06, 2005 at 06:09:37PM -0400, Tom Lane wrote:
>> Can anyone suggest a more general rule? Do we need for example to
>> consider whether the relation membership is the same in two clauses
>> that might be opposite sides of a range restriction?
On Wed, Apr 06, 2005 at 06:09:37PM -0400, Tom Lane wrote:
> Can anyone suggest a more general rule? Do we need for example to
> consider whether the relation membership is the same in two clauses
> that might be opposite sides of a range restriction? It seems like
>
> a.x > b.y AND a.x < b
I wrote:
> Arjen van der Meijden <[EMAIL PROTECTED]> writes:
>> SELECT COUNT(*) FROM
>> data_main AS dm,
>> postcodes AS p
>> WHERE dm.range BETWEEN p.range_from AND p.range_till
> Planner error ... because it doesn't have any good way to estimate the
> number of matching rows, it thinks that way
> -Original Message-
> From: Marc G. Fournier [mailto:[EMAIL PROTECTED]
> Sent: 06 April 2005 16:07
> To: Dave Page
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: 8.0.2 beta announcement??
>
>
> beta was packaged, and announced, last Friday/Saturday
> *scratch head* I
> didn't p
I am on a trip again. This time I am in Kansas City, Missouri doing
training from yesterday until Friday, and I am back again next week from
Tuesday to Thursday.
This of course delays my reading of email.
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa
beta was packaged, and announced, last Friday/Saturday *scratch head* I
didn't put it on pgsql-announce, only pgsql-general, so that might be the
mix up?
On Wed, 6 Apr 2005, Dave Page wrote:
Magnus & I have been looking out for the official 8.0.2 beta
announcement before we announce the win32 b
Palle Girgensohn <[EMAIL PROTECTED]> writes:
> When setting log_statement = all, and using JDBC PreparedStatements, I get $n
> in the log where the real arguments used to be in previous versions of
> postgresql:
>
> postgres[30059]: [97-1] LOG: statement: INSERT INTO group_data
> (this_group_id
On Tue, 5 Apr 2005, Alvaro Herrera wrote:
What happenned to your two phase commit patch? Are you still working on
it? Have you got something done from the last time we heard from you?
I've kept it up-to-date by doing "cvs update" every now and then and
fixing possible conflicts.
It would be nic
Hi!
When setting log_statement = all, and using JDBC PreparedStatements, I get
$n in the log where the real arguments used to be in previous versions of
postgresql:
postgres[30059]: [97-1] LOG: statement: INSERT INTO group_data
(this_group_id, item_text, link_path) VALUES ($1, $2, $3)
I reall
> -Original Message-
> From: Neil Conway [mailto:[EMAIL PROTECTED]
> Sent: 06 April 2005 10:57
> To: Dave Page
> Cc: pgsql-hackers@postgresql.org; Marc G. Fournier
> Subject: Re: [HACKERS] 8.0.2 beta announcement??
>
> Dave Page wrote:
> > Magnus & I have been looking out for the offic
Dave Page wrote:
Magnus & I have been looking out for the official 8.0.2 beta
announcement before we announce the win32 binaries that were built last
week. Did we miss it (I can't see anythign in the archives), or have
plans changed?
http://archives.postgresql.org/pgsql-general/2005-03/msg01311.php
Magnus & I have been looking out for the official 8.0.2 beta
announcement before we announce the win32 binaries that were built last
week. Did we miss it (I can't see anythign in the archives), or have
plans changed?
Regards, Dave.
---(end of broadcast)
26 matches
Mail list logo
