On 11.01.2011 23:51, Jeff Davis wrote:
On Tue, 2011-01-11 at 22:56 +0200, Heikki Linnakangas wrote:
1. If it's a primary recovering from a crash, and there is a
backup_label file, and the WAL referenced in the backup_label exists,
then it does a bunch of extra work during recovery; and
2.
On Tue, Jan 11, 2011 at 09:24:08PM -0500, Robert Haas wrote:
> commit 6c412f0605afeb809014553ff7ad28cf9ed5526b
> Author: Tom Lane
> Date: Sun May 1 18:56:19 2005 +
>
> Change CREATE TYPE to require datatype output and send functions to have
> only one argument. (Per recent discussi
On ons, 2011-01-12 at 13:52 +0900, Itagaki Takahiro wrote:
> I added a short description about MULTISET and example of operators
> in "Arrays > 8.14.7. Multiset Support" section in the docs.
> Is it enough? or what kind of information do you want?
>
> Separate patches for src and doc attached. It
On 01/11/2011 09:06 PM, Robert Haas wrote:
On Tue, Jan 11, 2011 at 7:55 PM, Andrew Dunstan wrote:
On 01/11/2011 07:17 PM, David E. Wheeler wrote:
On Jan 11, 2011, at 3:44 PM, Andrew Dunstan wrote:
I think there's at least a danger of breaking legacy code doing that. Say
you have some code
On Sat, Dec 25, 2010 at 2:09 PM, Maxim Boguk wrote:
> While I trying create reproducible test case for BUG #5798 I
> encountered very strange effect on two of my servers (both servers
> have same hardware platform/OS (freebsd 7.2) and PostgreSQL 8.4.4).
>
> Very simple test table created as:
> CRE
On 01/11/2011 10:24 PM, Shigeru HANADA wrote:
On Tue, 11 Jan 2011 13:24:33 +0100
Magnus Hagander wrote:
Aha. Thanks for the pointers, pfa a new version.
Changing pg_stat replication view would require to fix regression test
"rule". Please find attached patch.
I have just committed a fix
On Tue, 11 Jan 2011 13:24:33 +0100
Magnus Hagander wrote:
> Aha. Thanks for the pointers, pfa a new version.
Changing pg_stat replication view would require to fix regression test
"rule". Please find attached patch.
Regards,
--
Shigeru Hanada
rule_test.patch
Description: Binary data
--
Sent
On Sun, Jan 9, 2011 at 5:00 PM, Noah Misch wrote:
> When ALTER TABLE rewrites a table, it reindexes, but the reindex does not
> revalidate UNIQUE/EXCLUDE constraints. This behaves badly in cases like this,
> neglecting to throw an error on the new UNIQUE violation:
>
> CREATE TABLE t (c numeric U
On Tue, Jan 11, 2011 at 7:25 AM, Noah Misch wrote:
> On Tue, Jan 11, 2011 at 06:37:33AM -0500, Robert Haas wrote:
>> On Sun, Jan 9, 2011 at 4:59 PM, Noah Misch wrote:
>> > This begins the patch series for the design I recently proposed[1] for
>> > avoiding
>> > some table rewrites in ALTER TABLE
On Jan11, 2011, at 23:55 , Joel Jacobson wrote:
> 2011/1/11 Florian Pflug :
>> Could you give an example of the kind of trouble you're experiencing trying
>> to use a topological sort?
>
> Let's say you have a table t and a view v.
> The view v is defined as select * from t;
> If we put all object
On Sun, Jan 9, 2011 at 4:03 AM, Jeff Davis wrote:
> It also might be worth figuring out why input functions get the type oid
> and output functions do not. I see this comment above getTypeIOParam():
>
> * As of PostgreSQL 8.1, output functions receive only the value
> itself
> * and not any auxi
We have 46 patches in this CommitFest so far and I know that there are
quite a few patches that have been posted but not added to the
CommitFest application yet (please fix this, if you are a patch author
who has failed to do this) and that there will be lots more patches
posted over the next few d
On Tue, Jan 11, 2011 at 7:55 PM, Andrew Dunstan wrote:
> On 01/11/2011 07:17 PM, David E. Wheeler wrote:
>> On Jan 11, 2011, at 3:44 PM, Andrew Dunstan wrote:
>>
>>> I think there's at least a danger of breaking legacy code doing that. Say
>>> you have some code that does a ref test on the argumen
On Tue, Jan 11, 2011 at 7:24 AM, Magnus Hagander wrote:
>> No, do this at top
>>
>> if (walsnd->state == state)
>> return;
>>
>> Keep spinlocks when actually setting it.
I think this is safe...
> Aha. Thanks for the pointers, pfa a new version.
...but I think you also need to take the spinlock
2011/1/11 Heikki Linnakangas :
> On 11.01.2011 21:50, Dimitri Fontaine wrote:
>>
>> Heikki Linnakangas writes:
>>
>>> Now that we have a basic over-the-wire base backup capability in
>>> walsender,
>>> it would be nice to allow taking multiple base backups at the same time.
>>
>> I would prefer to
On Tue, Jan 11, 2011 at 7:14 PM, Tom Lane wrote:
> Andreas Karlsson writes:
>> On Tue, 2011-01-11 at 14:01 -0500, Tom Lane wrote:
>>> It really shouldn't be useful to include those. Attend what it says in
>>> the fine manual for CREATE OPERATOR CLASS:
>
>> Hm, that is not what I see when reading
On Tue, Jan 11, 2011 at 10:35 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jan 11, 2011 at 4:46 AM, Tatsuo Ishii wrote:
>>> For query based replication tools like pgpool-II (I don't know any
>>> other tools, for example Postgres XC falls in this category or
>>> not...), we need to be abl
On Tue, Nov 30, 2010 at 3:29 PM, Greg Smith wrote:
> Having the pg_stat_bgwriter.buffers_backend_fsync patch available all the
> time now has made me reconsider how important one potential bit of
> refactoring here would be. I managed to catch one of the situations where
> really popular relation
On 01/11/2011 07:17 PM, David E. Wheeler wrote:
On Jan 11, 2011, at 3:44 PM, Andrew Dunstan wrote:
I think there's at least a danger of breaking legacy code doing that. Say you
have some code that does a ref test on the argument, for example. The behavior
would now be changed.
I think that
> In the SEQUENCE example above, SELECT ... FOR UPDATE is certainly not
> adequate to protect the sequence against DDL-level changes. Fortunately
> sequences don't have too many DDL commands, but still an ALTER RENAME
> might be enough to confuse pg_dump.
>
> (By the way, does that SELECT ... FOR
On Thu, 2011-01-06 at 12:27 -0500, Robert Haas wrote:
> I've noticed something like this as well, but haven't been able to
> figure out exactly what is going wrong.
I've been having build problems ever since:
http://archives.postgresql.org/message-id/1291256879.25389.6.ca...@jdavis-ux.asterdata.l
On Jan 11, 2011, at 3:44 PM, Andrew Dunstan wrote:
> I think there's at least a danger of breaking legacy code doing that. Say you
> have some code that does a ref test on the argument, for example. The
> behavior would now be changed.
I think that'd be pretty rare.
David
--
Sent via pgsql-
Andreas Karlsson writes:
> On Tue, 2011-01-11 at 14:01 -0500, Tom Lane wrote:
>> It really shouldn't be useful to include those. Attend what it says in
>> the fine manual for CREATE OPERATOR CLASS:
> Hm, that is not what I see when reading the source.
> There can exist several entries in pg_amp
Peter Eisentraut writes:
> On tor, 2011-01-06 at 11:57 -0500, Tom Lane wrote:
>> Whilst fooling around with GIN, I have repeatedly observed that doing
>> "make" in src/backend/access/gin, followed by "make install-bin" in
>> src/backend, fails to rebuild the postgres executable --- it just
>> inst
On Tue, 2011-01-11 at 14:01 -0500, Tom Lane wrote:
> It really shouldn't be useful to include those. Attend what it says in
> the fine manual for CREATE OPERATOR CLASS:
>
> In a FUNCTION clause, the operand data type(s) the function is
> intended to support, if different from the inpu
On 01/11/2011 06:07 PM, David E. Wheeler wrote:
To maintain
compatibility with existing pl/perl code a new variable,
plperl.convert_array_arguments (better name?), is introduced. Its default
value is false, when set to true it triggers the new behavior, i.e.
Have you considered instead passi
On Tue, 2011-01-11 at 23:07 +0100, Magnus Hagander wrote:
> I think keeping the flexibility is important. If it does add an extra
> step I think that's ok once we have pg_basebackup, but it must be
> reasonably *safe*. Corrupt backups from forgetting to exclude a file
> seems not so.
Agreed.
> B
On Jan 11, 2011, at 2:25 PM, Alexey Klyukin wrote:
> Hello,
>
> Here's the patch that improves handling of arrays as pl/perl function input
> arguments, converting postgres arrays of arbitrary dimensions into perl array
> references.
Awesome! I've wanted this for *years*.
> It includes regressi
Is it a good idea that we run make check with MULTIBYTE = SQL_ASCII by
default? We run it with the user's locale by default, so shouldn't we
use the encoding that belongs to the locale by default? Otherwise we
are testing a fairly unrepresentative environment. If you really want
to test SQL_ASCI
2011/1/11 Florian Pflug :
> Could you give an example of the kind of trouble you're experiencing trying
> to use a topological sort?
Let's say you have a table t and a view v.
The view v is defined as select * from t;
If we put all objects in a tree, with the public schema as the root,
both v and
Hello,
Here's the patch that improves handling of arrays as pl/perl function input
arguments, converting postgres arrays of arbitrary dimensions into perl array
references. It includes regression tests and a documentation changes, and it
builds and runs successfully on my mac os x and linux boxes.
On Tue, Jan 11, 2011 at 05:06:34PM -0500, Robert Haas wrote:
> On Jan 11, 2011, at 2:07 PM, Tom Lane wrote:
> > The whole thing just seems too fragile and dangerous to be worth dealing
> > with given that actual usage will be a corner case. *I* sure wouldn't
> > trust it to work when the chips we
On tor, 2011-01-06 at 11:57 -0500, Tom Lane wrote:
> Whilst fooling around with GIN, I have repeatedly observed that doing
> "make" in src/backend/access/gin, followed by "make install-bin" in
> src/backend, fails to rebuild the postgres executable --- it just
> installs the existing one. A second
On Jan 11, 2011, at 2:07 PM, Tom Lane wrote:
> The whole thing just seems too fragile and dangerous to be worth dealing
> with given that actual usage will be a corner case. *I* sure wouldn't
> trust it to work when the chips were down.
I hope this assessment proves to be incorrect, because like
On Tue, Jan 11, 2011 at 22:51, Jeff Davis wrote:
> On Tue, 2011-01-11 at 22:56 +0200, Heikki Linnakangas wrote:
>> > 1. If it's a primary recovering from a crash, and there is a
>> > backup_label file, and the WAL referenced in the backup_label exists,
>> > then it does a bunch of extra work dur
On Tue, 2011-01-11 at 22:56 +0200, Heikki Linnakangas wrote:
> > 1. If it's a primary recovering from a crash, and there is a
> > backup_label file, and the WAL referenced in the backup_label exists,
> > then it does a bunch of extra work during recovery; and
> > 2. In the same situation, if th
Em 10-01-2011 05:25, Greg Smith escreveu:
Euler Taveira de Oliveira wrote:
Em 07-01-2011 22:59, Greg Smith escreveu:
setrandom: invalid maximum number -2147467296
It is failing at atoi() circa pgbench.c:1036. But it just the first
one. There are some variables and constants that need to be co
On tis, 2011-01-11 at 16:57 +0100, Dimitri Fontaine wrote:
> Peter Eisentraut writes:
> > Making it work for language SQL would be nice, though.
>
> Please consider a new DEPENDENCY_XXX constant for that though, because
> otherwise I think it could cause problems in the extension's dependency
> t
On 11.01.2011 22:16, Jeff Davis wrote:
On Tue, 2011-01-11 at 20:17 +0200, Heikki Linnakangas wrote:
So, this patch modifies the internal do_pg_start/stop_backup functions
so that in addition to the traditional mode of operation, where a
backup_label file is created in the data directory where it
On 11/01/11 18:59, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>> On 11/01/11 17:11, Tom Lane wrote:
>>> Huh? Why in the world would the specific location of the #include have
>>> anything to do with the problem?
>
>> I'v having a hard time convincing make to generate errcodes.h b
On Tue, 2011-01-11 at 20:17 +0200, Heikki Linnakangas wrote:
> So, this patch modifies the internal do_pg_start/stop_backup functions
> so that in addition to the traditional mode of operation, where a
> backup_label file is created in the data directory where it's backed up
> along with all oth
On 11.01.2011 21:50, Dimitri Fontaine wrote:
Heikki Linnakangas writes:
Now that we have a basic over-the-wire base backup capability in walsender,
it would be nice to allow taking multiple base backups at the same time.
I would prefer to be able to take a base backup from a standby, or is
t
Excerpts from Stephen Frost's message of vie ene 07 15:29:52 -0300 2011:
> * Stephen Frost (sfr...@snowman.net) wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> > > > Making it part of DISCARD PLANS; and back-patching it to 8.3 where
> > > > DISCARD was introduced would be awesome for me.
Heikki Linnakangas writes:
> Now that we have a basic over-the-wire base backup capability in walsender,
> it would be nice to allow taking multiple base backups at the same time.
I would prefer to be able to take a base backup from a standby, or is
that already possible? What about cascading t
On Tue, Jan 11, 2011 at 01:16:47AM -0800, Jeff Davis wrote:
> Ok, I have made some progress. This is still a proof-of-concept patch,
> but the important pieces are working together.
>
> Synopsis:
>
> CREATE TYPE numrange AS RANGE (SUBTYPE=numeric,
> SUBTYPE_CMP=numeric_cmp);
>
> SELECT
On 11.01.2011 20:17, Heikki Linnakangas wrote:
Patches for both approaches attached. They're also available in my
github repository at g...@github.com:hlinnaka/postgres.git.
Just so people won't report the same issues again, a couple of bugs have
already cropped up (thanks Magnus):
* a backu
Magnus Hagander writes:
> On Tue, Jan 11, 2011 at 19:51, Tom Lane wrote:
>> Seems like either one of these is fairly problematic in that you have to
>> have some monstrous kluge to get the backup_label file to appear with
>> the right name in the tarfile. How badly do we actually need this?
>> I
> It makes it very convenient to set up standbys, without having to worry
> that you'll conflict e.g with a nightly backup. I don't imagine people
> will use streaming base backups for very large databases anyway.
Also, imagine that you're provisioning a 10-node replication cluster on
EC2. This
On 11.01.2011 20:51, Tom Lane wrote:
Heikki Linnakangas writes:
I implemented this in two ways, and can't decide which I like better:
1. The contents of the backup label file are returned to the caller of
do_pg_start_backup() as a palloc'd string.
2. do_pg_start_backup() creates a tempora
Andreas Karlsson writes:
> So would anyone be confused by a description of pg_amproc not including
> the types?
It really shouldn't be useful to include those. Attend what it says in
the fine manual for CREATE OPERATOR CLASS:
In a FUNCTION clause, the operand data type(s) the function i
On Tue, Jan 11, 2011 at 19:51, Tom Lane wrote:
> Heikki Linnakangas writes:
>> I implemented this in two ways, and can't decide which I like better:
>
>> 1. The contents of the backup label file are returned to the caller of
>> do_pg_start_backup() as a palloc'd string.
>
>> 2. do_pg_start_backup
Heikki Linnakangas writes:
> I implemented this in two ways, and can't decide which I like better:
> 1. The contents of the backup label file are returned to the caller of
> do_pg_start_backup() as a palloc'd string.
> 2. do_pg_start_backup() creates a temporary file that the backup label
> is
On Jan11, 2011, at 19:41 , Heikki Linnakangas wrote:
> On 11.01.2011 20:08, Florian Pflug wrote:
>> Unfortunately, it seems that doing things this way will undermine the
>> guarantee
>> that retrying a failed SSI transaction won't fail due to the same conflict as
>> it did originally. Consider
>>
On Tue, 2011-01-11 at 11:43 -0500, Tom Lane wrote:
> If that's what you're after, getObjectDescription is entirely
> unsuitable, because of the fact that its results are dependent
> on search path and language settings.
>
> regards, tom lane
Agreed, and as long as the additi
Heikki Linnakangas wrote:
> On 11.01.2011 20:08, Florian Pflug wrote:
>> Unfortunately, it seems that doing things this way will undermine
>> the guarantee that retrying a failed SSI transaction won't fail
>> due to the same conflict as it did originally. Consider
>>
>> T1> BEGIN TRANSACTION ISOL
On 11.01.2011 20:08, Florian Pflug wrote:
Unfortunately, it seems that doing things this way will undermine the guarantee
that retrying a failed SSI transaction won't fail due to the same conflict as
it did originally. Consider
T1> BEGIN TRANSACTION ISOLATION SERIALIZABLE
T1> SELECT * FROM T
T
Jeff Davis wrote:
> I don't expect this to be a huge roadblock for the feature though.
> It seems fairly contained. I haven't read the 2PC code either, but
> I don't expect that you'll need to change the rest of your
> algorithm just to support it.
Agreed; but I am starting to get concerned ab
Florian Pflug wrote:
> On Jan10, 2011, at 18:50 , Kevin Grittner wrote:
>> I'm trying not to panic here, but I haven't looked at 2PC before
>> yesterday and am just dipping into the code to support it, and
>> time is short. Can anyone give me a pointer to anything I should
>> read before I dig th
On Tue, Jan 11, 2011 at 12:45:02PM -0500, Tom Lane wrote:
> Florian Pflug writes:
> > On Jan11, 2011, at 18:09 , Garick Hamlin wrote:
> >> My gut was that direct io would likely work right on Linux
> >> and Solaris, at least.
>
> > Didn't we discover recently that O_DIRECT fails for ext4 on linux
Now that we have a basic over-the-wire base backup capability in
walsender, it would be nice to allow taking multiple base backups at the
same time. It might not seem very useful at first, but it makes it
easier to set up standbys for small databases. At the moment, if you
want to set up two st
On Jan10, 2011, at 18:50 , Kevin Grittner wrote:
> I'm trying not to panic here, but I haven't looked at 2PC before
> yesterday and am just dipping into the code to support it, and time
> is short. Can anyone give me a pointer to anything I should read
> before I dig through the 2PC code, which mi
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
> On 11/01/11 17:11, Tom Lane wrote:
>> Huh? Why in the world would the specific location of the #include have
>> anything to do with the problem?
> I'v having a hard time convincing make to generate errcodes.h before
> compiling any .c file that includes
Florian Pflug writes:
> On Jan11, 2011, at 18:09 , Garick Hamlin wrote:
>> My gut was that direct io would likely work right on Linux
>> and Solaris, at least.
> Didn't we discover recently that O_DIRECT fails for ext4 on linux
> if ordered=data, or something like that?
Quite. Blithe assertions
On 11/01/11 17:11, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>>> I tried wiring it into the build system, but failed, I can't figure out
>>> which Makefiles should be updated in order to make errcodes.h and
>>> plerrcodes.h generated headers. Could someone help with that?
>
>> Tr
On Mon, 2011-01-10 at 11:50 -0600, Kevin Grittner wrote:
> I'm trying not to panic here, but I haven't looked at 2PC before
> yesterday and am just dipping into the code to support it, and time
> is short. Can anyone give me a pointer to anything I should read
> before I dig through the 2PC code,
2011/1/11 Garick Hamlin :
> On Tue, Jan 11, 2011 at 11:39:20AM -0500, Cédric Villemain wrote:
>> 2011/1/11 Garick Hamlin :
>> > On Mon, Jan 10, 2011 at 09:09:28AM -0500, Magnus Hagander wrote:
>> >> On Sun, Jan 9, 2011 at 23:33, Cédric Villemain
>> >> wrote:
>> >> > 2011/1/7 Magnus Hagander :
>> >
On Jan11, 2011, at 18:09 , Garick Hamlin wrote:
> My gut was that direct io would likely work right on Linux
> and Solaris, at least.
Didn't we discover recently that O_DIRECT fails for ext4 on linux
if ordered=data, or something like that?
best regards,
Florian Pflug
--
Sent via pgsql-hacker
On Jan11, 2011, at 16:54 , Joel Jacobson wrote:
> Has anyone written a in-depth description on how to traverse the pg_depend
> tree?
> The 'a' and 'i' deptype really makes it hard to figure out the
> dependency order, a topological sort does not work.
Could you give an example of the kind of trou
On Tue, Jan 11, 2011 at 11:39:20AM -0500, Cédric Villemain wrote:
> 2011/1/11 Garick Hamlin :
> > On Mon, Jan 10, 2011 at 09:09:28AM -0500, Magnus Hagander wrote:
> >> On Sun, Jan 9, 2011 at 23:33, Cédric Villemain
> >> wrote:
> >> > 2011/1/7 Magnus Hagander :
> >> >> On Fri, Jan 7, 2011 at 01:47,
On tis, 2011-01-11 at 11:03 -0500, Tom Lane wrote:
> We explicitly
> rejected the idea of providing direct casts to/from floating point
> types, on the grounds of not wanting any roundoff error; so I don't
> think this is a point that should be revisited.
We also explicitly chose floating point as
Joel Jacobson writes:
> I need to figure out the order of creation of all objects, not just
> the dependencies for a single object.
In that case try pg_dump's pg_dump_sort.c. You will never get "the"
order of creation of objects, because that isn't tracked; but you can
find out what a safe order
Joel Jacobson writes:
> 2011/1/11 Tom Lane :
>> Seems like concatenating the OIDs would accomplish that. (If you
>> think not, well, you still haven't explained what problem you're trying
>> to solve...)
> The can be different in two different databases sharing the same
> original schema, but of
2011/1/11 Tom Lane :
> Try reading the code in src/backend/catalog/dependency.c.
I've tried but failed to figure it out anyway. The focus in
dependency.c is to find out dependencies of a given object.
What I want to do is something slighly different.
I need to figure out the order of creation of a
2011/1/11 Garick Hamlin :
> On Mon, Jan 10, 2011 at 09:09:28AM -0500, Magnus Hagander wrote:
>> On Sun, Jan 9, 2011 at 23:33, Cédric Villemain
>> wrote:
>> > 2011/1/7 Magnus Hagander :
>> >> On Fri, Jan 7, 2011 at 01:47, Cédric Villemain
>> >> wrote:
>> >>> 2011/1/5 Magnus Hagander :
>> On W
Joel Jacobson writes:
> Has anyone written a in-depth description on how to traverse the pg_depend
> tree?
Try reading the code in src/backend/catalog/dependency.c.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Florian Pflug writes:
> @OP: Wouldn't it be sufficient to provide such a thing for structure
> objects that people are actually going to modify on a regular basis?
Yeah, I still don't see the need to argue over whether the elements of
an operator class are uniquely identifiable or not.
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>> I tried wiring it into the build system, but failed, I can't figure out
>> which Makefiles should be updated in order to make errcodes.h and
>> plerrcodes.h generated headers. Could someone help with that?
> Trying a bit harder to make src/include/utils
Peter Eisentraut writes:
> On tis, 2011-01-11 at 12:30 +0900, Itagaki Takahiro wrote:
>> If we won't to add accept integers for money, we should fix the docs.
>> | integer and floating-point string literals
>> |~~~
>> Will it get better?
> I think adding a
Robert Haas writes:
> On Mon, Jan 10, 2011 at 8:56 PM, Tom Lane wrote:
>> Not really. AFAIR, there are two cases that exist in practice,
>> depending on which AM you're talking about:
>>
>> 1. The recorded types match the input types of the operator/function
>> (btree & hash).
>> 2. The recor
Peter Eisentraut writes:
> Making it work for language SQL would be nice, though.
Please consider a new DEPENDENCY_XXX constant for that though, because
otherwise I think it could cause problems in the extension's dependency
tracking. Even with a new DEPENDENCY_FUNCALL or other constant, the
ext
On Mon, Jan 10, 2011 at 09:09:28AM -0500, Magnus Hagander wrote:
> On Sun, Jan 9, 2011 at 23:33, Cédric Villemain
> wrote:
> > 2011/1/7 Magnus Hagander :
> >> On Fri, Jan 7, 2011 at 01:47, Cédric Villemain
> >> wrote:
> >>> 2011/1/5 Magnus Hagander :
> On Wed, Jan 5, 2011 at 22:58, Dimitri F
Has anyone written a in-depth description on how to traverse the pg_depend tree?
The 'a' and 'i' deptype really makes it hard to figure out the
dependency order, a topological sort does not work.
My latest attempt involved trying to group by all objects connected to
each other via deptype 'a' or '
Excerpts from Maciej Sakrejda's message of mar ene 11 03:28:13 -0300 2011:
> Tried asking this in pgsql-general but I got no response, so I thought
> I'd give hackers a shot:
>
> postgres=# select (((1.7976931348623157081e+308)::double
> precision)::text)::double precision;
> ERROR: "1.7976931348
On Jan11, 2011, at 16:12 , Tom Lane wrote:
> Joel Jacobson writes:
>> I instead propose we introduce a new function named
>> pg_get_object_unique_identifier( classid oid, objid oid, objsubid
>> integer ) returns text.
>
> Seems like concatenating the OIDs would accomplish that. (If you
> think n
On 01/11/2011 04:53 PM, Kevin Grittner wrote:
Thanks much for testing. You're managing to exercise some code
paths I didn't think to test, which is great! I guess this is the
up side of having posted yesterday. :-)
Glad that I can help. This feature is something that is very important
to our
Robert Haas writes:
> On Tue, Jan 11, 2011 at 4:46 AM, Tatsuo Ishii wrote:
>> For query based replication tools like pgpool-II (I don't know any
>> other tools, for example Postgres XC falls in this category or
>> not...), we need to be able to lock sequences. Fortunately it is allowed to:
>>
>>
2011/1/11 Tom Lane :
> Seems like concatenating the OIDs would accomplish that. (If you
> think not, well, you still haven't explained what problem you're trying
> to solve...)
The can be different in two different databases sharing the same
original schema, but of two different versions.
In this
Excerpts from Robert Haas's message of mar ene 11 10:52:12 -0300 2011:
> Well, we shouldn't change them randomly or arbitrarily, but improving them is
> another thing altogether. I think the contention that any user or
> application anywhere is depending on the exact textual representation of a
Joel Jacobson writes:
> I instead propose we introduce a new function named
> pg_get_object_unique_identifier( classid oid, objid oid, objsubid
> integer ) returns text.
Seems like concatenating the OIDs would accomplish that. (If you
think not, well, you still haven't explained what problem you
On 28/12/10 12:25, Jan Urbański wrote:
> Here's the basic errcodes.txt file and three scripts to generate
> errcodes.h, plerrcodes.h and part of errcodes.sgml.
>
> I tried wiring it into the build system, but failed, I can't figure out
> which Makefiles should be updated in order to make errcodes.
Anssi Kääriäinen wrote:
> I think I found a problem. This is using SSI v8.
Thanks much for testing. You're managing to exercise some code
paths I didn't think to test, which is great! I guess this is the
up side of having posted yesterday. :-)
> So, something seems to be broken when using
Anssi Kääriäinen wrote:
> A speed test showing a significant drop in performance when using
SSI:
>
> hot2=> create table test_t2 as (select generate_series(0, 100));
> hot2=> \timing
> begin transaction isolation level repeatable read;
> Time: 0.185 ms
> hot2=> select count(*) from test_t2;
On Tue, 2011-01-11 at 07:14 -0500, Noah Misch wrote:
> On Tue, Jan 11, 2011 at 09:24:46AM +, Simon Riggs wrote:
> > I have a concern that by making the ALTER TABLE more complex that we
> > might not be able to easily tell if a rewrite happens, or not.
What about add EXPLAIN support to it, then
On 01/10/2011 06:03 PM, Kevin Grittner wrote:
Due to popular request (Hey, David's popular, right?), I'm posting a
patch for Serializable Snapshot Isolation (SSI), although I don't
yet have everything in it that I was planning on submitting before
the CF. I will probably be submitting another ve
On Jan 11, 2011, at 8:50 AM, Noah Misch wrote:
> Okay; I'll see what I can come up with. The other part I was going to try to
> finish before the last commitfest begins is avoiding unnecessary rebuilds of
> indexes involving changed columns. Is that more or less important than having
> an EXPLAI
On Jan 11, 2011, at 8:25 AM, Joel Jacobson wrote:
> 2011/1/11 Robert Haas :
>> I don't get it. If two different items that exist in the system out
>> of the box have the same description, it seems clear that relevant
>> piece of disambiguating information exists nowhere in the description
>> stri
On Tue, Jan 11, 2011 at 01:17:23PM +, Simon Riggs wrote:
> On Tue, 2011-01-11 at 08:06 -0500, Noah Misch wrote:
> > On Tue, Jan 11, 2011 at 12:37:28PM +, Simon Riggs wrote:
> > > Given your thoughts above, my preference would be for
> > > EXPLAIN ALTER TABLE to describe the actions that wi
2011/1/11 Robert Haas :
> I don't get it. If two different items that exist in the system out
> of the box have the same description, it seems clear that relevant
> piece of disambiguating information exists nowhere in the description
> string.
I guess it is a question of prioritization.
If backw
On Tue, 2011-01-11 at 08:06 -0500, Noah Misch wrote:
> On Tue, Jan 11, 2011 at 12:37:28PM +, Simon Riggs wrote:
> > On Tue, 2011-01-11 at 07:14 -0500, Noah Misch wrote:
> >
> > > These changes do make it harder to guess how much work the ALTER TABLE
> > > will do. Indeed, about 1/4 of my own g
On Tue, Jan 11, 2011 at 07:27:46AM -0500, Robert Haas wrote:
> On Tue, Jan 11, 2011 at 7:14 AM, Noah Misch wrote:
> > True. ?At least we could completely document the lock choices on the ALTER
> > TABLE
> > reference page. ?The no-rewrite cases are defined at arms length from ALTER
> > TABLE, and
1 - 100 of 135 matches
Mail list logo
