On Mon, Aug 23, 2004 at 03:20:09PM -0400, Tom Lane wrote:
> strk <[EMAIL PROTECTED]> writes:
> > Is returning a pointer to the input safe in every case ?
>
> You mean for returning *unmodified* input, don't you?
>
> Yes, that's safe. Scribbling on input values is definitely never safe.
>
>
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > Tom Lane <[EMAIL PROTECTED]> writes:
> >> According to the previous port report from Red Hat, the PS2 chip simply
> >> doesn't have any user-space TAS instruction, so you're pretty much stuck.
>
> > Out of curiosity
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Actually, the previous port report for 7.4 already required explicit
> disabling:
> needs new config.guess, --disable-spinlocks
Yeah, because *normal* ARM processors have a TAS instruction,
and configure only recognizes that you have an ARM.
Ap
Tom Lane wrote:
> > If that's not worth the trouble, would it be a good idea to have
> > configure disable spinlocks automagically on unsupported platforms?
>
> It used to do that. We deliberately changed this in 8.0 so that
> people would be aware that they were losing performance, and would be
>
On Tue, 24 Aug 2004, Greg Stark wrote:
>
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > Chris <[EMAIL PROTECTED]> writes:
> > > I've compiled 8.0 beta 1 on a R5900 V3.1 (a playstation 2) running
> > > Linux (PS2 Linux 1) for portability testing.
> > > ...
> > > I'm wondering: would it be hard to fix
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> According to the previous port report from Red Hat, the PS2 chip simply
>> doesn't have any user-space TAS instruction, so you're pretty much stuck.
> Out of curiosity. If it lacks a tas instruction, is there really a
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> With the new timezone stuff, is there any reason this shouldn't be made
> to work now in CVS:
> test=# select current_timestamp at time zone 'Australia/Perth';
> ERROR: time zone "australia/perth" not recognized
Lack of round tuits. We have
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Tue, 24 Aug 2004, Christopher Kings-Lynne wrote:
>> OK, what I mean is to know if a row is locked by any backend, why can't
>> we just put a reference count of the number of locks on that row,
>> instead of recording each backend separately? Wouldn't
Tom Lane <[EMAIL PROTECTED]> writes:
> Chris <[EMAIL PROTECTED]> writes:
> > I've compiled 8.0 beta 1 on a R5900 V3.1 (a playstation 2) running
> > Linux (PS2 Linux 1) for portability testing.
> > ...
> > I'm wondering: would it be hard to fix the assembly spinlock code
> > for the R5900?
>
> Ac
With the new timezone stuff, is there any reason this shouldn't be made
to work now in CVS:
test=# select current_timestamp at time zone 'Australia/Perth';
ERROR: time zone "australia/perth" not recognized
Chris
---(end of broadcast)---
TIP 2: you
On Tue, 24 Aug 2004, Christopher Kings-Lynne wrote:
> > Uh ... the interesting question is usually not "does this backend hold
> > any row locks", it is "is this row locked by any backends". If the
> > latter question is not *exceedingly* cheap to answer, at least in the
> > normal case where th
Uh ... the interesting question is usually not "does this backend hold
any row locks", it is "is this row locked by any backends". If the
latter question is not *exceedingly* cheap to answer, at least in the
normal case where the answer is no, you don't have a workable solution,
because you'll be
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> ie. why can't we just record the number of locks each backend has, sort
> of, and use a reference counting sort of method. Per-backend in case
> the backend dies and we need to discount those locks..?
Uh ... the interesting question is usual
pg_subtrans is trivial to index --- it's a linear array subscripted by
TransactionId. I'm not sure what we'd do to handle row locks, which
would need a key like (DBoid, RELoid, BlockNum, LineNum) and would be
extremely non-dense in that space.
'Tis something to think about though...
I've been thin
Philip Warner <[EMAIL PROTECTED]> writes:
> At 01:27 PM 24/08/2004, Tom Lane wrote:
>> I prefer declaring it as unsigned, which means you drop the
>> \377 end instead ...
> ...I've used explicit values (128) since '\200' is -127.
Actually I'd go with "(unsigned char) '\200'". There's a bunch
of
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> so, its trying bigint = int, and not picking up the index ...
> the database server is 7.4.3 ... is this something that has been made a
> bit more intelligent in 8.0? other then casting 0 to bigint, is there
> something else I should be looking a
On Tue, Aug 24, 2004 at 09:17:59AM +0800, Christopher Kings-Lynne wrote:
> Just random speculation, but could we use a pg_subtrans-like setup to do
> row share locks?
>
> ie. Store them in a sort of table to avoid the problems with limited
> shared memory size?
Hmm ... how would you map the row
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Just random speculation, but could we use a pg_subtrans-like setup to do
> row share locks?
pg_subtrans is trivial to index --- it's a linear array subscripted by
TransactionId. I'm not sure what we'd do to handle row locks, which
would need
At 01:27 PM 24/08/2004, Tom Lane wrote:
I prefer declaring it as unsigned, which means you drop the
\377 end instead ...
No problem.
Philip Warner| __---_
Albatross Consulting Pty. Ltd. |/ - \
Philip Warner <[EMAIL PROTECTED]> writes:
> At 01:58 AM 24/08/2004, Alvaro Herrera wrote:
>> static int _isIdentChar(unsigned char c)
> I think the correct thing to do is to leave it as (signed) char, and remove
> the comparison to \200 = -127.
No, that isn't the right thing, because not all pla
At 01:27 PM 24/08/2004, Tom Lane wrote:
I prefer declaring it as unsigned, which means you drop the
\377 end instead ...
...I've used explicit values (128) since '\200' is -127.
Philip Warner| __---_
Albatr
Chris <[EMAIL PROTECTED]> writes:
> I've compiled 8.0 beta 1 on a R5900 V3.1 (a playstation 2) running
> Linux (PS2 Linux 1) for portability testing.
> ...
> I'm wondering: would it be hard to fix the assembly spinlock code
> for the R5900?
According to the previous port report from Red Hat, the P
Just had a "performance" question from a client ... the query they were
running, through EXPLAIN ANALYZE, was showing 37ms to resolve ... there
are indices on the two fields being queried, but only used on one of them
...
by changing the query *very slightly* (adding ::bigint to force-cast one
At 01:58 AM 24/08/2004, Alvaro Herrera wrote:
static int _isIdentChar(unsigned char c)
I think the correct thing to do is to leave it as (signed) char, and remove
the comparison to \200 = -127. All chars will be >= -127. I will fix this
in the next release.
--
At 12:11 PM 24/08/2004, Neil Conway wrote:
I get the following warnings compiling current sources:
My fault; I'll fix it in the next patch to pg_dump etc. I compare a char to
the range \200 through \377. It must always be >= \200...at least I assume
that's the problem.
--
I get the following warnings compiling current sources:
/Users/neilc/pgsql/src/bin/pg_dump/pg_backup_db.c: In function
`_isIdentChar':
/Users/neilc/pgsql/src/bin/pg_dump/pg_backup_db.c:874: warning:
comparison is always true due to limited range of data type
/Users/neilc/pgsql/src/bin/pg_dump/pg_
Just random speculation, but could we use a pg_subtrans-like setup to do
row share locks?
ie. Store them in a sort of table to avoid the problems with limited
shared memory size?
Chris
Tom Lane wrote:
Log Message:
---
Rearrange pg_subtrans handling as per recent discussion. pg_subtrans
in order to debug "step by step" the postmaster,
just to understand better the code, is it enough
to compile it after having exported:
CFLAGS='-O0 -g' ?
do you have any hint and/or tips ?
BTW what do you use for this task ?
./configure --enable-debug
Chris
---(end of broadca
If you're not missing your data dir, clog or xlog then what's the problem?
Daniel Kalchev wrote:
Hello,
Is there ANY chance to recover data from a database system that suffered disk
crash, and is not missing the data/global directory?
Version is 7.2.4. Database files seem to be intact as well as
Hi,
I've compiled 8.0 beta 1 on a R5900 V3.1 (a playstation 2) running
Linux (PS2 Linux 1) for portability testing.
Here is what make check gave:
Without --disable-spinlocks
compilation *appears* to be fine, but the backends core dumps
on the spinlock assembly in s_lock.c (signal 4 -- illegal
in
On Mon, Aug 23, 2004 at 10:19:20PM +0200, Manfred Spraul wrote:
> >Does it make sense to add a platform specific call that will flush a write
> >cache when fsync is enable?
> >
> Pete Zaitsev from mysql wrote that there is a special call on Mac OS:
> Quoting him:
>
> >Mac OS X also has this "opti
On Tue, Aug 24, 2004 at 12:05:33AM +0200, Gaetano Mendola wrote:
> Simon Riggs wrote:
>
> >As a result, I have thought that there may be a way to remove those pages
> >from the xlog files immediately before being copied away to archive,
> >without effecting crash recovery logic AT ALL.
>
> So th
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> As a result, I have thought that there may be a way to remove those pages
> from the xlog files immediately before being copied away to archive, without
> effecting crash recovery logic AT ALL.
This isn't all that easy. The main problem I can see is tha
Simon Riggs wrote:
As a result, I have thought that there may be a way to remove those pages
from the xlog files immediately before being copied away to archive, without
effecting crash recovery logic AT ALL. The archiver process could read the
xlog files and re-write them exactly as read to anothe
Alvaro Herrera wrote:
> On Mon, Aug 23, 2004 at 10:03:26PM +0100, Simon Riggs wrote:
>
> Simon,
>
> > I raise this now because I'm thinking that this functionality really ought
> > to be in the main production 8.0 release. Not sure if anybody will
> > agreebut that's what I'm thinking now, ba
On Mon, Aug 23, 2004 at 10:03:26PM +0100, Simon Riggs wrote:
Simon,
> I raise this now because I'm thinking that this functionality really ought
> to be in the main production 8.0 release. Not sure if anybody will
> agreebut that's what I'm thinking now, based upon what seems like a
> simple
Bruce Momjian wrote:
> Gaetano Mendola wrote:
>
>>Hi all,
>>I don't want be a pain in the but now that 7.4.5 is
>>officially out I think is time to change the version doc on:
>>
>>http://www.postgresql.org/docs/7.4/interactive/index.html
> I have updated the FAQ.
??
However I see now the right
> Bruce Momjian wrote
>
>P O S T G R E S Q L
>
> 8 . 0 O P E NI T E M S
>
a few comments...
> * add xid to log_line_prefix for PITR
This at first sounded like a wonderfully simple solution, though on
consideration, I'm not sure I'd r
One of the possible barriers to adoption of PITR is the volume of the logs
themselves. Maybe this isn't a problem for now, maybe it is.
Re-thinking the whole purpose of the additional full page images appended to
the xlog records, I now understand and agree with Tom's comment in the docs
that we
[EMAIL PROTECTED] wrote:
Something to think about:
if you run PostgreSQL with fsync on, but you use the hardware write cache
on your disk drives, how likely are you to lose data? Obviously, this is a
fairly limited problem, as it only applies to power down (which you can
control) or power loss wher
Tom,
This is basically what I had in mind, but you described it better than I ever
could :)
What I need from this database system is just one database and probably not
all of the tables anyway (but some do seem valuable). This database happens to
be second in the pg_dumpall script. The next da
strk <[EMAIL PROTECTED]> writes:
> Is returning a pointer to the input safe in every case ?
You mean for returning *unmodified* input, don't you?
Yes, that's safe. Scribbling on input values is definitely never safe.
regards, tom lane
---(end of
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Marc G. Fournier wrote:
>>> We avoided this with oids but it seems we have added another. I don't
>>> see a good way of avoiding this like we had with oids.
>>
>> Isn't that what hte proposed (or implemented?) "SET DEFAULT_TABLESPACE"
>> was for?
> No
Daniel Kalchev <[EMAIL PROTECTED]> writes:
> Is there ANY chance to recover data from a database system that suffered disk
> crash, and is not missing the data/global directory?
> Version is 7.2.4. Database files seem to be intact as well as pg_clog and
> pg_xlog directories.
The hard part I thin
[EMAIL PROTECTED] wrote:
> Something to think about:
>
> if you run PostgreSQL with fsync on, but you use the hardware write cache
> on your disk drives, how likely are you to lose data? Obviously, this is a
> fairly limited problem, as it only applies to power down (which you can
> control) or po
[EMAIL PROTECTED] writes:
> Something to think about:
>
> if you run PostgreSQL with fsync on, but you use the hardware write cache
> on your disk drives, how likely are you to lose data? Obviously, this is a
> fairly limited problem, as it only applies to power down (which you can
> control) or p
Something to think about:
if you run PostgreSQL with fsync on, but you use the hardware write cache
on your disk drives, how likely are you to lose data? Obviously, this is a
fairly limited problem, as it only applies to power down (which you can
control) or power loss where the risks may be reduc
On August 20, 2004 09:01 pm, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Darcy Buskermolen wrote:
> > >>> * remove to_char(interval) if we initdb or mention removal
> > >>
> > >> I vote just to mention it's removal at this time,
> > >
> > > Agreed. Do
Is returning a pointer to the input safe in every case ?
--strk;
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Hi all,
in order to debug "step by step" the postmaster,
just to understand better the code, is it enough
to compile it after having exported:
CFLAGS='-O0 -g' ?
do you have any hint and/or tips ?
BTW what do you use for this task ?
Regards
Gaetano Mendola
---(end of broadca
I have updated the FAQ.
---
Gaetano Mendola wrote:
> Hi all,
> I don't want be a pain in the but now that 7.4.5 is
> officially out I think is time to change the version doc on:
>
> http://www.postgresql.org/docs/7.4/in
Hi all,
I don't want be a pain in the but now that 7.4.5 is
officially out I think is time to change the version doc on:
http://www.postgresql.org/docs/7.4/interactive/index.html
Regards
Gaetano Mendola
---(end of broadcast)---
TIP 2: you can ge
Hackers,
I'm seeing this:
gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations
-I/home/alvherre/CVS/pgsql/source/00orig/src/interfaces/libpq -I../../../src/include
-I/home/alvherre/CVS/pgsql/source/00orig/src/include -D_GNU_SOURCE -DFRONTEND -c -o
pg_backup_db.o
Marc G. Fournier wrote:
> On Mon, 23 Aug 2004, Bruce Momjian wrote:
>
> > Philip Warner wrote:
> >> At 03:15 PM 23/08/2004, Tom Lane wrote:
> >>
> >>> I thought the idea was for pg_dump to emit something like
> >>>
> >>> SET magic_tablespace_variable = some_ts;
> >>> CREATE TABLE f
On Mon, 23 Aug 2004, Bruce Momjian wrote:
Philip Warner wrote:
At 03:15 PM 23/08/2004, Tom Lane wrote:
I thought the idea was for pg_dump to emit something like
SET magic_tablespace_variable = some_ts;
CREATE TABLE foo (columns...);
rather than
CREATE TABLE foo (columns...)
On Mon, 2004-08-23 at 14:11, Mike Mascari wrote:
...
> MONEY seems "odd" because it is interpreting its internal
> representation based upon locale and the locale is also determining
> its possible representation, so one database's MONEY isn't really
> the same type as another database's MONEY.
Tom Lane wrote:
> Philip Warner <[EMAIL PROTECTED]> writes:
> > So, if you do make the changes, will the schema definition be affected by
> > those changes, or do you expect the tablespace to be embedded in the CREATE
> > SCHEMA command?
>
> I thought the idea was for pg_dump to emit something l
Tom Lane wrote:
> Philip Warner <[EMAIL PROTECTED]> writes:
> > On the question of schemas, how would you expect:
> > SET magic_tablespace_variable = some_ts;
> > CREATE SCHEMA foo;
> > to behave? Would foo have a default tablespace of some_ts?
>
> Yeah, I would think so. I sur
On Mon, Aug 23, 2004 at 02:52:44PM +0200, Dennis Bjorklund wrote:
> On Mon, 23 Aug 2004, Karel Zak wrote:
>
> > I think it's pretty extendable solution in contrast to the current
> > hardcoded in/out datetypes functions.
>
> Who are we formatting for? If the client wants the data in a s
Philip Warner wrote:
> At 03:15 PM 23/08/2004, Tom Lane wrote:
>
> >I thought the idea was for pg_dump to emit something like
> >
> > SET magic_tablespace_variable = some_ts;
> > CREATE TABLE foo (columns...);
> >
> >rather than
> >
> > CREATE TABLE foo (columns...) TABLESP
Dennis Bjorklund wrote:
On Sun, 22 Aug 2004, Peter Eisentraut wrote:
To me, this seems completely wrong-headed. Data types should be defined
by what operations you can do on them, not by what output format they
have.
I totally agree, lets get rid of money all together.
If not, what makes money s
Hello,
Is there ANY chance to recover data from a database system that suffered disk
crash, and is not missing the data/global directory?
Version is 7.2.4. Database files seem to be intact as well as pg_clog and
pg_xlog directories.
Thanks in advance for any ideas.
Daniel
--
On Mon, 23 Aug 2004, Karel Zak wrote:
> I think it's pretty extendable solution in contrast to the current
> hardcoded in/out datetypes functions.
Who are we formatting for? If the client wants the data in a specific
format then they can do SELECT to_char(...), or do the formatting in t
On Sun, Aug 22, 2004 at 04:07:17PM -0400, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> We keep hoping someone will step up to the plate and rewrite it,
> >> instead. Per previous discussion, the type really ought to be a thin
> >> layer over "numeric", wit
Dear Drake,
Thanks for your response and suggestions on what i
should do to solve the above problem.
I have tried it and here are the results i had:
doing a cd /usr from the command line took me into
usr directory. However when i tried to do another
cd /local from the above resulting command
On Fri, Aug 20, 2004 at 11:44:28PM -0400, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Darcy Buskermolen wrote:
> >>> * remove to_char(interval) if we initdb or mention removal
> >>
> >> I vote just to mention it's removal at this time,
>
> > Agreed. Done.
>
> While I don't c
66 matches
Mail list logo
