On Tue, 26 Jun 2007, Andrew Dunstan wrote:
Jeremy Drake wrote:
2. If you cannot tell what process is connecting on a local socket (which
I suspect you cannot portably),
See ident_unix() in hba.c.
It might not be 100% portable but I think it's fairly close for platforms
that actually
Heikki Linnakangas wrote:
Michael Enke wrote:
My primary goal is to get quasi numeric ordering on text column, e.g.
1
2
10
Normal order with varchar would be
1
10
2
You don't need to custom type for that. A custom operator class with
custom comparison operators is enough.
Ok, I tried
On Thu, 28 Jun 2007, ITAGAKI Takahiro wrote:
Do you need to increase shared_buffers in such case?
If you have something going wild creating dirty buffers with a high usage
count faster than they are being written to disk, increasing the size of
the shared_buffers cache can just make the
Michael Enke [EMAIL PROTECTED] writes:
Heikki Linnakangas wrote:
You don't need to custom type for that. A custom operator class with
custom comparison operators is enough.
Ok, I tried with ordinary varchar and my own operators/op class. But than:
1) the index is never used (I created it
During one of HOT stress tests, an asserition failed at tqual.c:1178
in HeapTupleSatisfiesVacuum(). The assertion failure looked really
strange because the assertion checks for HEAP_XMAX_COMMITTED
which we set just couple of lines above. I inspected the core dump
and found that the flag is *set*
Pavan Deolasee [EMAIL PROTECTED] writes:
So we suspected an interaction between multiple processes each holding
a SHARE lock and setting/checking different bits in the infomask and
we could theoritically say that such interaction can potentially lead to
missing hint bit updates.
Yeah. This
With today's CVS code (originally noticed with 8.2beta3), on a PC where
INT_MAX=0x7FFF=2147483647
postgres=# select version();
version
Pavan Deolasee wrote:
During one of HOT stress tests, an asserition failed at tqual.c:1178
in HeapTupleSatisfiesVacuum(). The assertion failure looked really
strange because the assertion checks for HEAP_XMAX_COMMITTED
which we set just couple of lines above. I inspected the core dump
and found
Patrick Welche [EMAIL PROTECTED] writes:
With today's CVS code (originally noticed with 8.2beta3), on a PC where
INT_MAX=0x7FFF=2147483647
postgres=# select to_char(2147483648,'999,999,999');
WARNING: detected write past chunk end in ExprContext 0x845509c
WARNING: detected write past
Heikki Linnakangas [EMAIL PROTECTED] writes:
AFAICS, we can just simply remove the assertion. But is there any
codepaths that assume that after calling HeapTupleSatisfiesSnapshot, all
appropriate hint bits are set?
There had better not be, since we are going to postpone setting hint
bits for
Tom Lane escribió:
Heikki Linnakangas [EMAIL PROTECTED] writes:
AFAICS, we can just simply remove the assertion. But is there any
codepaths that assume that after calling HeapTupleSatisfiesSnapshot, all
appropriate hint bits are set?
There had better not be, since we are going to
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane escribió:
A quick grep suggests that VACUUM FULL might be at risk here.
That particular case seems easily fixed since VACUUM FULL must hold an
exclusive lock; and we can forcibly set sync commit for VACUUM FULL.
Uh, that wouldn't help. The
This is the problematic part in formatting.c, function dch_time.
int siz =
strlen(tmtcTzn(tmtc));
if (arg == DCH_TZ)
strcpy(inout, tmtcTzn(tmtc));
Hi,
I noticed that lazy vacuum acquires an exclusive lock at the end, to be
able to truncate the table. This is not a surprise. If it cannot
acquire the lock, it simply skips truncating the table and goes on with
life.
However, what's problematic is that if a non-zero cost delay has been
set,
On Thu, 2007-06-28 at 15:16 -0400, Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
AFAICS, we can just simply remove the assertion. But is there any
codepaths that assume that after calling HeapTupleSatisfiesSnapshot, all
appropriate hint bits are set?
There had better not
On Thu, 2007-06-28 at 17:16 -0400, Alvaro Herrera wrote:
I noticed that lazy vacuum acquires an exclusive lock at the end, to be
able to truncate the table. This is not a surprise. If it cannot
acquire the lock, it simply skips truncating the table and goes on with
life.
However, what's
On Thu, 2007-06-28 at 15:29 -0400, Alvaro Herrera wrote:
Tom Lane escribió:
Heikki Linnakangas [EMAIL PROTECTED] writes:
AFAICS, we can just simply remove the assertion. But is there any
codepaths that assume that after calling HeapTupleSatisfiesSnapshot, all
appropriate hint bits
Simon Riggs wrote:
On Thu, 2007-06-28 at 17:16 -0400, Alvaro Herrera wrote:
I noticed that lazy vacuum acquires an exclusive lock at the end, to be
able to truncate the table. This is not a surprise. If it cannot
acquire the lock, it simply skips truncating the table and goes on with
Simon Riggs [EMAIL PROTECTED] writes:
On Thu, 2007-06-28 at 15:16 -0400, Tom Lane wrote:
A quick grep suggests that VACUUM FULL might be at risk here.
No we're clear: I caught that issue specifically for VACUUM FULL fairly
early on. VF assumes all hint bits are set after the first scan, so we
imad [EMAIL PROTECTED] writes:
This is the problematic part in formatting.c, function dch_time.
intsiz = strlen(tmtcTzn(tmtc));
if (arg == DCH_TZ)
strcpy(inout, tmtcTzn(tmtc));
else
{
Alvaro Herrera [EMAIL PROTECTED] wrote:
What I'm requesting here is that the sleep in count_nondeletable_pages()
be removed and that change backpatched to 8.2 and 8.1.
Agreed. We'd better to shorten the exclusive locking as far as possible.
We don't know how many pages we can truncate until
Alvaro Herrera [EMAIL PROTECTED] writes:
What I'm requesting here is that the sleep in count_nondeletable_pages()
be removed and that change backpatched to 8.2 and 8.1.
Are you sure that that is, and always will be, the only sleep in that
part of the code path?
Seems like it might be better to
Bruce, please make sure to keep the list copied on replies. I think
there is an important bug here and I don't want it to get lost just
because I lose track of it. I'm also crossposting to pgsql-hackers.
Bruce McAlister wrote:
okidoki, I tried this:
blueface-crm=# select relname, nspname
Robert Treat wrote:
And while we're talking about things that suck wrt packaging, I noticed it's
now been over a year since I first complained about the stable snapshots in
our ftp directory being outdated
(http://www.postgresql.org/ftp/stable_snapshot/), if no one is going to fix
that,
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
What I'm requesting here is that the sleep in count_nondeletable_pages()
be removed and that change backpatched to 8.2 and 8.1.
Are you sure that that is, and always will be, the only sleep in that
part of the code path?
It is
Alvaro Herrera [EMAIL PROTECTED] writes:
Well, it certainly seems like this shouldn't be happening. Maybe the
table belonged to a session that crashed, but the pg_class entry has not
been cleaned up -- possibly because that backend has not connected to
that particular database.
Hm --- a
Tom Lane wrote:
Patrick Welche [EMAIL PROTECTED] writes:
With today's CVS code (originally noticed with 8.2beta3), on a PC where
INT_MAX=0x7FFF=2147483647
postgres=# select to_char(2147483648,'999,999,999');
WARNING: detected write past chunk end in ExprContext 0x845509c
WARNING:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Well, it certainly seems like this shouldn't be happening. Maybe the
table belonged to a session that crashed, but the pg_class entry has not
been cleaned up -- possibly because that backend has not connected to
that particular
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Yeah, we had better investigate some way to clean them up. It was never
obvious before that it mattered to get rid of orphan temp tables, but I
guess it does.
Would it be enough to delete the tuple from pg_class?
No, you need a full
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Yeah, we had better investigate some way to clean them up. It was never
obvious before that it mattered to get rid of orphan temp tables, but I
guess it does.
Would it be enough to delete the tuple from
Alvaro Herrera [EMAIL PROTECTED] writes:
Oh, I was just thinking in way for Bruce to get out of his current
situation.
Oh, for that a manual drop table as superuser should work fine.
regards, tom lane
---(end of
Heikki Linnakangas [EMAIL PROTECTED] writes:
Added a note to the docs that pg_start_backup can take a long time to
finish now that we spread out checkpoints:
I was starting to wordsmith this, and then wondered whether it's not
just a stupid idea for pg_start_backup to act that way. The reason
32 matches
Mail list logo
