On 6 April 2012 07:21, Peter Eisentraut wrote:
> On lör, 2012-03-24 at 10:01 +, Gianni Ciolli wrote:
>> ON (DELETE | UPDATE) actions for EACH foreign keys
>> ==
>>
>> -- --- ---
>> | ON |
On Fri, Jun 15, 2012 at 10:19 AM, Bruce Momjian wrote:
> On Thu, Jun 14, 2012 at 02:43:04PM -0400, Tom Lane wrote:
>> Euler Taveira writes:
>> > On 14-06-2012 02:19, Tom Lane wrote:
>> >> ... I especially think that importing bzip2
>> >> is a pretty bad idea --- it's not only a new dependency, b
On 15.06.2012 06:19, Nikolas Everett wrote:
I've been a PostgreSQL user for years and have a feature that I'd like to
see implemented. I've started playing with the source and have a vague
implementation plan for it, but before I go blundering around I'd like to
run the idea by this list. So he
I've been a PostgreSQL user for years and have a feature that I'd like to
see implemented. I've started playing with the source and have a vague
implementation plan for it, but before I go blundering around I'd like to
run the idea by this list. So here it is:
I'd like to be able to save the cur
On Thu, Jun 14, 2012 at 6:30 PM, Peter Geoghegan wrote:
>> Here we know that it doesn't matter, so the application of Knuth's first law
>> of optimization is appropriate.
>
> I'm not advocating some Byzantine optimisation, or even something that
> could reasonably be described as an optimisation a
On Thu, Jun 14, 2012 at 02:43:04PM -0400, Tom Lane wrote:
> Euler Taveira writes:
> > On 14-06-2012 02:19, Tom Lane wrote:
> >> ... I especially think that importing bzip2
> >> is a pretty bad idea --- it's not only a new dependency, but bzip2's
> >> compression versus speed tradeoff is entirely
> I guess my first question is: why do we need this? There are lots of
> things in the TODO list that someone wanted once upon a time, but
> they're not all actually important. Do you have reason to believe
> that this one is? It's been six years since that email, so it's worth
> asking if this
On Thu, Jun 14, 2012 at 5:34 PM, Heikki Linnakangas
wrote:
> On 14.06.2012 18:01, Robert Haas wrote:
>> What I'm really looking for at this stage of the game is feedback on
>> the design decisions I made. The intention here is that it should be
>> possible to read old-format heaps and indexes tra
Here is my first patch for the transforms feature. This is a mechanism
to adapt data types to procedural languages. The previous proposal was
here: http://archives.postgresql.org/pgsql-hackers/2012-05/msg00728.php
At the surface, this contains:
- New catalog pg_transform
- CREATE/DROP TRANSFOR
On 14 June 2012 20:32, Robert Haas wrote:
> Yeah, but *it doesn't matter*. If you test this on strings that are
> long enough that they get pushed out to TOAST, you'll find that it
> doesn't measurably improve performance, because the overhead of
> detoasting so completely dominates any savings o
On Thursday, June 14, 2012 11:01:42 PM Heikki Linnakangas wrote:
> As I threatened earlier
> (http://archives.postgresql.org/message-id/4fd0b1ab.3090...@enterprisedb.co
> m), here are three patches that change the WAL format. The goal is to
> change the format so that when you're inserting a WAL re
On Thursday, June 14, 2012 11:01:42 PM Heikki Linnakangas wrote:
> As I threatened earlier
> (http://archives.postgresql.org/message-id/4fd0b1ab.3090...@enterprisedb.co
> m), here are three patches that change the WAL format. The goal is to
> change the format so that when you're inserting a WAL re
On Thursday, June 14, 2012 11:19:00 PM Heikki Linnakangas wrote:
> On 13.06.2012 14:28, Andres Freund wrote:
> > Features:
> > - streaming reading/writing
> > - filtering
> > - reassembly of records
> >
> > Reusing the ReadRecord infrastructure in situations where the code that
> > wants to do so
On Wed, Jan 11, 2012 at 8:48 PM, Robert Haas wrote:
> I've had cause, a few times this development cycle, to want to measure
> the amount of spinning on each lwlock in the system. To that end,
> I've found the attached patch useful. Note that if you don't define
> LWLOCK_STATS, this changes noth
On Thursday, June 14, 2012 11:19:00 PM Heikki Linnakangas wrote:
> On 13.06.2012 14:28, Andres Freund wrote:
> > Features:
> > - streaming reading/writing
> > - filtering
> > - reassembly of records
> >
> > Reusing the ReadRecord infrastructure in situations where the code that
> > wants to do so
On 14.06.2012 18:01, Robert Haas wrote:
What I'm really looking for at this stage of the game is feedback on
the design decisions I made. The intention here is that it should be
possible to read old-format heaps and indexes transparently, but that
when we create or rewrite a relation, we add a n
On 13.06.2012 14:28, Andres Freund wrote:
Features:
- streaming reading/writing
- filtering
- reassembly of records
Reusing the ReadRecord infrastructure in situations where the code that wants
to do so is not tightly integrated into xlog.c is rather hard and would require
changes to rather inte
On Thu, Jun 14, 2012 at 5:00 PM, Robert Haas wrote:
> On Thu, Jun 14, 2012 at 4:51 PM, Andres Freund wrote:
>> Lets sidetrack this till we have a tender agreement on how to handle DDL ;).
>> I
>> am aware of the issues with rollbacks, truncate et al...
>
> Agreed; I will write up my thoughts abo
On Thu, Jun 14, 2012 at 4:51 PM, Andres Freund wrote:
> Lets sidetrack this till we have a tender agreement on how to handle DDL ;). I
> am aware of the issues with rollbacks, truncate et al...
Agreed; I will write up my thoughts about DDL on the other thread. I
think that's a key thing we need
On Thursday, June 14, 2012 08:50:51 PM Robert Haas wrote:
> On Wed, Jun 13, 2012 at 7:28 AM, Andres Freund
wrote:
> > This patch is problematic because formally indexes used by syscaches
> > needs to be unique, this one is not though because of 0/InvalidOids
> > entries for nailed/shared catalog
Hi Robert,
Thanks for your answer.
On Thursday, June 14, 2012 06:17:26 PM Robert Haas wrote:
> On Wed, Jun 13, 2012 at 7:27 AM, Andres Freund
wrote:
> > === Design goals for logical replication === :
> > - in core
> > - fast
> > - async
> > - robust
> > - multi-master
> > - modular
> > - as uni
On Thu, Jun 14, 2012 at 02:38:02PM -0500, Merlin Moncure wrote:
> On Thu, Jun 14, 2012 at 1:43 PM, Tom Lane wrote:
> > So I've got very little patience with the idea of "let's put in some
> > hooks and then great things will happen". It would be far better all
> > around if we supported exactly o
On Thu, Jun 14, 2012 at 1:43 PM, Tom Lane wrote:
> So I've got very little patience with the idea of "let's put in some
> hooks and then great things will happen". It would be far better all
> around if we supported exactly one, well-chosen, method. But really
> I still don't see a reason not to
On Thu, Jun 14, 2012 at 3:20 PM, Robert Haas wrote:
> Also, you had
> the same primary content for both comments, and you incorrectly
> reversed the sense of the FreeFile() test.
>
I am known for my fat fingers :)
> Committed with those changes.
>
Thanks!
--
Gurjeet Singh
EnterpriseDB Corpor
On Thu, Jun 14, 2012 at 3:24 PM, Peter Geoghegan wrote:
> On 14 June 2012 19:28, Robert Haas wrote:
>> I thought that doubling repeatedly would be overly aggressive in terms
>> of memory usage. Blowing the buffers out to 8kB because we hit a
>> string that's a bit over 4kB isn't so bad, but blow
On 14 June 2012 19:28, Robert Haas wrote:
> I thought that doubling repeatedly would be overly aggressive in terms
> of memory usage. Blowing the buffers out to 8kB because we hit a
> string that's a bit over 4kB isn't so bad, but blowing them out to
> 256MB because we hit a string that's a bit o
On Thu, Jun 14, 2012 at 3:10 PM, Gurjeet Singh wrote:
>> Well, according to the comments for AllocateFile:
>>
>> * fd.c will automatically close all files opened with AllocateFile at
>> * transaction commit or abort; this prevents FD leakage if a routine
>> * that calls AllocateFile is terminat
On Tue, Jun 12, 2012 at 10:59 PM, Vlad Arkhipov wrote:
> Does it make sense to have a comment on function's arguments? Of course it
> is possible to include these comments in a function's comment, but may be
> better to have them in more formalized way like comments on columns of a
> table. IDEs m
On Thu, Jun 14, 2012 at 2:02 PM, Robert Haas wrote:
> On Thu, Jun 14, 2012 at 1:48 PM, Gurjeet Singh
> wrote:
> > On Thu, Jun 14, 2012 at 1:29 PM, Robert Haas
> wrote:
> >> Committed.
> >
> >
> > A minor gripe:
> >
> > + /*
> > + * Close the backup label file.
> > + */
> > + if
On Thu, Jun 14, 2012 at 11:39 AM, Amit Kapila wrote:
> I am planning to work on the below Todo list item for this CommitFest
> Allow WAL information to recover corrupted pg_controldata
> http://archives.postgresql.org/pgsql-patches/2006-06/msg00025.php
The deadline for patches for this CommitFest
On Wed, Jun 13, 2012 at 7:28 AM, Andres Freund wrote:
> This patch is problematic because formally indexes used by syscaches needs to
> be unique, this one is not though because of 0/InvalidOids entries for
> nailed/shared catalog entries. Those values aren't allowed to be queried
> though.
That
Euler Taveira writes:
> On 14-06-2012 02:19, Tom Lane wrote:
>> ... I especially think that importing bzip2
>> is a pretty bad idea --- it's not only a new dependency, but bzip2's
>> compression versus speed tradeoff is entirely inappropriate for this
>> use-case.
> I see, the idea is that bzip2
On Thu, Jun 14, 2012 at 2:05 PM, Fujii Masao wrote:
> On Fri, Jun 15, 2012 at 2:29 AM, Robert Haas wrote:
>> On Thu, Jun 14, 2012 at 6:06 AM, Gabriele Bartolini
>> wrote:
>>> thank you very much for your patience (and thank you Marco for supporting
>>> me). I apologise for the delay.
>>>
>>>
On Thu, Jun 14, 2012 at 2:10 PM, Peter Geoghegan wrote:
> Why have you made the reusable buffer managed by sortsupport
> TEXTBUFLEN-aligned? The existing rationale for that constant (whose
> value is 1024) does not seem to carry forward here:
>
> * This should be large enough that most strings wi
On Thu, Jun 14, 2012 at 1:56 PM, Peter Geoghegan wrote:
> On 14 June 2012 17:35, Robert Haas wrote:
>> The problem with pre-detoasting to save comparison cycles is that you
>> can now fit many, many fewer tuples in work_mem. There might be cases
>> where it wins (for example, because the entire
On 2 March 2012 20:45, Robert Haas wrote:
> I decided to investigate the possible virtues of allowing "text" to
> use the sortsupport infrastructure, since strings are something people
> often want to sort.
I should mention up-front that I agree with the idea that it is worth
optimising text sort
On Fri, Jun 15, 2012 at 2:29 AM, Robert Haas wrote:
> On Thu, Jun 14, 2012 at 6:06 AM, Gabriele Bartolini
> wrote:
>> thank you very much for your patience (and thank you Marco for supporting
>> me). I apologise for the delay.
>>
>> I have retested the updated patch and it works fine with m
On Thu, Jun 14, 2012 at 1:48 PM, Gurjeet Singh wrote:
> On Thu, Jun 14, 2012 at 1:29 PM, Robert Haas wrote:
>>
>> On Thu, Jun 14, 2012 at 6:06 AM, Gabriele Bartolini
>> wrote:
>> > thank you very much for your patience (and thank you Marco for
>> > supporting
>> > me). I apologise for the del
On 14 June 2012 17:35, Robert Haas wrote:
> The problem with pre-detoasting to save comparison cycles is that you
> can now fit many, many fewer tuples in work_mem. There might be cases
> where it wins (for example, because the entire data set fits even
> after decompressing everything) but in mo
On Thu, Jun 14, 2012 at 1:29 PM, Robert Haas wrote:
> On Thu, Jun 14, 2012 at 6:06 AM, Gabriele Bartolini
> wrote:
> >thank you very much for your patience (and thank you Marco for
> supporting
> > me). I apologise for the delay.
> >
> >I have retested the updated patch and it works fine
On Sun, Jan 8, 2012 at 3:48 PM, Peter Eisentraut wrote:
> psql tab completion currently only supports the form GRANT privilege ON
> something TO someone (and the analogous REVOKE), but not the form GRANT
> role TO someone. Here is a patch that attempts to implement the latter.
This seems to have
On Mon, Apr 23, 2012 at 9:42 AM, Krzysztof Nienartowicz
wrote:
> Hello,
> Sorry for re-posting - I initially posted this in pgsql.sql - probably
> this group is more appropriate.
>
> I have a bizzare problem that started to manifest itself after
> addition of field being the array of compound UDTs
On Thu, Jun 14, 2012 at 6:06 AM, Gabriele Bartolini
wrote:
> thank you very much for your patience (and thank you Marco for supporting
> me). I apologise for the delay.
>
> I have retested the updated patch and it works fine with me. It is "ready
> for committer" for me.
Committed.
--
Rob
On Thu, Jun 14, 2012 at 5:38 PM, Robert Haas wrote:
> On Thu, Jun 14, 2012 at 11:59 AM, Dave Page wrote:
>> On Thu, Jun 14, 2012 at 11:43 AM, Dave Page wrote:
>>>
>>> I'll have a play with it and see if a simple switch to NetworkService
>>> seems feasible.
>>
>> OK, I worked up a patch which use
On Thu, Jun 14, 2012 at 11:59 AM, Dave Page wrote:
> On Thu, Jun 14, 2012 at 11:43 AM, Dave Page wrote:
>>
>> I'll have a play with it and see if a simple switch to NetworkService
>> seems feasible.
>
> OK, I worked up a patch which uses "NT AUTHORITY\NetworkService" as
> the service account by d
On Thu, Jun 14, 2012 at 11:36 AM, Peter Geoghegan wrote:
> On 18 March 2012 15:08, Tom Lane wrote:
>> One other thing I've always wondered about in this connection is the
>> general performance of sorting toasted datums. Is it better to detoast
>> them in every comparison, or pre-detoast to save
On Wed, Jun 13, 2012 at 7:27 AM, Andres Freund wrote:
> === Design goals for logical replication === :
> - in core
> - fast
> - async
> - robust
> - multi-master
> - modular
> - as unintrusive as possible implementation wise
> - basis for other technologies (sharding, replication into other DBMSs,
On Thu, Jun 14, 2012 at 9:57 AM, Phil Sorber wrote:
> It doesn't sound like there is a lot of support for this idea, but I
> think it would be nice to get something like lz4
> (http://code.google.com/p/lz4/) or snappy
> (http://code.google.com/p/snappy/) support. Both are BSD-ish licensed.
> It co
On Thu, Jun 14, 2012 at 11:43 AM, Dave Page wrote:
>
> I'll have a play with it and see if a simple switch to NetworkService
> seems feasible.
OK, I worked up a patch which uses "NT AUTHORITY\NetworkService" as
the service account by default. This doesn't need a password, so
allows us to simply p
I am planning to work on the below Todo list item for this CommitFest
Allow WAL information to recover corrupted pg_controldata
http://archives.postgresql.org/pgsql-patches/2006-06/msg00025.php
I wanted to confirm my understanding about the work involved for this patch:
The existing patch
On 18 March 2012 15:08, Tom Lane wrote:
> One other thing I've always wondered about in this connection is the
> general performance of sorting toasted datums. Is it better to detoast
> them in every comparison, or pre-detoast to save comparison cycles at
> the cost of having to push much more da
On Thursday, June 14, 2012 04:04:22 PM Robert Haas wrote:
> On Thu, Jun 14, 2012 at 9:57 AM, Andres Freund
wrote:
> > On Thursday, June 14, 2012 03:50:28 PM Robert Haas wrote:
> >> On Wed, Jun 13, 2012 at 7:28 AM, Andres Freund
> >
> > wrote:
> >> > This is locally defined in lots of places and
On Thu, Jun 14, 2012 at 10:45 AM, Tom Lane wrote:
> Robert Haas writes:
>> Is RESOURCE_RELEASE_AFTER_LOCKS actually used for anything? Is it
>> just for extensions?
>
> I'm too lazy to go look, but it certainly ought to be in use.
> The idea is that that's the phase for post-lock-release cleanup
On Thu, Jun 14, 2012 at 10:14 AM, Florian Pflug wrote:
> On Jun14, 2012, at 15:28 , Euler Taveira wrote:
>> On 14-06-2012 02:19, Tom Lane wrote:
>>> I still think that pushing this off to openssl (not an ssh tunnel, but
>>> the underlying transport library) would be an adequate solution.
>>> If yo
Robert Haas writes:
> Is RESOURCE_RELEASE_AFTER_LOCKS actually used for anything? Is it
> just for extensions?
I'm too lazy to go look, but it certainly ought to be in use.
The idea is that that's the phase for post-lock-release cleanup,
and anything that can possibly be postponed till after rel
On Wed, Jun 13, 2012 at 3:20 PM, Dimitri Fontaine
wrote:
> Please let's apply that documentation patch to 9.2 too.
Agreed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
On Sun, Jun 10, 2012 at 5:37 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Jun 10, 2012 at 4:19 PM, Noah Misch wrote:
>>> Agreed. We now have $OLD_SUBJECT, but this is a win independently. I have
>>> reviewed the code that runs between the old and new call sites, and I did
>>> not
>>>
> That seems undesirable. I don't think this is important enough to be
worth reparsing > the connection string for.
The connect string should not be long, so parsing is not a big cost
performance wise.
I have currently modified the code for dblink in the patch I have uploaded
in CF.
However as p
On Jun14, 2012, at 15:28 , Euler Taveira wrote:
> On 14-06-2012 02:19, Tom Lane wrote:
>> I still think that pushing this off to openssl (not an ssh tunnel, but
>> the underlying transport library) would be an adequate solution.
>> If you are shoving data over a connection that is long enough to ne
On Thu, Jun 14, 2012 at 9:57 AM, Andres Freund wrote:
> On Thursday, June 14, 2012 03:50:28 PM Robert Haas wrote:
>> On Wed, Jun 13, 2012 at 7:28 AM, Andres Freund
> wrote:
>> > This is locally defined in lots of places and would get introduced
>> > frequently in the next commits. It is expected
On Thu, Jun 7, 2012 at 8:44 AM, Robert Haas wrote:
> On Wed, Jun 6, 2012 at 5:21 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> rhaas=# create table pg_catalog.tom (a int);
>>> ERROR: permission denied to create "pg_catalog.tom"
>>
>>> The offending error check is in heap_create(), and based on
On Thursday, June 14, 2012 03:50:28 PM Robert Haas wrote:
> On Wed, Jun 13, 2012 at 7:28 AM, Andres Freund
wrote:
> > This is locally defined in lots of places and would get introduced
> > frequently in the next commits. It is expected that this can be defined
> > in a header-only manner as soon
On Wed, Jun 13, 2012 at 12:07 AM, Amit Kapila wrote:
>
>> Why not 'dblink'?
>
> We can do for dblink as well. I just wanted to check before implementing in
> dblink.
>
> I have checked the dblink_connect() function, it receives the connect string
> and used in most cases that string to
> call libp
On Tue, Jun 12, 2012 at 03:13:26PM -0400, Tom Lane wrote:
> Even if I accepted that premise, this patch is a pretty bad
> implementation of it, because it restricts cases that there is no
> reason to think are unsafe.
>
> A less bizarre and considerably more future-proof restriction, IMO,
> would
On Wed, Jun 13, 2012 at 7:28 AM, Andres Freund wrote:
> This is locally defined in lots of places and would get introduced frequently
> in the next commits. It is expected that this can be defined in a header-only
> manner as soon as the XLogInsert scalability groundwork from Heikki gets in.
This
On Sun, Jun 3, 2012 at 5:30 AM, Alastair Turner wrote:
> A one-line change adds the SSL info on its own line like
>
> --
> You are connected to database "scratch" as user "scratch" on host
> "127.0.0.1" at port "5432".
> SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)
> --
>
> Does
On 14-06-2012 02:19, Tom Lane wrote:
> I still think that pushing this off to openssl (not an ssh tunnel, but
> the underlying transport library) would be an adequate solution.
> If you are shoving data over a connection that is long enough to need
> compression, the odds that every bit of it is tr
On Thu, Jun 14, 2012 at 1:04 AM, Tom Lane wrote:
> Robert Haas writes:
>> Maybe:
>
>> listen_addresses = { host | host:port | * | *:port } [, ...]
>> unix_socket_directory = { directory | directory:port ] [,...]
>
>> ...except that colon is a valid character in a directory name. Not
>> sure what
Il giorno mer, 13/06/2012 alle 18.07 -0400, Noah Misch ha scritto:
> On Wed, Jun 13, 2012 at 10:12:18PM +0200, Gabriele Bartolini wrote:
> > Our goal is to work on this patch from the next commit fest.
> >
> > What we are about to do for this commit fest is to split the previous
> > patch and sen
On Thu, Jun 14, 2012 at 12:55 AM, Craig Ringer
wrote:
> On 06/13/2012 05:14 PM, Dave Page wrote:
>>
>> On Wed, Jun 13, 2012 at 2:18 AM, Craig Ringer
>> wrote:
>>>
>>> On 06/12/2012 08:08 PM, Dave Page wrote:
Some background: By default the installer will use 'postgres' for both
the
Hi,
following Gabriele's email regarding our previous patch on "Foreign
Key Arrays"[1], I am sending a subset of that patch which includes only
two array functions which will be needed in that patch: array_remove
(limited to single-dimensional arrays) and array_replace.
The patch includes cha
Hello Gilles,
thank you very much for your patience (and thank you Marco for
supporting me). I apologise for the delay.
I have retested the updated patch and it works fine with me. It is
"ready for committer" for me.
Cheers,
Gabriele
Il 14/06/12 11:36, Marco Nenciarini ha scritto:
Hi Gilles,
unfortunately Gabriele has been very busy recently and he asked me to
check again the status of this patch for this commit fest. In order to
speed up the application of the patch, I am sending an updated version
which correctly compiles with current head. Gabriele will then proceed
with
Tom Lane writes:
> Well, TBH I didn't think that concept was a useful solution for this at
> all. I can't imagine that we would define "features" at a sufficiently
> fine granularity, or with enough advance foresight, to solve the sort of
> problem that's being faced here. How would you deal wit
Euler Taveira wrote:
> There was already some discussion about compressing libpq data
[1][2][3].
> Recently, I faced a scenario that would become less problematic if we
have had
> compression support. The scenario is frequent data load (aka COPY)
over
> slow/unstable links. It should be executed in
> yeah -- but you still have to call:
> *) TransactionIdIsCurrentTransactionId(), which adds a couple of tests
> (and a bsearch in the presence of subtransactions)
> *) TransactionIdIsInProgress() which adds a few tests and a out of
line call in the typical case
> *) TransactionIdDidCommit() whi
76 matches
Mail list logo
