Heikki Linnakangas wrote:
1. call pg_start_backup('foo')
2. tar/etc. the whole data directory, except for pg_xlog
3. tar pg_xlog
4. call pg_stop_backup()
If we just made sure that we don't delete or recycle any WAL files while
the backup is being taken, that would work, right?
When is the bac
Tom Lane wrote:
[EMAIL PROTECTED] (Peter Eisentraut) writes:
Implement a few changes to how shared libraries and dynamically loadable
modules are built.
Seems this patch has broken all the Windows buildfarm animals ... is
anybody on that?
Not all, only those that use the Makefil
On Mon, 7 Apr 2008 22:05:09 -0400 (EDT)
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > Better tools would be good, but unless someone commits to producing
> > a tool that will be ready by June but not by May, that's not a good
> > reason to slide either.
>
> Fine with me --- I just wanted to give T
[EMAIL PROTECTED] (Peter Eisentraut) writes:
> Implement a few changes to how shared libraries and dynamically loadable
> modules are built.
Seems this patch has broken all the Windows buildfarm animals ... is
anybody on that?
regards, tom lane
--
Sent via pgsql-hackers
Paul van den Bogaard <[EMAIL PROTECTED]> writes:
> just started with 8.4 devel. Still focussing on LWlocks. With the
> same load (#users & benchmarktool) I now see LockID 11
> (CLogControlLock) to be in the top waiting list.
> This one was never noticable in 8.3.
> Did anything change with r
Dimitri Fontaine <[EMAIL PROTECTED]> writes:
> And my main concern would still be left as-is, COPY wouldn't have any
> facility
> to cope with data representation not matching what datatype input functions
> want to read.
That's sufficiently covered by the proposal to allow a COPY FROM as a
tab
Gregory Stark <[EMAIL PROTECTED]> writes:
> Just throwing out a crazy idea. What if we had a commitfest as scheduled at
> the start of May but made it a Tom-free commitfest. Specifically to try to
> organize a larger work-force rather than to leave it all on Tom's shoulders.
> Not that your efforts
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Josh Berkus wrote:
> >> Maybe we should make the next commit-fest June 1 to give people some time
> >> off? And some time to improve the tools?
>
> > Agreed.
>
> I don't agree, not even a little bit. The reason this fest has been
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Josh Berkus wrote:
>> Maybe we should make the next commit-fest June 1 to give people some time
>> off? And some time to improve the tools?
> Agreed.
I don't agree, not even a little bit. The reason this fest has been so
long and painful is that the
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Josh Berkus wrote:
>> Maybe we should make the next commit-fest June 1 to give people some time
>> off? And some time to improve the tools?
>
> I would rather do the commit fests often, to keep the patch queue and the
> commit fests short.
Just
Tom Lane wrote:
Neil Conway <[EMAIL PROTECTED]> writes:
Applied to HEAD.
At this point it would probably be a good idea if a couple of buildfarm
machines were to start testing builds with --disable-integer-datetimes
... any volunteers out there?
I have changed the dash
FYI, we (Stefan and I) started a wiki page to organize this effort:
http://wiki.postgresql.org/wiki/Performances_QA_testing . Ideas and
participation are very welcome.
I also described the platform we have here and the usage of each
server:
http://wiki.postgresql.org/wiki/QA_Platform_hosted_at_Op
On Sun, Apr 06, 2008 at 11:29:50PM +0100, Gregory Stark wrote:
> I wonder if there's much of a use case for any statements aside from
> CREATE statements.
Yes. Some modules could have COPY or equivalent in them, as they
could easily contain data.
Cheers,
David.
--
David Fetter <[EMAIL PROTECTE
Chris Browne wrote:
[EMAIL PROTECTED] (Heikki Linnakangas) writes:
Josh Berkus wrote:
Maybe we should make the next commit-fest June 1 to give people some
time off? And some time to improve the tools?
I would rather do the commit fests often, to keep the patch queue and
the c
[EMAIL PROTECTED] (Heikki Linnakangas) writes:
> Josh Berkus wrote:
>> Maybe we should make the next commit-fest June 1 to give people some
>> time off? And some time to improve the tools?
>
> I would rather do the commit fests often, to keep the patch queue and
> the commit fests short.
But if i
Decibel! írta:
On Apr 3, 2008, at 12:52 AM, Zoltan Boszormenyi wrote:
Where is the info in the sequence to provide restarting with
the _original_ start value?
There isn't any. If you want the sequence to start at some magic
value, adjust the minimum value.
There's the START WITH option for
Le Monday 07 April 2008 21:04:26 Andrew Dunstan, vous avez écrit :
> Quite apart from any other reason why not, this would be a horrid hack
> and is just the sort of "feature" we rightly eschew, IMNSHO. COPY is
> designed as a bulk load/unload facility. It's fragile enough in that role.
And my mai
Heikki Linnakangas wrote:
> > However, it occurred to me that if someone turned on continuous arciving
> > during the file system snapshots, then you could use PITR to recover
> > from file system snapshots that were not simultaneous.
> >
> > Should this be documented?
>
> If you use continuous a
Decibel! wrote:
On Apr 3, 2008, at 4:51 PM, Andrew Dunstan wrote:
Several years ago Bruce and I discussed the then theoretical use of a
SELECT query as the source for COPY TO, and we agreed that the sane
analog would be to have an INSERT query as the target of COPY FROM.
This idea seems to
On Mon, Apr 7, 2008 at 2:58 PM, Heikki Linnakangas
<[EMAIL PROTECTED]> wrote:
> Incidentally, I looked at this stuff just a couple of days ago, and it
> occurred to me that we really should make it easier to take a hot backup
> with that mechanism. We shouldn't require setting up archive_command,
Bruce Momjian wrote:
Right now it isn't possible to use file system snapshots a reliable
backup if you are using multiple file systems for tablespaces because
most systems don't allow the simultaneous snapshoting of multiple file
system. Our documentation mentions this:
If your database
On Apr 3, 2008, at 9:35 AM, Tom Lane wrote:
"Dawid Kuroczko" <[EMAIL PROTECTED]> writes:
The idea of \G command is to perform the query, but with printing
query results using extended table output format.
Seems a bit useless --- if you prefer \x format, wouldn't you
prefer it
all the time?
Right now it isn't possible to use file system snapshots a reliable
backup if you are using multiple file systems for tablespaces because
most systems don't allow the simultaneous snapshoting of multiple file
system. Our documentation mentions this:
If your database is spread across multi
On Apr 3, 2008, at 4:51 PM, Andrew Dunstan wrote:
Several years ago Bruce and I discussed the then theoretical use of
a SELECT query as the source for COPY TO, and we agreed that the
sane analog would be to have an INSERT query as the target of COPY
FROM.
This idea seems to take that rathe
Josh Berkus wrote:
Maybe we should make the next commit-fest June 1 to give people some time
off? And some time to improve the tools?
I would rather do the commit fests often, to keep the patch queue and
the commit fests short.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprised
On Mon, 7 Apr 2008 14:31:51 -0400 (EDT)
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > Maybe we should make the next commit-fest June 1 to give people
> > some time off? And some time to improve the tools?
>
> Agreed.
>
+1
Joshua D. Drake
--
The PostgreSQL Company since 1997: http://www.comma
Josh Berkus wrote:
> Bruce,
>
> > We are down to 12 feature freeze items (240 emails):
> >
> > http://momjian.us/cgi-bin/pgpatches
> >
> > Most are not ready to apply but require feedback to the author.
>
> Yaaay!
>
> Maybe we should make the next commit-fest June 1 to give people some time
On Apr 3, 2008, at 12:52 AM, Zoltan Boszormenyi wrote:
Where is the info in the sequence to provide restarting with
the _original_ start value?
There isn't any. If you want the sequence to start at some magic
value, adjust the minimum value.
--
Decibel!, aka Jim C. Nasby, Database Architect
On Apr 1, 2008, at 7:20 PM, Stephen Frost wrote:
* Greg Smith ([EMAIL PROTECTED]) wrote:
=4 cores, >=8GB RAM, and >=8 disks with a usable write-caching
controller
in it.
hrmmm. So a DL385G2, dual-proc/dual-core with 16GB of ram and 8 SAS
disks with a Smart Array P800 w/ 512MB of write cache
On Apr 1, 2008, at 10:03 PM, Greg Smith wrote:
The idea we were bouncing around went a step past that and
considered this: if you have good statistics on a table, and you
have a sample set of queries you want to execute against it, how
would you use that information to plan what indexes sho
Bruce,
> We are down to 12 feature freeze items (240 emails):
>
> http://momjian.us/cgi-bin/pgpatches
>
> Most are not ready to apply but require feedback to the author.
Yaaay!
Maybe we should make the next commit-fest June 1 to give people some time
off? And some time to improve the too
On Mar 27, 2008, at 10:47 AM, Aidan Van Dyk wrote:
I was recently made aware of this:
http://repo.or.cz/w/PostgreSQL.git?
a=commit;h=69db64c737012a8d2d6fbcce3ace7136cb2bc85f
I started digging around to figure this out on Tuesday.
It appears as if the "rsync" mirror of CVS is not always "good
We are down to 12 feature freeze items (240 emails):
http://momjian.us/cgi-bin/pgpatches
Most are not ready to apply but require feedback to the author.
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB http://enterprisedb.com
On 07/04/2008, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Pavel Stehule escribió:
>
>
> > WARNING: problem in alloc set MessageContext: req size > alloc size
> > for chunk 0x8b6d1e0 in block 0x8b6bb50
> > WARNING: problem in alloc set MessageContext: req size > alloc size
> > for chunk 0x8b6
Pavel Stehule escribió:
> WARNING: problem in alloc set MessageContext: req size > alloc size
> for chunk 0x8b6d1e0 in block 0x8b6bb50
> WARNING: problem in alloc set MessageContext: req size > alloc size
> for chunk 0x8b6d1e0 in block 0x8b6bb50
I suggest you make distclean and rebuild the whol
On 07/04/2008, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> Pavel Stehule wrote:
>
> > when I tested ptop, I found some problems
> >
>
> Which version are you running?
I am sorry, HEAD 8.4 today actualized
Pavel
>
> --
> Heikki Linnakangas
> EnterpriseDB http://www.enterprisedb.com
>
Pavel Stehule wrote:
when I tested ptop, I found some problems
Which version are you running?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.
On Mon, Apr 7, 2008 at 7:55 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Tom Dunstan" <[EMAIL PROTECTED]> writes:
> > OK, I found an example that does NOT fit the "just drop all
> > dependencies" scenario, but that I would still like to support. I just
> > had a look at the postgis pl/java support
Hello
when I tested ptop, I found some problems
this pgbench is very slow and when after getting table of locks from
ptop I got backend crash.
[EMAIL PROTECTED] ~]$ /usr/local/pgsql/bin/pgbench -c80 -t1000 postgres
starting vacuum...end.
WARNING: you don't own a lock of type ShareLock
WARNING:
"Tom Dunstan" <[EMAIL PROTECTED]> writes:
> OK, I found an example that does NOT fit the "just drop all
> dependencies" scenario, but that I would still like to support. I just
> had a look at the postgis pl/java support, and its install does stuff
> like "SELECT sqlj.install_jar('file://${PWD}/pos
just started with 8.4 devel. Still focussing on LWlocks. With the
same load (#users & benchmarktool) I now see LockID 11
(CLogControlLock) to be in the top waiting list.
This one was never noticable in 8.3.
Did anything change with respect to this?
Thanks
Paul
---
Sorry to keep replying to myself, but part of the point of doing a
patch was to force myself (and whoever else is interested to examine
stuff that comes up...
On Mon, Apr 7, 2008 at 11:46 AM, Tom Dunstan <[EMAIL PROTECTED]> wrote:
> None of that suggests that an uninstaller script would be needed
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> If the scanning of the inner side is a performance problem, why would we
> be choosing a nested loop in the first place, vs. another type of join?
I clearly haven't done a good job explaining this as nobody seems to getting
what I'm describing. I thin
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> I've been hacking on the idea of an Append node which maintains the ordering
>> of its subtables merging their records in order.
>
> I finally got round to looking at this ...
A lot of things to chew on. Thanks
Pavan Deolasee wrote:
On Fri, Apr 4, 2008 at 11:10 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
The
policy of this project is that we only put nontrivial bug fixes into
back branches, and I don't think this item qualifies ...
Got it. I will submit a patch for HEAD.
Thanks,
As I mentio
On Mon, Apr 7, 2008 at 11:46 AM, Tom Dunstan <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 7, 2008 at 3:59 AM, Gregory Stark <[EMAIL PROTECTED]> wrote:
> > I wonder if there's much of a use case for any statements aside from
> CREATE
> > statements. If we restrict it to CREATE statements we could h
46 matches
Mail list logo
