Jeremy Drake <[EMAIL PROTECTED]> writes:
> On several occasions I have wanted to input integers in hexadecimal rather
> than in decimal in PostgreSQL. I notice that there is a to_hex function,
> but there is not (AFAIK) a way to provide an integer in hexadecimal.
regression=# select x'abcd'::int;
On several occasions I have wanted to input integers in hexadecimal rather
than in decimal in PostgreSQL. I notice that there is a to_hex function,
but there is not (AFAIK) a way to provide an integer in hexadecimal.
I have written a pure-sql implementation of some functions to input
integers in
Just for curiosity, I would like to ask you why you need to modify
pgbench. pgbench can accept custom SQL scripts...
P.S. HOT seems to be one of the greatest enhancements since PostgreSQL
was born!
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> Hi All,
>
> Here are some preliminary numbers with the HOT 4
"Postgres User" <[EMAIL PROTECTED]> writes:
> On 3/1/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> "Postgres User" <[EMAIL PROTECTED]> writes:
>>> ref_entry = 'c_entry';
>>> MOVE Backward All In c_entry;
>>
>> You have to use EXECUTE for the latter.
> I had tried several variations of MOVE Ba
Zeugswetter Andreas ADI SD wrote:
accounts 157895 (initial size) 49284 (increase)
accounts_pkey 19709 (initial size) 19705 (increase)
Just to clarify, the relation size and increase is in number
of blocks.
The numbers are quite impressive :-) Have you removed the select
Hi Gavin,
Thanks for your comments.
I shall set up the ctids list to be stored in memory initially and dump to a
temp file if needed.
Regards,
John Bartlett
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gavin Sherry
Sent: Wednesday, 28 February 2007
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > CVS HEAD doc won't compile due to broken mark up. Please someone
> > commit following patches if they are appropreate.
>
> Done.
Thanks.
> > Also please do not commit broken sgml files without trying to compile
> > them.
>
> Some committers are us
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> CVS HEAD doc won't compile due to broken mark up. Please someone
> commit following patches if they are appropreate.
Done.
> Also please do not commit broken sgml files without trying to compile
> them.
Some committers are using DocBook installations t
CVS HEAD doc won't compile due to broken mark up. Please someone
commit following patches if they are appropreate.
Also please do not commit broken sgml files without trying to compile
them.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Index: array.sgml
===
CVS HEAD doc won't compile due to broken mark up. Please someone
commit following patches if they are appropreate.
Also please do not commit broken sgml files without trying to compile
them.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Index: array.sgml
===
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> However, I'm not sure whether 2.5.4 will choke on unrecognized %option
>> commands --- if it has to be conditional on version it'll be a PITA.
> %option noyyget_in
> causes flex 2.5.4a to barf:
On closer investigation, flex does cont
On Thu, Mar 01, 2007 at 01:05:28PM +, Simon Riggs wrote:
> ISTM a radical approach is needed, so I'm very open to discussion about
> this and how we cope.
>
> If we break down the main thoughts into a few parts:
>
> 1. would like a way to CLUSTER/VACUUM FULL where we don't have to move
> all
On Thu, Mar 01, 2007 at 04:54:44PM +0200, Hannu Krosing wrote:
> > > I was not suggesting that we remove visible rows through truncation.
> >
> > Sure, unless you suggest to not truncate during this vacuum run ?
> > But we are talking about vacuum full, so truncation is essential.
> >
> > It was
On Fri, 2007-03-02 at 03:31 +0300, Sergey E. Koposov wrote:
> > So it seems like we already have a solution to quotas at the database
> > level.
>
> I still don't understand how FS quotas can help with DB quotas. ..
> All the FS quotas are setup for limiting the space for specific user and
> sp
On Thu, 1 Mar 2007, Tom Lane wrote:
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
I still don't understand how FS quotas can help with DB quotas. ..
All the FS quotas are setup for limiting the space for specific user and
specific mount point. AFAIK They do not allow to limit the space in o
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> I still don't understand how FS quotas can help with DB quotas. ..
> All the FS quotas are setup for limiting the space for specific user and
> specific mount point. AFAIK They do not allow to limit the space in one
> directory. And since all th
So it seems like we already have a solution to quotas at the database
level.
I still don't understand how FS quotas can help with DB quotas. ..
All the FS quotas are setup for limiting the space for specific user and
specific mount point. AFAIK They do not allow to limit the space in one
dir
On Thu, 2007-03-01 at 17:53 -0500, Tom Lane wrote:
> The real problem though is whether you can get anything much done if up
> against a hard limit; especially if that limit also affects the system
> catalogs. Remember that UPDATE requires the ability to insert new tuple
> versions, so there are a
Hi.
Yeah, as for me, it is already mutual agreement.:-)
Everyone will be able to use it easily. It is important in the meaning that avoids
useless confusion. Moreover, the DEBUG function of VS2005 is very excellent.
I think great evolution of it. Thanks!!
Regards,
Hiroshi Saito
I would like
On Fri, 2 Mar 2007 01:20, Simon Riggs wrote:
> On Thu, 2007-03-01 at 15:17 +1100, FAST PostgreSQL wrote:
Hi Simon,
> > We are happy to provide that. If and when it comes to the final patch
> > being accepted, we can send a copyright waiver mail which will put our
> > source code contribution unde
Jeff Davis <[EMAIL PROTECTED]> writes:
> Is it possible to make the database safe in this case? I can see why it
> would be difficult to handle pg_xlog filling up (or for that matter
> pg_log), but couldn't any other area be turned into just a simple ERROR?
It is --- Josh is mistaken about the sev
On Thu, 2007-03-01 at 14:13 -0800, Joshua D. Drake wrote:
> Andrew Dunstan wrote:
> > Jeff Davis wrote:
> >>
> >> If we allowed an admin to revoke CREATE from the pg_default tablespace,
> >> then anyone who needed that feature could limit people to their own
> >> tablespace (at which point it's the
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
Andrew Dunstan wrote:
Hitting a file system quota limit is likely to bring you down pretty
hard, isn't it?
Yes, and likely corrupt the database.
As long as you don't keep WAL on the restricted filesystem,
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
>> Hitting a file system quota limit is likely to bring you down pretty
>> hard, isn't it?
> Yes, and likely corrupt the database.
As long as you don't keep WAL on the restricted filesystem, it won't
stop or corrupt your databa
Andrew Dunstan wrote:
> Jeff Davis wrote:
>>
>> If we allowed an admin to revoke CREATE from the pg_default tablespace,
>> then anyone who needed that feature could limit people to their own
>> tablespace (at which point it's the filesystem's job to limit their
>> usage). Is there some reason that
Jeff Davis wrote:
If we allowed an admin to revoke CREATE from the pg_default tablespace,
then anyone who needed that feature could limit people to their own
tablespace (at which point it's the filesystem's job to limit their
usage). Is there some reason that we can't do this now?
Hitting
Jeff Davis <[EMAIL PROTECTED]> writes:
> If we allowed an admin to revoke CREATE from the pg_default tablespace,
> then anyone who needed that feature could limit people to their own
> tablespace (at which point it's the filesystem's job to limit their
> usage). Is there some reason that we can't d
On Wed, 2007-02-28 at 12:56 -0500, Tom Lane wrote:
> "Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> > Per user AND per database (as Tom noted). But I dont see what's odd in
> > it... It exists in Oracle, and I need quotas in the project on which I'm
> > working. And I remember user requests f
Hi!
I would like to suggest that we retire some of the old Visual C++ build
infrastructure. Specifically, all the makefiles for VC++ 6.0 *except* libpq.
There is a point for keeping libpq - if you want to build a static
version, it's easier if you can use the same version. And it's also
required
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> This might all be OK - I just noticed it as I was looking at the
> problem, so I though I'd mention it.
I'm inclined to leave that code alone unless someone can point to a
platform where setting POLLERR in events actually causes a problem.
The pgstat c
On Wed, Feb 28, 2007 at 02:29:52PM -0800, Joshua D. Drake wrote:
>
> > I don't know, but in my opinion, I don't see anything bad in requiring
> > dropping the data if the quota is full. That's what usually occurs in
> > the case of normal filesystem quota... If you don't have a space there,
> > yo
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Good catch. I am also a bit dubious about this code:
input_fd.fd = pgStatSock;
input_fd.events = POLLIN | POLLERR;
input_fd.revents = 0;
Hm. The Single Unix Spec saith that POLLERR is ignored
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Good catch. I am also a bit dubious about this code:
> input_fd.fd = pgStatSock;
> input_fd.events = POLLIN | POLLERR;
> input_fd.revents = 0;
Hm. The Single Unix Spec saith that POLLERR is ignored in the events
field, but it i
Tom Lane wrote:
Darcy Buskermolen <[EMAIL PROTECTED]> writes:
I'm observing high CPU usage (95%) of a 2.6GHz opteron by the stats
collector on an 8.2.3 box investigation has lead me to belive that the
stats file is written a lot more often that once every 500ms the
following shows this beha
Andrew,
> I told you I would and offered some suggestions ... last time I looked I
> still had commit privs ...
Sorry, I must have missed that. On IRC?
Anyway, thank you and looking forward to it!
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of broadc
Josh Berkus wrote:
All,
Well, there were 30+ posts on the Google SoC thread. However, at the end
of it only Robert Treat, Dave Page, Mark Wong, and Josh Drake volunteered
to be mentors. Note that there's not *one* core-backend-code-committer in
that list.
We really, really, really need a
Darcy Buskermolen <[EMAIL PROTECTED]> writes:
> I'm observing high CPU usage (95%) of a 2.6GHz opteron by the stats
> collector on an 8.2.3 box investigation has lead me to belive that the
> stats file is written a lot more often that once every 500ms the
> following shows this behavior.
Looks l
On Thu, 2007-03-01 at 22:35 +0530, Pavan Deolasee wrote:
> Merlin Moncure wrote:
> > On 3/1/07, Pavan Deolasee <[EMAIL PROTECTED]> wrote:
> >>
> > seems pretty solid except for one possible problem...at one point when
> > I dropped then later added the index on 'abalance', I got spammed
> > 'W
All,
Well, there were 30+ posts on the Google SoC thread. However, at the end
of it only Robert Treat, Dave Page, Mark Wong, and Josh Drake volunteered
to be mentors. Note that there's not *one* core-backend-code-committer in
that list.
We really, really, really need a couple of core-code co
On Wednesday 28 February 2007 14:31, Joshua D. Drake wrote:
> Joshua D. Drake wrote:
> > Darcy Buskermolen wrote:
> >> I'm observing high CPU usage (95%) of a 2.6GHz opteron by the stats
> >> collector on an 8.2.3 box investigation has lead me to belive that the
> >> stats file is written a lot mo
On Thu, Mar 01, 2007 at 06:23:37PM +0100, Jonathan Scher wrote:
> >Because when it drops the old copy of the table there had better not be
> >any concurrent readers.
> Then, is it possible to take a share update exclusive lock until the new
> table is ready, then an access exclusive one only in o
Florian G. Pflug wrote:
> Alvaro Herrera wrote:
>> Florian G. Pflug wrote:
>>
>>> However, I just realized that doing this is much harder than I initially
>>> thought, because catalog access always happens with SnapshotNow, and
>>> e.g. "drop table" deletes datafiles at commit time, and not during
Tom Lane a écrit :
Jonathan Scher <[EMAIL PROTECTED]> writes:
CLUSTER uses an ACCESS EXCLUSIVE lock. Why does it forbid concurrent reads?
Because when it drops the old copy of the table there had better not be
any concurrent readers.
regards, tom lane
Then
Merlin Moncure wrote:
> On 3/1/07, Pavan Deolasee <[EMAIL PROTECTED]> wrote:
>>
> seems pretty solid except for one possible problem...at one point when
> I dropped then later added the index on 'abalance', I got spammed
> 'WARNING: found a HOT-updated tuple' from psql prompt.
Thats intentional.
Tom Lane írta:
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
However, I get warning messages like:
WARNING: detected write past chunk end in ExecutorState 0xaaff68
How can I prevent them?
Find the memory-clobbering bug in your patch.
regards, tom lane
Th
On 3/1/07, Pavan Deolasee <[EMAIL PROTECTED]> wrote:
Hi All,
Here are some preliminary numbers with the HOT 4.0 patch that I sent
out earlier today. These are only indicative results and should not be
used to judge the performance of HOT in general. I have intentionally
used the setup favorabl
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
> However, I get warning messages like:
> WARNING: detected write past chunk end in ExecutorState 0xaaff68
> How can I prevent them?
Find the memory-clobbering bug in your patch.
regards, tom lane
---
Hello,
I have a single Athlon 2.3MHz. Then I bought a Netfinity 7600 with quad
Xeon 700MHz (for EUR 151 on Ebay, 2gb RAM included). I worked over my
application to run queries in parallel. I got a speedup from 13:37 min
(on the AMD) to 4:01 min (on the IBM). With this email I am suggesting
the
> This means that
>
> VACUUM FULL mytable;
>
> would translate to:
>
> VACUUM mytable; -- make free space
> COMPACT mytable; -- move tuples in a bunch of small transactions
> -- might have a GUC for max trx length
> VACUUM mytable; -- free the tuples at the end and give spac
On Wed, Feb 28, 2007 at 04:10:09PM +0900, ITAGAKI Takahiro wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
>
> > At some point it might make sense to convert the FSM into a bitmap; that
> > way everything just scales with database size.
>
> > In the meantime, I'm not sure if it makes sense to
> > accounts 157895 (initial size) 49284 (increase)
> > accounts_pkey 19709 (initial size) 19705 (increase)
> >
> >
> Just to clarify, the relation size and increase is in number
> of blocks.
The numbers are quite impressive :-) Have you removed the selects on
accounts too
Jonathan Scher <[EMAIL PROTECTED]> writes:
> CLUSTER uses an ACCESS EXCLUSIVE lock. Why does it forbid concurrent reads?
Because when it drops the old copy of the table there had better not be
any concurrent readers.
regards, tom lane
---(end of br
On Wed, Feb 28, 2007 at 12:16:10PM -0500, Bruce Momjian wrote:
> background writer, and I think after a server crash, all pages would
> have to be read and checked. The good news is that both of these are
Would they? If you're doing recovery you'd have to read all pages
dirtied since the last che
On 3/1/07, Pavan Deolasee <[EMAIL PROTECTED]> wrote:
accounts 157895 (initial size) 49284 (increase)
accounts_pkey 19709 (initial size) 19705 (increase)
Just to clarify, the relation size and increase is in number of blocks.
Thanks,
Pavan
--
EnterpriseDB http://w
Jim C. Nasby wrote:
On Wed, Feb 28, 2007 at 10:14:24PM +, Heikki Linnakangas wrote:
cache instead. In the index scan phase, it's randomly accessed, but if
the table is clustered, it's in fact not completely random access. In
the 2nd vacuum pass, the array is scanned sequentially again. I'm
On Wed, Feb 28, 2007 at 10:14:24PM +, Heikki Linnakangas wrote:
> cache instead. In the index scan phase, it's randomly accessed, but if
> the table is clustered, it's in fact not completely random access. In
> the 2nd vacuum pass, the array is scanned sequentially again. I'm not
Only if th
Ühel kenal päeval, N, 2007-03-01 kell 15:03, kirjutas Zeugswetter
Andreas ADI SD:
> > > > -- start the VACUUM from the first non-filled block
> > > >
> > > > So if we do this, we wouldn't need to worry about HOT tuples at
> all,
> > > > nor would we need to wait until all transact
Hi
I've updated (or rather rewritten) my proposal for implementing
read-onyl queries on PITR slaves as a "Summer of Code 2007" project.
I've added are more details description of how I plan implement
a read-only mode suitable for PITR slaves, and put in a few
possible enhancements to the "Big, G
Hello,
CLUSTER uses an ACCESS EXCLUSIVE lock. Why does it forbid concurrent reads?
Florian G. Pflug, on a post (
http://archives.postgresql.org/pgsql-hackers/2007-02/msg00081.php )
suggested that there were no way to let the old entry until the command
commit.
I would like Cluster to create a
On Thu, 2007-03-01 at 15:17 +1100, FAST PostgreSQL wrote:
> We are happy to provide that. If and when it comes to the final patch being
> accepted, we can send a copyright waiver mail which will put our source code
> contribution under the BSD license.
This approach is not practically workable
> > > -- start the VACUUM from the first non-filled block
> > >
> > > So if we do this, we wouldn't need to worry about HOT tuples at
all,
> > > nor would we need to wait until all transactions are gone.
> >
> > You need to wait until you are allowed to truncate if you want
> > concu
Hi All,
Please see the version 4.0 of HOT WIP patch posted on pgsql-patches.
I am having some trouble since afternoon posting the patch, tried
multiple times. So not sure if has made to -patches yet. If doesn't get
through on -patches this time also I would retry after few hours again.
Please
Zeugswetter Andreas ADI SD wrote:
Maybe a suitable replacement for full-page would be to sync the
first
WAL record for a page change before writing the buffer
We *always* sync WAL records for page changes before writing
the buffer for the page.
Um, is that so ? And how is that done ? (e.g. b
> One imho important (not necessarily mandatory) aspect of HOT
> is, that it does parts of what vacuum would usually do.
>
> Thus:
> 1. resume, load ctid list
> 2. continue filling ctid list
> 3. remove index tuples for these ctids (* problem *)
>
> You have just removed index
Zoltan Boszormenyi írta:
The cost I am thinking now is an extra heap_update()
after heap_insert() without generating the identity value
and inserting index tuples to indexes that doesn't
contain the identity column.
And as far as I tested the current state, there is no cost
if you don't use GEN
Hi All,
Here are some preliminary numbers with the HOT 4.0 patch that I sent
out earlier today. These are only indicative results and should not be
used to judge the performance of HOT in general. I have intentionally
used the setup favorable to HOT. The goal here is to point out the best
usage
On Thu, Mar 01, 2007 at 08:32:57AM -0500, Merlin Moncure wrote:
>
> Following an emergency downgrade back to 8.1, the kernel panics went
> away. Note that I don't believe for a second that the database was
> the root cause here...research suggest that the problem is due to some
> type of bug in t
On Thu, 2007-03-01 at 14:35 +0100, Zeugswetter Andreas ADI SD wrote:
> > -- start the VACUUM from the first non-filled block
> >
> > So if we do this, we wouldn't need to worry about HOT tuples
> > at all, nor would we need to wait until all transactions are gone.
>
> You need to wai
Ühel kenal päeval, N, 2007-03-01 kell 13:14, kirjutas Simon Riggs:
> On Thu, 2007-03-01 at 14:42 +0200, Hannu Krosing wrote:
> > Ühel kenal päeval, N, 2007-03-01 kell 14:32, kirjutas Hannu Krosing:
> >
> > > If we can trust FSM, the whole process just becomes the backward scan
> > > and null updat
> -- start the VACUUM from the first non-filled block
>
> So if we do this, we wouldn't need to worry about HOT tuples
> at all, nor would we need to wait until all transactions are gone.
You need to wait until you are allowed to truncate if you want
concurrency.
Or a concurrent s
Andrew Dunstan wrote:
> Mageshwaran wrote:
>> Hi,
>>
>> Some body help me regarding postgres replication, Give me some ideas .
>>
>> Thanks in advance
>>
>>
>
> Here are some ideas:
Tsk, Andrew.
Replication in PostgreSQL is usually served via Point in Time recovery,
Slony (http://www.slony.info)
On 2/26/07, Merlin Moncure <[EMAIL PROTECTED]> wrote:
On 2/23/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
> > On friday we upgraded a critical backend server to postgresql 8.2
> > running on fedora core 4.
>
> Umm ... why that particular choice of OS? R
> I admit that the implementation is much complex, but I can
> not see any big problems to save the dead tuples out and read
> it in again(like two phase commit does). Why do we need to
> hold the lock and transaction? We can open the lock and
> abandon the transaction ID, vacuum can take the
> > Maybe a suitable replacement for full-page would be to sync the
first
> > WAL record for a page change before writing the buffer
>
> We *always* sync WAL records for page changes before writing
> the buffer for the page.
Um, is that so ? And how is that done ? (e.g. bgwriter would need to
On Thu, 2007-03-01 at 14:42 +0200, Hannu Krosing wrote:
> Ühel kenal päeval, N, 2007-03-01 kell 14:32, kirjutas Hannu Krosing:
>
> > If we can trust FSM, the whole process just becomes the backward scan
> > and null updates until the null update does not move tuple to a lower
> > page. Also, for t
On Thu, 2007-03-01 at 14:32 +0200, Hannu Krosing wrote:
> Ühel kenal päeval, N, 2007-03-01 kell 12:02, kirjutas Simon Riggs:
> > Use case for VACUUM FULL is very low these days. VACUUM does the most
> > important part of what VACUUM FULL offers, yet does it concurrently
> > rather than with a full
On Thu, 2007-03-01 at 13:56, Simon Riggs wrote:
> > Wouldn't this be deadlock prone ? What if a non-utility transaction
> > (which could even be started before the vacuum full) blocks on the table
> > being vacuumed, then if the vacuum wants to wait until all non-utility
> > transactions finish wil
On Thu, 2007-03-01 at 13:21 +0100, Csaba Nagy wrote:
> On Thu, 2007-03-01 at 13:02, Simon Riggs wrote:
> > I would like to introduce the concept of utility transactions. This is
> > any transaction that touches only one table in a transaction and is not
> > returning or modifying data. All utility
Ühel kenal päeval, N, 2007-03-01 kell 14:32, kirjutas Hannu Krosing:
> If we can trust FSM, the whole process just becomes the backward scan
> and null updates until the null update does not move tuple to a lower
> page. Also, for the duration of COMPACT TABLE the updated tuple should
> always be
Ühel kenal päeval, N, 2007-03-01 kell 12:02, kirjutas Simon Riggs:
> Use case for VACUUM FULL is very low these days. VACUUM does the most
> important part of what VACUUM FULL offers, yet does it concurrently
> rather than with a full table lock. VACUUM FULL also
> - has very long execution time
>
On Thu, 2007-03-01 at 13:02, Simon Riggs wrote:
> I would like to introduce the concept of utility transactions. This is
> any transaction that touches only one table in a transaction and is not
> returning or modifying data. All utility transactions wait until they
> are older than all non-utility
Hi
Just to add an question to it.. do we have a felixbitily to run this
xlogdump or xlogviewer on windows installation of Postgres. Also how do we
run these utilities with the existing postgres server running on linux box.
thanks
Vishal
From: "Jonah H. Harris" <[EMAIL PROTECTED]>
To: Mage
Florian G. Pflug írta:
Yes, of course you can prevent gaps by just filling them
with garbage/invalid records of whatever. But I don't see
why this is usefull - either you want, say, your invoice
number to be continuous because it's required by law - or
you don't. But if the law required your invo
Use case for VACUUM FULL is very low these days. VACUUM does the most
important part of what VACUUM FULL offers, yet does it concurrently
rather than with a full table lock. VACUUM FULL also
- has very long execution time
- generates lots of WAL traffic
- uses lots of memory while it runs
- isn't a
Zoltan Boszormenyi wrote:
Florian G. Pflug írta:
Zoltan Boszormenyi wrote:
The GENERATED column is an easy of use feature
with possibly having less work, whereas the IDENTITY
column is mandatory for some applications (e.g. accounting
and billing is stricter in some countries) where you simply
c
BenchmarkSQL is open source, but, I don't think anyone has published version
5.2 yet on pgFoundry. Amongst other goodies, version 5.2 allows for the
running of Java based tpcC and/or tpcB like benchmarks from the command line
or the cutsie gui. We've also added consistency checks to the end of
Zoltan Boszormenyi írta:
Florian G. Pflug írta:
Zoltan Boszormenyi wrote:
The GENERATED column is an easy of use feature
with possibly having less work, whereas the IDENTITY
column is mandatory for some applications (e.g. accounting
and billing is stricter in some countries) where you simply
ca
Florian G. Pflug írta:
Zoltan Boszormenyi wrote:
The GENERATED column is an easy of use feature
with possibly having less work, whereas the IDENTITY
column is mandatory for some applications (e.g. accounting
and billing is stricter in some countries) where you simply
cannot skip a value in the s
Zoltan Boszormenyi wrote:
The GENERATED column is an easy of use feature
with possibly having less work, whereas the IDENTITY
column is mandatory for some applications (e.g. accounting
and billing is stricter in some countries) where you simply
cannot skip a value in the sequence, the strict mono
"Zeugswetter Andreas ADI SD" <[EMAIL PROTECTED]> writes:
> Maybe a suitable replacement for full-page would be to sync the first WAL
> record for a page change before writing the buffer
We *always* sync WAL records for page changes before writing the buffer for
the page.
--
Gregory Stark
En
> Under normal operations, shutting down the database does a
> checkpoint, right? So unless you're in recovery mode, there's
> no additional cost.
> And I can't think of any reason you'd need to see any pages
> before the last checkpoint (unless you don't trust your disk
> and just want to che
Mageshwaran wrote:
Hi,
Some body help me regarding postgres replication, Give me some ideas .
Thanks in advance
Here are some ideas:
lose the idiotic, pointless and inaccurate email addendum, especially
the ads for bollywood etc.
do some research yourself, especially by reading the Post
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> I've disabled packed varlenas for user-defined data types and find tsearch2
>> and _int still fail. tsearch2 requires the small patch attached. _int seems
>> to
>> be unrelated.
>
> As of when? I committed fixe
On Thu, 2007-03-01 at 11:00 +0900, ITAGAKI Takahiro wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> wrote:
>
> > > > VACUUM's current behaviour is to take blocks it has touched and place
> > > > them on the head of the freelist, allowing them to be reused.
> > >
> > > No, it puts them at the tail of t
> > Then you cannot run any queries that extend the size of
> your relations
> > (for example INSERT, UPDATE etc.). Unless you drop your tables or
> > DELETE something
>
> Interesting. Well my two cents is don't go any deeper than database.
> I.e; don't try and track to the individual relation
Hi,
Some body help me regarding postgres replication, Give me some ideas .
Thanks in advance
Regards
J Mageshwaran
** DISCLAIMER **
Information contained and transmitted by this E-MAIL is proprietary to
Sify Limited and is intended for use only by the individual or entity to
96 matches
Mail list logo
