On Tue, Nov 16, 2010 at 3:07 AM, Robert Haas 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 might also h
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 wrote:
> With Informix VTI, indexing is the same for native tables as for
> vir
On Tue, Nov 16, 2010 at 01:35, Tom Lane 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 handle larger than 2^
On Tue, Nov 16, 2010 at 10:01 AM, Magnus Hagander wrote:
> On Tue, Nov 16, 2010 at 01:35, Tom Lane 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
On Tue, Nov 16, 2010 at 3:07 AM, Robert Haas 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 seems like this will
On Fri, Nov 12, 2010 at 17:47, Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian 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.
>
> Thanks, I am now a
On Tue, Nov 16, 2010 at 11:01, Magnus Hagander wrote:
> On Tue, Nov 16, 2010 at 01:35, Tom Lane 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 gu
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 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 functions? Or for
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 clang
On Tue, Nov 16, 2010 at 15:42, Tom Lane wrote:
> Magnus Hagander writes:
>> On Tue, Nov 16, 2010 at 11:01, Magnus Hagander wrote:
>>> So yes, it looks completely broken. I guess Windows doesn't actually
>>> *assign* you a handle larger than 2^32 until you actually ahve that
>>> many open handles
Greg Sabino Mullane 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
> GNU_SOURCE v
On Tue, Nov 16, 2010 at 16:09, Tom Lane wrote:
> Magnus Hagander 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 actively using stored procedures proba
On Tue, Nov 16, 2010 at 16:23, Tom Lane wrote:
> Magnus Hagander 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 are sign extended 32b valu
On Tue, Nov 16, 2010 at 16:35, Tom Lane wrote:
> Magnus Hagander writes:
>> On Tue, Nov 16, 2010 at 16:23, Tom Lane wrote:
>>> What's not clear to me is whether the section title means that only
>>> certain handles have this guarantee, and if so whether we have to worry
>>> about running into on
On 13.11.2010 00:34, Greg Stark wrote:
On Fri, Nov 12, 2010 at 7:20 PM, Heikki Linnakangas
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 indicating that the rightlink must a
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 "autovacuum_main
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 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, but is there the sam
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 writes:
> On Wed, Nov 17, 2010 at 01:12, Alvaro Herrera 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 so
On Tue, Nov 16, 2010 at 2:43 AM, Robert Haas 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 instrumentation stuff,
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
(http://archives.postgresql.org/pgsql-hackers/2007-02/ms
On Tue, Nov 16, 2010 at 11:12 AM, Alvaro Herrera
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 value and DBA B raises
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 wrote:
> With Informix VTI, i
Heikki Linnakangas 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 we're inserting. The old GiST
> al
-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 als
"Greg Sabino Mullane" 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 GNU_SOUR
Andy Colson 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:
http://www.postgresql.org/mailpref
On 16.11.2010 20:01, Tom Lane wrote:
Heikki Linnakangas 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 cleared. Again
the purpose is to ensure tha
Itagaki Takahiro 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 notational
complexity.
I woul
On Tue, Nov 16, 2010 at 1:09 PM, Andy Colson 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 unlogged. (Thats fr
On Tue, Nov 16, 2010 at 1:28 PM, Tom Lane wrote:
> Itagaki Takahiro 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
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 autov
On Tue, Nov 16, 2010 at 1:36 PM, 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_me
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_wor
On Tue, Nov 16, 2010 at 1:22 PM, Heikki Linnakangas
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.
Seems like it would be good to have
On 16.11.2010 20:46, Robert Haas wrote:
On Tue, Nov 16, 2010 at 1:22 PM, Heikki Linnakangas
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.
> 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 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 UNLOGGED
> TABLE st
Hello
2010/11/16 Peter Eisentraut :
> 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.
>
>
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
> > arrive
On Tue, Nov 16, 2010 at 1:58 PM, Alvaro Herrera
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 wrote:
>
>> > dump/restore?
>>
>> All of those. I guess there's a question of what pg_dump should emit
>> for an unlogge
On Tue, Nov 16, 2010 at 1:50 PM, Heikki Linnakangas
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 also no mechanism for trimm
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 wrote:
> On Tue, Nov 16, 2010 at 2:43 AM, Robert Haas 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-WI
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 ca
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+ t
2010/11/16 Magnus Hagander :
> On Tue, Nov 16, 2010 at 16:09, Tom Lane wrote:
>> Magnus Hagander 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 11:38 AM, Robert Haas 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';
Interesting. Though in
2010/11/16 Peter Eisentraut :
> 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 *
> 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
On Tue, Nov 16, 2010 at 2:53 PM, Greg Stark 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 end up
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 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 can suppor
2010/11/16 marcin mank :
>> 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 d
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
On tis, 2010-11-16 at 20:59 +0100, Pavel Stehule wrote:
> 2010/11/16 Peter Eisentraut :
> > 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
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 coll
>> 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 :
> On tis, 2010-11-16 at 20:59 +0100, Pavel Stehule wrote:
>> 2010/11/16 Peter Eisentraut :
>> > 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
Robert Haas 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 unless backed by evide
Robert Haas 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 like it either.
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 page
On Tue, Nov 16, 2010 at 3:46 PM, Tom Lane wrote:
> Robert Haas 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
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
Robert Haas writes:
> On Tue, Nov 16, 2010 at 2:49 PM, Peter Eisentraut 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 created. It's also hard to k
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
On 11/16/2010 02:06 PM, Robert Haas wrote:
On Tue, Nov 16, 2010 at 1:58 PM, Alvaro Herrera
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, wow. That seems confusing.
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 w
On Tue, Nov 16, 2010 at 3:50 PM, Tom Lane wrote:
> Robert Haas 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.
>
>
> 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 l
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 mo
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 peo
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 --om
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 differ
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 t
Robert Haas writes:
> On Tue, Nov 16, 2010 at 3:50 PM, Tom Lane 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 rather the flag have a single def
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-
Jignesh Shah 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 have found it
Peter Eisentraut 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 have to r
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 pg
Andres Freund 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 pg_dump backs up a
Martijn van Oosterhout 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 depending on DB
>
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
Josh Berkus 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 sure we
> 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 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,
> Uniqu
On Tue, Nov 16, 2010 at 5:30 PM, 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
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 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 shutdown time you'd
Robert Haas writes:
> On Tue, Nov 16, 2010 at 5:57 PM, marcin mank 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
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 Haas wrote:
On Thu, Nov 4, 2010 at 6:35 AM, Stephen Frost wrote:
* Jan Urbański (wulc...@wulczer.org) wrote:
On 04/11/10 14:09, Robert Haas wrote:
Hmm, I wonder how useful this is given that restriction.
As Kai
On Wed, Nov 17, 2010 at 03:36, Robert Haas wrote:
> On Tue, Nov 16, 2010 at 1:28 PM, Tom Lane 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 infrastructure for it is a waste of time a
On Tue, Nov 16, 2010 at 7:46 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Nov 16, 2010 at 5:57 PM, marcin mank 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 b
1 - 100 of 109 matches
Mail list logo
