On Tue, Nov 16, 2010 at 3:07 AM, Robert Haas robertmh...@gmail.com wrote:
The loop that begins here:
for (i = 0; i maxoff; i++)
{
/* First half of segs goes to the left datum. */
if (i seed_2)
...looks like it should perhaps be broken into two separate loops.
That
Thanks for the information about Informix VTI. Because I'm not
familiar to Informix, I might have missed your point. Would you mind
telling me more about Informix VTI?
On Mon, 15 Nov 2010 08:45:14 -0800
Eric Davies e...@barrodale.com wrote:
With Informix VTI, indexing is the same for native
On Tue, Nov 16, 2010 at 01:35, Tom Lane t...@sss.pgh.pa.us wrote:
... and if so, isn't postmaster.c's code to transfer a HANDLE value to a
child process all wet?
It is definitely 64-bit. sizeof(HANDLE)==8.
So yes, it looks completely broken. I guess Windows doesn't actually
*assign* you a
On Tue, Nov 16, 2010 at 10:01 AM, Magnus Hagander mag...@hagander.net wrote:
On Tue, Nov 16, 2010 at 01:35, Tom Lane t...@sss.pgh.pa.us wrote:
... and if so, isn't postmaster.c's code to transfer a HANDLE value to a
child process all wet?
It is definitely 64-bit. sizeof(HANDLE)==8.
So yes,
On Tue, Nov 16, 2010 at 3:07 AM, Robert Haas robertmh...@gmail.com wrote:
But on a broader note, I'm not very certain the sorting algorithm is
sensible. For example, suppose you have 10 segments that are exactly
'0' and 20 segments that are exactly '1'. Maybe I'm misunderstanding,
but it
On Fri, Nov 12, 2010 at 17:47, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Uh, I still cannot reproduce the failure:
I would imagine you need -w option on the start. The whole issue
here is whether start's wait-for-server-start code works.
On Tue, Nov 16, 2010 at 11:01, Magnus Hagander mag...@hagander.net wrote:
On Tue, Nov 16, 2010 at 01:35, Tom Lane t...@sss.pgh.pa.us wrote:
... and if so, isn't postmaster.c's code to transfer a HANDLE value to a
child process all wet?
It is definitely 64-bit. sizeof(HANDLE)==8.
So yes, it
Is there a particular reason why track_functions is disabled by default?
Does having it at 'pl' by default create a noticable overhead for
people who aren't using pl functions? Or for that matter, even a
noticable overhead for those that *are*?
--
Magnus Hagander
Me: http://www.hagander.net/
Magnus Hagander mag...@hagander.net writes:
Is there a particular reason why track_functions is disabled by default?
Performance worries, plus the thought that not everyone cares to
have these stats.
Does having it at 'pl' by default create a noticable overhead for
people who aren't using pl
I've been trying to get clang working enough that I can at
least get HEAD going for a build farm client, and the attached
patch is the bare minimum to get it working. There may be a
better way to do this, but as indicated in a past thread, the
GNU_SOURCE variable does not play nicely with
On Tue, Nov 16, 2010 at 15:42, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Tue, Nov 16, 2010 at 11:01, Magnus Hagander mag...@hagander.net wrote:
So yes, it looks completely broken. I guess Windows doesn't actually
*assign* you a handle larger than 2^32
Greg Sabino Mullane g...@turnstep.com writes:
I've been trying to get clang working enough that I can at
least get HEAD going for a build farm client, and the attached
patch is the bare minimum to get it working. There may be a
better way to do this, but as indicated in a past thread, the
On Tue, Nov 16, 2010 at 16:09, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
Is there a particular reason why track_functions is disabled by default?
Performance worries, plus the thought that not everyone cares to
have these stats.
Most people who are
On Tue, Nov 16, 2010 at 16:23, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
Do you still have a reference to the page that said they will never be
assigned that high?
http://msdn.microsoft.com/en-us/library/ms810720.aspx
which says
USER and GDI handles
On Tue, Nov 16, 2010 at 16:35, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Tue, Nov 16, 2010 at 16:23, Tom Lane t...@sss.pgh.pa.us wrote:
What's not clear to me is whether the section title means that only
certain handles have this guarantee, and if so
On 13.11.2010 00:34, Greg Stark wrote:
On Fri, Nov 12, 2010 at 7:20 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I think we can work around that with a small modification to the page split
algorithm. In a nutshell, when the child page is split, put a flag on the
left half
Magnus was just talking to me about having a better way of controlling
memory usage on autovacuum. Instead of each worker using up to
maintenance_work_mem, which ends up as a disaster when DBA A sets to a
large value and DBA B raises autovacuum_max_workers, we could simply
have an
On tis, 2010-11-16 at 09:41 -0500, Greg Sabino Mullane wrote:
I've been trying to get clang working enough that I can at
least get HEAD going for a build farm client, and the attached
patch is the bare minimum to get it working. There may be a
better way to do this, but as indicated in a
On Wed, Nov 17, 2010 at 01:12, Alvaro Herrera alvhe...@alvh.no-ip.org wrote:
So for the initial implementation, we could just have each worker set
its local maintenance_work_mem to autovacuum_maintenance_memory / max_workers.
That way there's never excessive memory usage.
It sounds reasonable,
On mån, 2010-11-15 at 23:13 +0100, Pavel Stehule wrote:
a) default encoding for collate isn't same as default encoding of database
it's minimally not friendly - mostly used encoding is UTF8, but in
most cases users should to write locale.utf8.
I don't understand what you are trying to say.
Itagaki Takahiro itagaki.takah...@gmail.com writes:
On Wed, Nov 17, 2010 at 01:12, Alvaro Herrera alvhe...@alvh.no-ip.org wrote:
So for the initial implementation, we could just have each worker set
its local maintenance_work_mem to autovacuum_maintenance_memory /
max_workers.
That way
On Tue, Nov 16, 2010 at 2:43 AM, Robert Haas robertmh...@gmail.com wrote:
I don't really think these changes to the INSTR macros make much
sense. The macros don't really add much notational convenience;
they're mostly wrappers to make the WIN32 and non-WIN32 cases work
similarly for the
On 16.11.2010 18:12, Alvaro Herrera wrote:
Thoughts?
Sounds reasonable, but you know what would be even better? Use less
memory in vacuum, so that it doesn't become an issue to begin with.
There was some discussion on that back in 2007
On Tue, Nov 16, 2010 at 11:12 AM, Alvaro Herrera
alvhe...@alvh.no-ip.org wrote:
Magnus was just talking to me about having a better way of controlling
memory usage on autovacuum. Instead of each worker using up to
maintenance_work_mem, which ends up as a disaster when DBA A sets to a
large
At 01:36 AM 11/16/2010, Shigeru HANADA wrote:
Thanks for the information about Informix VTI. Because I'm not
familiar to Informix, I might have missed your point. Would you mind
telling me more about Informix VTI?
On Mon, 15 Nov 2010 08:45:14 -0800
Eric Davies e...@barrodale.com wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
There are two key changes to the insert algorithm:
1. When we walk down the tree searching for a suitable leaf page to
insert the new tuple to, we update the nodes on the way down so that
they are consistent with the new key
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Tom asked:
What happens to plperl?
It still doesn't work. I was going to leave it out via --without-perl,
and save fixing that for another day. There's a handful of other
warnings when making, but --with-perl is the only showstopper
(once
I was able to apply and compile and run ok, creating unlogged tables
seems to work as well.
I patched up pgbench to optionally create unlogged tables, and ran it
both ways. I get ~80tps normally, and ~1,500tps with unlogged. (Thats
from memory, was playing with it last night at home)
I
Greg Sabino Mullane g...@turnstep.com writes:
Tom asked:
What happens to plperl?
It still doesn't work. I was going to leave it out via --without-perl,
and save fixing that for another day. There's a handful of other
warnings when making, but --with-perl is the only showstopper
(once the
Andy Colson a...@squeakycode.net writes:
Is create temp unlogged table stuff(...) an option?
temp tables are unlogged already.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 16.11.2010 20:01, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
2. When a page is split, we mark the new left page with a flag to
indicate that the downlink for the page to the right hasn't been
inserted yet. When the downlink is inserted, the flag is
Itagaki Takahiro itagaki.takah...@gmail.com writes:
Here is a WIP patch to extensible executor nodes.
I am of the opinion that a run-time-extensible set of plan node types
is merest fantasy. We will never have that, so putting in place 5%
of the infrastructure for it is a waste of time and
On Tue, Nov 16, 2010 at 1:09 PM, Andy Colson a...@squeakycode.net wrote:
I was able to apply and compile and run ok, creating unlogged tables seems
to work as well.
I patched up pgbench to optionally create unlogged tables, and ran it both
ways. I get ~80tps normally, and ~1,500tps with
On Tue, Nov 16, 2010 at 1:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Itagaki Takahiro itagaki.takah...@gmail.com writes:
Here is a WIP patch to extensible executor nodes.
I am of the opinion that a run-time-extensible set of plan node types
is merest fantasy. We will never have that, so
On 11/16/10 9:27 AM, Robert Haas wrote:
I'm a little skeptical about creating more memory tunables. DBAs who
are used to previous versions of PG will find that their vacuum is now
really slow, because they adjusted maintenance_work_mem but not this
Also, generally people who are using
On Tue, Nov 16, 2010 at 1:36 PM, Josh Berkus j...@agliodbs.com wrote:
On 11/16/10 9:27 AM, Robert Haas wrote:
I'm a little skeptical about creating more memory tunables. DBAs who
are used to previous versions of PG will find that their vacuum is now
really slow, because they adjusted
On Tue, 2010-11-16 at 10:36 -0800, Josh Berkus wrote:
On 11/16/10 9:27 AM, Robert Haas wrote:
I'm a little skeptical about creating more memory tunables. DBAs who
are used to previous versions of PG will find that their vacuum is now
really slow, because they adjusted maintenance_work_mem
On Tue, Nov 16, 2010 at 1:22 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
BTW, I don't try to fix incomplete splits during vacuum in the patch. That's
perhaps a bit surprising, and probably would be easy to add, but I left it
out for now as it's not strictly necessary.
On 16.11.2010 20:46, Robert Haas wrote:
On Tue, Nov 16, 2010 at 1:22 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
BTW, I don't try to fix incomplete splits during vacuum in the patch. That's
perhaps a bit surprising, and probably would be easy to add, but I left it
out for
I think the difficulty is figuring out what to get the existing
workers to give us some memory when a new one comes along. You want
the first worker to potentially use ALL the memory... until worker #2
arrives.
Yeah, doing this would mean that you couldn't give worker #1 all the
memory,
Excerpts from Robert Haas's message of mar nov 16 15:34:55 -0300 2010:
On Tue, Nov 16, 2010 at 1:09 PM, Andy Colson a...@squeakycode.net wrote:
dump/restore?
All of those. I guess there's a question of what pg_dump should emit
for an unlogged table. Clearly, we need to dump a CREATE
Hello
2010/11/16 Peter Eisentraut pete...@gmx.net:
On mån, 2010-11-15 at 23:13 +0100, Pavel Stehule wrote:
a) default encoding for collate isn't same as default encoding of database
it's minimally not friendly - mostly used encoding is UTF8, but in
most cases users should to write
Excerpts from Josh Berkus's message of mar nov 16 15:52:14 -0300 2010:
I think the difficulty is figuring out what to get the existing
workers to give us some memory when a new one comes along. You want
the first worker to potentially use ALL the memory... until worker #2
arrives.
On Tue, Nov 16, 2010 at 1:58 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of mar nov 16 15:34:55 -0300 2010:
On Tue, Nov 16, 2010 at 1:09 PM, Andy Colson a...@squeakycode.net wrote:
dump/restore?
All of those. I guess there's a question of what
On Tue, Nov 16, 2010 at 1:50 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
If we start to enlarge the bounding boxes on the higher levels of the
tree and then crash before inserting the key, is there any mechanism
for getting them back down to the minimal size?
No. There's
they are consistent with the new key we're inserting. The old GiST
algorithm adjusted all the parent pages only after inserting the tuple
on the leaf. Updating them on the way down ensures that the tree is
Hm, performance? while you traverse to leaf page, on each inner page you will
need to call
On tis, 2010-11-16 at 20:00 +0100, Pavel Stehule wrote:
yes - my first question is: Why we need to specify encoding, when only
one encoding is supported? I can't to use a cs_CZ.iso88592 when my db
use a UTF8 - btw there is wrong message:
yyy=# select * from jmena order by jmeno collate
On Tue, Nov 16, 2010 at 12:19 PM, Greg Stark st...@mit.edu wrote:
On Tue, Nov 16, 2010 at 2:43 AM, Robert Haas robertmh...@gmail.com wrote:
I don't really think these changes to the INSTR macros make much
sense. The macros don't really add much notational convenience;
they're mostly wrappers
On lör, 2010-11-13 at 19:16 -0500, Robert Haas wrote:
1. The first one (relpersistence-v1) is a mostly mechanical patch that
replaces pg_class.relistemp (a Boolean) with pg_class.relpersistence
(a character), so that we can support more than two values. BE SURE
YOU INITDB, since the old
Hello All,
I am recently using sysbench with PostgreSQL 9.0 and 8.4.5 and doing
some tests on 8core systems with SSDs.
I seem to be hitting some problems with the read-write tests and
hoping to see if it is a possible concurrency bug or expected
behavior.
Using sysbench with 1M rows and 80+
2010/11/16 Magnus Hagander mag...@hagander.net:
On Tue, Nov 16, 2010 at 16:09, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
Is there a particular reason why track_functions is disabled by default?
Performance worries, plus the thought that not everyone cares
On Tue, Nov 16, 2010 at 11:38 AM, Robert Haas robertmh...@gmail.com wrote:
I think we should have a project policy of always printing memory and
disk usage in kB, MB, GB etc unless they're functions returning an
integer intended for machine use.
rhaas=# set work_mem to '1048577kB';
2010/11/16 Peter Eisentraut pete...@gmx.net:
On tis, 2010-11-16 at 20:00 +0100, Pavel Stehule wrote:
yes - my first question is: Why we need to specify encoding, when only
one encoding is supported? I can't to use a cs_CZ.iso88592 when my db
use a UTF8 - btw there is wrong message:
yyy=#
I can only look at the locales that the operating system provides. We
could conceivably make some simplifications like stripping off the
.utf8, but then how far do we go and where do we stop? Locale names
on Windows look different too. But in general, how do you suppose we
should map an
On Tue, Nov 16, 2010 at 2:53 PM, Greg Stark st...@mit.edu wrote:
Yeah, VERBOSE is kind of a catch-all for things that we don't have
individual flags for. But I think it's better for each piece of data
to depend on one setting, rather than a combination of two or more
settings. Otherwise you
Actually cutting down my mail to something more readable..
Lets consider two transactions
BEGIN;
BEGIN;
DELETE FROM sbtest WHERE id=500815;
INSERT INTO sbtest
values(500815,0,'','aaffrreeyy');
DELETE FROM sbtest WHERE id=500815;
On Tue, Nov 16, 2010 at 2:49 PM, Peter Eisentraut pete...@gmx.net wrote:
On lör, 2010-11-13 at 19:16 -0500, Robert Haas wrote:
1. The first one (relpersistence-v1) is a mostly mechanical patch that
replaces pg_class.relistemp (a Boolean) with pg_class.relpersistence
(a character), so that we
2010/11/16 marcin mank marcin.m...@gmail.com:
I can only look at the locales that the operating system provides. We
could conceivably make some simplifications like stripping off the
.utf8, but then how far do we go and where do we stop? Locale names
on Windows look different too. But in
On tis, 2010-11-16 at 15:08 -0500, Robert Haas wrote:
Btw., I would recommend that even in-progress or proposed patches
include catversion updates, which helps communicate the message such
as
yours in a more robust manner and also reduces the chance of
forgetting
the catversion change in
On tis, 2010-11-16 at 20:59 +0100, Pavel Stehule wrote:
2010/11/16 Peter Eisentraut pete...@gmx.net:
On tis, 2010-11-16 at 20:00 +0100, Pavel Stehule wrote:
yes - my first question is: Why we need to specify encoding, when only
one encoding is supported? I can't to use a cs_CZ.iso88592 when
On tis, 2010-11-16 at 21:05 +0100, marcin mank wrote:
It would be nice if we could have some mapping of locale names bult
in, so one doesn`t have to write alternative sql depending on DB
server OS:
select * from tab order by foo collate Polish, Poland
select * from tab order by foo collate
Relevant to this is the question: *when* does vacuum do its memory
allocation? Is memory allocation reasonably front-loaded, or does
vacuum keep grabbing more RAM until it's done?
All at start.
That means that allocation by halves would work fine.
--
--
2010/11/16 Peter Eisentraut pete...@gmx.net:
On tis, 2010-11-16 at 20:59 +0100, Pavel Stehule wrote:
2010/11/16 Peter Eisentraut pete...@gmx.net:
On tis, 2010-11-16 at 20:00 +0100, Pavel Stehule wrote:
yes - my first question is: Why we need to specify encoding, when only
one encoding is
Robert Haas robertmh...@gmail.com writes:
Oh. So do the indexes just degrade over time until they eventually
need to be REINDEX'd?
At some point you might reach a state where a reindex would be helpful.
But the same is true of btrees. I don't think this is a serious
objection, at least not
Robert Haas robertmh...@gmail.com writes:
On Tue, Nov 16, 2010 at 1:58 PM, Alvaro Herrera
I think if you do a regular backup of the complete database, unlogged
tables should come out empty, but if you specifically request a dump of
it, it shouldn't.
Oh, wow. That seems confusing.
I don't
On 16.11.2010 21:20, Teodor Sigaev wrote:
they are consistent with the new key we're inserting. The old GiST
algorithm adjusted all the parent pages only after inserting the tuple
on the leaf. Updating them on the way down ensures that the tree is
Hm, performance? while you traverse to leaf
On Tue, Nov 16, 2010 at 3:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Oh. So do the indexes just degrade over time until they eventually
need to be REINDEX'd?
At some point you might reach a state where a reindex would be helpful.
But the same is true
On tis, 2010-11-16 at 21:40 +0100, Pavel Stehule wrote:
ok, then we should to define this alias manually
some like - CREATE COLLATE czech FOR LOCALE cs_CZ.UTF8
or some similar. Without this, the application or stored procedures
can be non portable between UNIX and WIN.
Yes, such a command
Robert Haas robertmh...@gmail.com writes:
On Tue, Nov 16, 2010 at 2:49 PM, Peter Eisentraut pete...@gmx.net wrote:
Btw., I would recommend that even in-progress or proposed patches
include catversion updates,
I thought we had a policy of NOT doing that, because of the merge
conflicts thereby
On Tue, Nov 16, 2010 at 10:32:01PM +0200, Peter Eisentraut wrote:
On tis, 2010-11-16 at 21:05 +0100, marcin mank wrote:
It would be nice if we could have some mapping of locale names bult
in, so one doesn`t have to write alternative sql depending on DB
server OS:
select * from tab order
On 11/16/2010 02:06 PM, Robert Haas wrote:
On Tue, Nov 16, 2010 at 1:58 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
I think if you do a regular backup of the complete database, unlogged
tables should come out empty, but if you specifically request a dump of
it, it shouldn't.
Oh,
On tis, 2010-11-16 at 16:04 -0500, Tom Lane wrote:
Well, my expectation would be that the committer would reset the
catversion to current date when it goes into master. The question is
whether such a practice would be (a) helpful to testers and/or (b)
useful to the committer.
As with most
On mån, 2010-11-15 at 23:34 -0500, Tom Lane wrote:
It's clear to me that we are very far from having a handle on what
it'll really take to run parallel builds safely, and I am therefore
now of the opinion that we ought to revert the patch. Hypothetical
gains in parallelism are useless if we
On Tue, Nov 16, 2010 at 3:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Nov 16, 2010 at 1:58 PM, Alvaro Herrera
I think if you do a regular backup of the complete database, unlogged
tables should come out empty, but if you specifically request a
Yeah, you'd have to allow a flag to control the behavior. And in that
case I'd rather the flag have a single default rather than different
defaults depending on whether or not individual tables were selected.
Something like --omit-unlogged-data.
Are you sure we don't want to default the
On Tue, Nov 16, 2010 at 02:00:33PM -0800, Josh Berkus wrote:
Yeah, you'd have to allow a flag to control the behavior. And in
that case I'd rather the flag have a single default rather than
different defaults depending on whether or not individual tables
were selected. Something like
On tis, 2010-11-16 at 14:00 -0800, Josh Berkus wrote:
It seems to me
that most people using unlogged tables won't want to back them up ...
especially since the share lock for pgdump will add overhead for the
kinds of high-volume updates people want to do with unlogged tables.
Or perhaps most
On 11/16/10 2:08 PM, Peter Eisentraut wrote:
On tis, 2010-11-16 at 14:00 -0800, Josh Berkus wrote:
It seems to me
that most people using unlogged tables won't want to back them up ...
especially since the share lock for pgdump will add overhead for the
kinds of high-volume updates people want
On Tue, 2010-11-16 at 14:00 -0800, Josh Berkus wrote:
Yeah, you'd have to allow a flag to control the behavior. And in that
case I'd rather the flag have a single default rather than different
defaults depending on whether or not individual tables were selected.
Something like
On fre, 2010-11-12 at 09:44 -0500, Tom Lane wrote:
But I'm still not convinced that this feature is useful enough to
justify the implementation effort. AFAICS there's nothing here that
you couldn't get with some non-default operators on regular arrays,
Unique constraints would behave
On 11/16/2010 05:12 PM, Josh Berkus wrote:
On 11/16/10 2:08 PM, Peter Eisentraut wrote:
On tis, 2010-11-16 at 14:00 -0800, Josh Berkus wrote:
It seems to me
that most people using unlogged tables won't want to back them up ...
especially since the share lock for pgdump will add overhead for
Robert Haas robertmh...@gmail.com writes:
On Tue, Nov 16, 2010 at 3:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I think allowing pg_dump to dump the data in an unlogged table is not
only reasonable, but essential.
Yeah, you'd have to allow a flag to control the behavior. And in that
case I'd
On Wed, 2010-11-17 at 00:08 +0200, Peter Eisentraut wrote:
On tis, 2010-11-16 at 14:00 -0800, Josh Berkus wrote:
It seems to me
that most people using unlogged tables won't want to back them up ...
especially since the share lock for pgdump will add overhead for the
kinds of high-volume
Jignesh Shah jks...@gmail.com wrote:
The question is should the delete fail if it doesn't exist and
cause a rollback or succeed with DELETE 0 ?
I think existing behavior is consistent with both the standard and
the other behaviors of PostgreSQL at the READ COMMITTED isolation
level. I might
Peter Eisentraut pete...@gmx.net writes:
On mån, 2010-11-15 at 23:34 -0500, Tom Lane wrote:
It's clear to me that we are very far from having a handle on what
it'll really take to run parallel builds safely, and I am therefore
now of the opinion that we ought to revert the patch.
We don't
On Tuesday 16 November 2010 23:12:10 Josh Berkus wrote:
On 11/16/10 2:08 PM, Peter Eisentraut wrote:
On tis, 2010-11-16 at 14:00 -0800, Josh Berkus wrote:
It seems to me
that most people using unlogged tables won't want to back them up ...
especially since the share lock for pgdump will
Andres Freund and...@anarazel.de wrote:
One way your backup runs too long and too much data changes, the
other way round you loose the data which you assumed safely
backuped.
Isn't that a *really* easy decision?
Yeah. Count me in the camp which wants the default behavior to be
that
Martijn van Oosterhout klep...@svana.org writes:
On Tue, Nov 16, 2010 at 10:32:01PM +0200, Peter Eisentraut wrote:
On tis, 2010-11-16 at 21:05 +0100, marcin mank wrote:
It would be nice if we could have some mapping of locale names bult
in, so one doesn`t have to write alternative sql
On Tuesday 16 November 2010 23:30:29 Andres Freund wrote:
On Tuesday 16 November 2010 23:12:10 Josh Berkus wrote:
On 11/16/10 2:08 PM, Peter Eisentraut wrote:
On tis, 2010-11-16 at 14:00 -0800, Josh Berkus wrote:
It seems to me
that most people using unlogged tables won't want to back
Josh Berkus j...@agliodbs.com writes:
Yeah, you'd have to allow a flag to control the behavior. And in that
case I'd rather the flag have a single default rather than different
defaults depending on whether or not individual tables were selected.
Something like --omit-unlogged-data.
Are you
That's a very debatable assumption. You got any evidence for it?
Personally, I don't think pg_dump should ever default to omitting
data.
Survey launched, although it may become a moot point, given how this
discussion is going.
--
-- Josh Berkus
Peter Eisentraut pete...@gmx.net writes:
On fre, 2010-11-12 at 09:44 -0500, Tom Lane wrote:
But I'm still not convinced that this feature is useful enough to
justify the implementation effort. AFAICS there's nothing here that
you couldn't get with some non-default operators on regular arrays,
On Tue, Nov 16, 2010 at 5:30 PM, Andres Freund and...@anarazel.de wrote:
On Tuesday 16 November 2010 23:12:10 Josh Berkus wrote:
On 11/16/10 2:08 PM, Peter Eisentraut wrote:
On tis, 2010-11-16 at 14:00 -0800, Josh Berkus wrote:
It seems to me
that most people using unlogged tables won't
Can (should ?) unlogged tables' contents survive graceful (non-crash) shutdown?
Greetings
Marcin Mańk
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Nov 16, 2010 at 5:57 PM, marcin mank marcin.m...@gmail.com wrote:
Can (should ?) unlogged tables' contents survive graceful (non-crash)
shutdown?
I don't think so. To make that work, you'd need to keep track of
every backing file that might contain pages not fsync()'d to disk, and
at
Robert Haas robertmh...@gmail.com writes:
On Tue, Nov 16, 2010 at 5:57 PM, marcin mank marcin.m...@gmail.com wrote:
Can (should ?) unlogged tables' contents survive graceful (non-crash)
shutdown?
I don't think so. To make that work, you'd need to keep track of
every backing file that might
On 11/16/10 4:40 PM, Robert Haas wrote:
But I'm happy to leave all of this until we gain some field experience
with this feature, and have a better idea what features people would
most like to see.
+1. Let's not complicate this.
--
-- Josh Berkus
(2010/11/15 11:50), Robert Haas wrote:
On Thu, Nov 4, 2010 at 10:04 AM, Robert Haasrobertmh...@gmail.com wrote:
On Thu, Nov 4, 2010 at 6:35 AM, Stephen Frostsfr...@snowman.net wrote:
* Jan Urbański (wulc...@wulczer.org) wrote:
On 04/11/10 14:09, Robert Haas wrote:
Hmm, I wonder how useful
On Wed, Nov 17, 2010 at 03:36, Robert Haas robertmh...@gmail.com wrote:
On Tue, Nov 16, 2010 at 1:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I am of the opinion that a run-time-extensible set of plan node types
is merest fantasy. We will never have that, so putting in place 5%
of the
On Tue, Nov 16, 2010 at 7:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Nov 16, 2010 at 5:57 PM, marcin mank marcin.m...@gmail.com wrote:
Can (should ?) unlogged tables' contents survive graceful (non-crash)
shutdown?
I don't think so. To make
1 - 100 of 109 matches
Mail list logo
