"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> I raise this problem because (1) I want to add a stat number for xlog
> write/sync; (2) Considering we may have a background xlog writer (discussed
> long time before), the stats may become pointless for local process.
The bgwriter is already capable o
"Tom Lane" <[EMAIL PROTECTED]> wrote
> "Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> > The problematic line is "0 written" --
>
> What's your point? Those stats are correct for the current process (or
> if not, better take it up with your kernel vendor) and we've never
> stated that they are anyt
"Qingqing Zhou" <[EMAIL PROTECTED]> writes:
> The problematic line is "0 written" --
What's your point? Those stats are correct for the current process (or
if not, better take it up with your kernel vendor) and we've never
stated that they are anything else than process-local stats. In every
ver
I wrote:
> Hmm, this seems like a plpgsql deficiency. It feels it can generate a
> separate parameter symbol ($n) for each occurrence of each variable it
> passes into a SQL query. But for this query to be legal, the two
> instances of IntervalMinutes have to be represented by the *same*
> parame
test=# set log_statement_stats = on;
SET
test=# checkpoint;
LOG: QUERY STATISTICS
DETAIL: ! system usage stats:
! 0.100725 elapsed 0.00 user 0.00 system sec
! [0.00 user 0.001999 sys total]
! 0/0 [0/0] filesystem blocks in/out
!
"Davidson, Robert" <[EMAIL PROTECTED]> writes:
> ERROR: column "em.email_creation_datetime" must appear in the GROUP BY =
> clause or be used in an aggregate function
> CONTEXT: SQL statement " select to_char(to_timestamp(EXTRACT(HOUR FROM =
> em.email_creation_datetime) || ':' || (EXTRACT(MINUTE
"Rafael Jorge Sierra Goncales" <[EMAIL PROTECTED]> writes:
> =# CREATE LANGUAGE "plpythonu"
> Program received signal SIGABRT, Aborted.
This most likely indicates an Assert failure (did you build with
--enable-cassert?) There should be a TRAP message in the postmaster
log if so. Seeing that woul
"Alexander Kirpa" <[EMAIL PROTECTED]> writes:
> In case abnormal exit (for instance 'ERROR: invalid UTF-8 byte sequence
> detected near byte 0xc3') from application based on Perl (5.8.8) with access
> to Postgres over DBD::Pg (1.47) temporary tables still unremoved.
Please provide a complete test
"Gloria W" <[EMAIL PROTECTED]> writes:
> ERROR: invalid input syntax for type timestamp with time zone: "2006-03-20
> 09:06:00 US/Pacific"
That is not currently supported, sorry. Timestamp input can only use
the timezone names known to the "date token table", which basically
is the short abbrevi
The following bug has been logged online:
Bug reference: 2354
Logged by: Mike Haller
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.3-1
Operating system: Windows 2000
Description:No admin rights, but still refuses to run
Details:
Hi Postgres-People,
i hav
it works when run manually, it looks like the combination NSIS
installer and the MSI installer doesn't work very well.
I did what you suggested, I created a user before launching the
installer and the installer failed this time with the following error.
User "some binary signs"4/"some binary s
The following bug has been logged online:
Bug reference: 2352
Logged by: Rafael Jorge Sierra Goncales
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.3
Operating system: NetBSD-3.0
Description:Bug with Pl/Python
Details:
I'm trying run this command:
=# CREA
The following bug has been logged online:
Bug reference: 2353
Logged by: Alexander Kirpa
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.3
Operating system: FreeBSD 6.0
Description:Temporary tables created within trigger function still
exist after abend
Detai
The following bug has been logged online:
Bug reference: 2350
Logged by: Gloria W
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.2
Operating system: Red Hat 2.6.9-11.ELsmp #1 SMP Fri May 20 18:26:27 EDT
Description:Timezone string fails in a certain context
On Wed, 22 Mar 2006, Marinos Yannikos wrote:
> Stephan Szabo schrieb:
> > AFAICS, our behavior follows SQL.
> >
> > a NOT IN b is NOT(a IN b)
> > IN is defined in terms of = ANY.
> > a =ANY (b) is basically (by my reading of 8.8 anyway):
> > True if a = bi for some bi in b
> > False if b is emp
This isn't a bug. Authentication for the user just failed.
> [java] org.postgresql.util.PSQLException: FATAL: Ident authentication
> failed for user "dspace"
On Mon, Mar 20, 2006 at 07:38:39AM +, rama krishna wrote:
>
> The following bug has been logged online:
>
> Bug reference:
16 matches
Mail list logo
