Thanks!
Best regards,
Etsuro Fujita
> -Original Message-
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Sent: Thursday, October 11, 2012 2:58 AM
> To: Etsuro Fujita
> Cc: 'PostgreSQL-development'
> Subject: Re: [HACKERS] Minor document updates
>
> "Etsuro Fujita" writes:
> >> I think we
On Thursday, October 11, 2012 04:49:20 AM Andres Freund wrote:
> On Thursday, October 11, 2012 04:31:21 AM Tom Lane wrote:
> > Greg Stark writes:
> > > On Thu, Oct 11, 2012 at 2:40 AM, Tom Lane wrote:
> > >> Isn't there an even more serious problem, namely that this assumes
> > >> all transaction
On Thursday, October 11, 2012 04:31:21 AM Tom Lane wrote:
> Greg Stark writes:
> > On Thu, Oct 11, 2012 at 2:40 AM, Tom Lane wrote:
> >> Isn't there an even more serious problem, namely that this assumes
> >> *all* transactions are serializable? What happens when they aren't?
> >> Or even just t
On Thursday, October 11, 2012 04:16:39 AM Greg Stark wrote:
> On Thu, Oct 11, 2012 at 2:40 AM, Tom Lane wrote:
> >> I think I've mentioned it before, but in the interest of not being
> >> seen to critique the bikeshed only after it's been painted: this
> >> design gives up something very important
On Thursday, October 11, 2012 03:10:48 AM Robert Haas wrote:
> On Wed, Oct 10, 2012 at 7:02 PM, Peter Geoghegan
wrote:
> > The purpose of ApplyCache/transaction reassembly is to reassemble
> > interlaced records, and organise them by XID, so that the consumer
> > client code sees only streams (we
Bruce Momjian writes:
> On Mon, Oct 8, 2012 at 12:12:54PM -0400, Tom Lane wrote:
>> I'm inclined to think we should make zic.c bail out on write errors.
>> Otherwise, "make install" could fail to notice an out-of-disk-space
>> situation during install.
> My warnings have disappeared now that _FO
Greg Stark writes:
> On Thu, Oct 11, 2012 at 2:40 AM, Tom Lane wrote:
>> Isn't there an even more serious problem, namely that this assumes
>> *all* transactions are serializable? What happens when they aren't?
>> Or even just that the effective commit order is not XID order?
> I don't think it
On Thu, Oct 11, 2012 at 03:16:39AM +0100, Greg Stark wrote:
> On Thu, Oct 11, 2012 at 2:40 AM, Tom Lane wrote:
> >> I think I've mentioned it before, but in the interest of not being
> >> seen to critique the bikeshed only after it's been painted: this
> >> design gives up something very important
Hi,
First of: Awesome review.
On Thursday, October 11, 2012 01:02:26 AM Peter Geoghegan wrote:
> What follows is an initial overview of the patch (or at least my
> understanding of the patch, which you may need to correct), and some
> points of concern.
>
> > * applycache module which reassemble
On Thu, Oct 11, 2012 at 2:40 AM, Tom Lane wrote:
>> I think I've mentioned it before, but in the interest of not being
>> seen to critique the bikeshed only after it's been painted: this
>> design gives up something very important that exists in our current
>> built-in replication solution, namely
On Mon, Oct 8, 2012 at 12:12:54PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > I am seeing the following warnings in git head from zic.c:
> > zic.c:1505: warning: ignoring return value of ‘fwrite’, declared with
> > attribute warn_unused_result
>
> Yeah, this is probably a consequence
On Wed, Oct 10, 2012 at 10:01:30PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Wed, Oct 10, 2012 at 09:29:16PM -0400, Tom Lane wrote:
> >> In what way would somebody be relying on the 9.2 behavior?
>
> > I don't know. I am just asking if an application could be relying on
> > the 9.2 b
Bruce Momjian writes:
> On Wed, Oct 10, 2012 at 09:29:16PM -0400, Tom Lane wrote:
>> In what way would somebody be relying on the 9.2 behavior?
> I don't know. I am just asking if an application could be relying on
> the 9.2 behavior.
I don't think so. Robert suggested in the original discussi
On Wed, 2012-10-10 at 11:29 +0100, Peter Geoghegan wrote:
> On 8 October 2012 14:39, Peter Geoghegan wrote:
> > Small patch that hopefully fixes everything for everyone is attached.
>
> Will someone take a look at this, please?
I've removed it. It had too many problems.
--
Sent via pgsql-ha
Robert Haas writes:
> On Wed, Oct 10, 2012 at 7:02 PM, Peter Geoghegan
> wrote:
>> The purpose of ApplyCache/transaction reassembly is to reassemble
>> interlaced records, and organise them by XID, so that the consumer
>> client code sees only streams (well, lists) of records split by XID.
> I
Compiler warning needs to be fixed:
rewriteHandler.c: In function 'RewriteQuery':
rewriteHandler.c:2153:29: error: 'view_rte' may be used uninitialized in this
function [-Werror=maybe-uninitialized]
rewriteHandler.c:2015:17: note: 'view_rte' was declared here
Duplicate OIDs need to be adjusted:
On Wed, Oct 10, 2012 at 09:29:16PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Wed, Oct 10, 2012 at 08:43:34PM -0400, Tom Lane wrote:
> >> I think we have to revert and go back to the drawing board on this.
>
> > Is reverting going to adversely affect users who are already using the
> >
Bruce Momjian writes:
> On Wed, Oct 10, 2012 at 08:43:34PM -0400, Tom Lane wrote:
>> I think we have to revert and go back to the drawing board on this.
> Is reverting going to adversely affect users who are already using the
> 9.2 behavior?
In what way would somebody be relying on the 9.2 behav
On Wed, Oct 10, 2012 at 09:10:48PM -0400, Robert Haas wrote:
> > You consider this to be a throw-away function that won't ever be
> > committed. However, I strongly feel that you should move it into
> > /contrib, so that it can serve as a sort of reference implementation
> > for authors of decoder
On Wed, Oct 10, 2012 at 08:43:34PM -0400, Tom Lane wrote:
> > It seems to me that the
> > root of the issue here is that people is not that people expect two
> > snapshots -- indeed, a number of people strongly supported getting rid
> > of that behavior at the time -- but rather that they expect th
On Wed, Oct 10, 2012 at 7:02 PM, Peter Geoghegan wrote:
> The purpose of ApplyCache/transaction reassembly is to reassemble
> interlaced records, and organise them by XID, so that the consumer
> client code sees only streams (well, lists) of records split by XID.
I think I've mentioned it before,
Robert Haas writes:
> On Wed, Oct 10, 2012 at 7:10 PM, Tom Lane wrote:
>> Yeah, I think that last is the key point: this patch was sold on the
>> grounds that it wouldn't cause any interesting user-visible behavioral
>> change, but your example blows that claim into tiny little pieces.
>>
>> I'm
On Wed, Oct 10, 2012 at 7:10 PM, Tom Lane wrote:
> Yeah, I think that last is the key point: this patch was sold on the
> grounds that it wouldn't cause any interesting user-visible behavioral
> change, but your example blows that claim into tiny little pieces.
>
> I'm inclined to think we need to
On Thu, Oct 11, 2012 at 4:58 AM, Boszormenyi Zoltan wrote:
> I was able to test it on OSX and I found my bug. Attached is the new code.
> The problem was in conninfo_init(), the last entry in the filtered list was
> not initialized to 0. It seems that for some reason, my Linux machine gave
> me pr
On Thu, Oct 11, 2012 at 3:36 AM, Boszormenyi Zoltan wrote:
> 2012-10-10 18:23 keltezéssel, Fujii Masao írta:
>> When tar output format is specified together with -R option, recovery.conf
>> is
>> not included in base.tar. I think it should.
>
>
> Why? This patch only promises to write the recovery
On Mon, Oct 8, 2012 at 09:03:37PM -0400, Bruce Momjian wrote:
> On Mon, Oct 8, 2012 at 04:33:29PM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > A while ago I noticed that in some places we strdup/pg_strdup() optarg
> > > strings from getopt(), and in some places we don't.
> >
> > > If
On Thu, Oct 11, 2012 at 01:34:58AM +0200, anara...@anarazel.de wrote:
>
>
> Bruce Momjian schrieb:
>
> >On Thu, Oct 11, 2012 at 12:02:26AM +0100, Peter Geoghegan wrote:
> >> On 15 September 2012 01:39, Andres Freund
> >wrote:
> >> > (0008-Introduce-wal-decoding-via-catalog-timetravel.patch)
>
Bruce Momjian schrieb:
>On Thu, Oct 11, 2012 at 12:02:26AM +0100, Peter Geoghegan wrote:
>> On 15 September 2012 01:39, Andres Freund
>wrote:
>> > (0008-Introduce-wal-decoding-via-catalog-timetravel.patch)
>>
>> This patch is the 8th of 8 in a patch series that covers different
>> aspects of
> Does this design allow replication/communcation between clusters running
> different major versions of Postgres?
Just catching up on your email, hmmm?
Yes, that's part of the design 2Q presented.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing
On Thu, Oct 11, 2012 at 12:02:26AM +0100, Peter Geoghegan wrote:
> On 15 September 2012 01:39, Andres Freund wrote:
> > (0008-Introduce-wal-decoding-via-catalog-timetravel.patch)
>
> This patch is the 8th of 8 in a patch series that covers different
> aspects of the bi-directional replication fea
Tomas Vondra writes:
> On 10.10.2012 22:43, Thom Brown wrote:
>> On 10 October 2012 21:21, Tomas Vondra wrote:
>>> A: BEGIN;
>>> A: LOCK x IN ACCESS EXCLUSIVE MODE;
>>> A: INSERT INTO x VALUES (100);
>>> B: SELECT * FROM x;
>>> A: COMMIT;
>>>
>>> Now on 9.1, B receives the value "100" while on 9
On 15 September 2012 01:39, Andres Freund wrote:
> (0008-Introduce-wal-decoding-via-catalog-timetravel.patch)
This patch is the 8th of 8 in a patch series that covers different
aspects of the bi-directional replication feature planned for
PostgreSQL 9.3. For those that are unfamiliar with the BDR
On 10.10.2012 23:57, Andres Freund wrote:
> On Wednesday, October 10, 2012 11:45:41 PM Tomas Vondra wrote:
>> Oh yeah, right. Any lock would work - advisory or not.
> Well, it needs to be a lock youre conflicting on, not any lock ;)
Oh, yeah, right. I was thinking about acquiring the same advisory
On Wednesday, October 10, 2012 11:45:41 PM Tomas Vondra wrote:
> On 10.10.2012 23:31, Andres Freund wrote:
> > On Wednesday, October 10, 2012 11:23:10 PM Tomas Vondra wrote:
> >> On 10.10.2012 23:05, Andres Freund wrote:
> >>> On Wednesday, October 10, 2012 10:43:57 PM Thom Brown wrote:
> On 1
On 10.10.2012 23:31, Andres Freund wrote:
> On Wednesday, October 10, 2012 11:23:10 PM Tomas Vondra wrote:
>> On 10.10.2012 23:05, Andres Freund wrote:
>>> On Wednesday, October 10, 2012 10:43:57 PM Thom Brown wrote:
On 10 October 2012 21:21, Tomas Vondra wrote:
> Hi,
>
> I've jus
On Wednesday, October 10, 2012 11:23:10 PM Tomas Vondra wrote:
> On 10.10.2012 23:05, Andres Freund wrote:
> > On Wednesday, October 10, 2012 10:43:57 PM Thom Brown wrote:
> >> On 10 October 2012 21:21, Tomas Vondra wrote:
> >>> Hi,
> >>>
> >>> I've just noticed a change of LOCK command behavior
On 10.10.2012 23:05, Andres Freund wrote:
> On Wednesday, October 10, 2012 10:43:57 PM Thom Brown wrote:
>> On 10 October 2012 21:21, Tomas Vondra wrote:
>>> Hi,
>>>
>>> I've just noticed a change of LOCK command behavior between 9.1 and 9.2,
>>> and I'm not sure whether this is expected or not.
>
Hi Joachim,
Attached, please find new patch. Test unchanged.
Best regards,
Joel
> Patch looks good, all concerns that had been raised previously have
> been addressed in this version of the patch.
>
> The only thing that IMO needs to change is a stylistic issue:
>
> if (fout->remoteVersion >= 8
On Wed, Oct 10, 2012 at 01:54:49PM -0400, Bruce Momjian wrote:
> On Wed, Oct 10, 2012 at 10:35:06AM -0600, Chris Ernst wrote:
> > On 10/10/2012 09:56 AM, Bruce Momjian wrote:
> > > Can you show me what is in the PG_VERSION file in the old cluster? It
> > > should be "9.1".
> >
> > Hi Bruce,
> >
On Wednesday, October 10, 2012 10:43:57 PM Thom Brown wrote:
> On 10 October 2012 21:21, Tomas Vondra wrote:
> > Hi,
> >
> > I've just noticed a change of LOCK command behavior between 9.1 and 9.2,
> > and I'm not sure whether this is expected or not.
> >
> > Let's use a very simple table
> >
>
Shigeru HANADA writes:
> [ dblink_fdw_validator.v3.patch ]
I've committed the dblink portion of this with some mostly-cosmetic
adjustments. We still need a plan for getting to a point where it's
safe to remove postgresql_fdw_validator.
regards, tom lane
--
Sent via pg
On 10.10.2012 22:43, Thom Brown wrote:
> On 10 October 2012 21:21, Tomas Vondra wrote:
>> Example:
>>
>> A: BEGIN;
>> A: LOCK x IN ACCESS EXCLUSIVE MODE;
>> A: INSERT INTO x VALUES (100);
>> B: SELECT * FROM x;
>> A: COMMIT;
>>
>> Now on 9.1, B receives the value "100" while on 9.2 it gets no rows
On 10.10.2012 22:42, Andres Freund wrote:
> On Wednesday, October 10, 2012 10:21:51 PM Tomas Vondra wrote:
>> Hi,
>>
>> I've just noticed a change of LOCK command behavior between 9.1 and 9.2,
>> and I'm not sure whether this is expected or not.
>>
>> Let's use a very simple table
>>
>> CREATE TA
On 10 October 2012 21:21, Tomas Vondra wrote:
> Hi,
>
> I've just noticed a change of LOCK command behavior between 9.1 and 9.2,
> and I'm not sure whether this is expected or not.
>
> Let's use a very simple table
>
> CREATE TABLE x (id INT);
>
> Say there are two sessions - A and B, where A pe
On Wednesday, October 10, 2012 10:21:51 PM Tomas Vondra wrote:
> Hi,
>
> I've just noticed a change of LOCK command behavior between 9.1 and 9.2,
> and I'm not sure whether this is expected or not.
>
> Let's use a very simple table
>
> CREATE TABLE x (id INT);
>
> Say there are two sessions -
On 10.10.2012 22:37, k...@rice.edu wrote:
> On Wed, Oct 10, 2012 at 10:21:51PM +0200, Tomas Vondra wrote:
>> Example:
>>
>> A: BEGIN;
>> A: LOCK x IN ACCESS EXCLUSIVE MODE;
>> A: INSERT INTO x VALUES (100);
>> B: SELECT * FROM x;
>> A: COMMIT;
>>
>> Now on 9.1, B receives the value "100" while on 9
On Wed, Oct 10, 2012 at 10:21:51PM +0200, Tomas Vondra wrote:
> Hi,
>
> I've just noticed a change of LOCK command behavior between 9.1 and 9.2,
> and I'm not sure whether this is expected or not.
>
> Let's use a very simple table
>
> CREATE TABLE x (id INT);
>
> Say there are two sessions -
Shigeru HANADA writes:
> (2012/10/09 0:30), Kohei KaiGai wrote:
>> If it is also OK for you, I'd like to take over this patch to comitter.
>> This patch is prerequisite of postgresql_fdw, so I hope this patch
>> getting merged soon.
> Please go ahead. :-)
While reviewing this patch, I realized t
On 10.10.2012, at 20:26, Tom Lane wrote:
> Daniel Frey writes:
>> INSERT INTO dummy VALUES ( '0X1P-1022' );
>
>> this value itself is the problem. If I use pg_dump / pg_restore, the restore
>> fails with:
>
>> COPY failed for table "dummy": ERROR: "2.22507385850720138e-308" is out of
>> ra
Hi,
I've just noticed a change of LOCK command behavior between 9.1 and 9.2,
and I'm not sure whether this is expected or not.
Let's use a very simple table
CREATE TABLE x (id INT);
Say there are two sessions - A and B, where A performs some operations
on "x" and needs to protect them with an
2012-10-10 20:36 keltezéssel, Boszormenyi Zoltan írta:
2012-10-10 18:23 keltezéssel, Fujii Masao írta:
On Wed, Oct 10, 2012 at 10:12 PM, Boszormenyi Zoltan wrote:
Hi,
thanks for the new review.
2012-10-10 08:58 keltezéssel, Amit Kapila írta:
On Thursday, October 04, 2012 9:50 PM Boszormenyi
A very timely answer, and we'd debating moving to 9.2 at the same time but
decided on staying on the 8.4 line (latest patch level though). After we do
this we should be able to do a regular, normal pg_dump (not excluding anything)
to get from 8.4 -> 9.2 in a few weeks from now.
Thanks so much T
>> Assuming that's how 9.2 ships, we might as well wait to see if there
>> are any real complaints from the field before we decide whether any
>> changing is needed.
So, here's a complaint: 9.2 is breaking our code for checking table sizes:
postgres=# select pg_size_pretty(100);
ERROR: function
I wrote:
> Alvaro Herrera writes:
>> * Move postgresql_fdw_validator into dblink
> I'm not sure if the validator change is noncontroversial or not ---
> I seem to recall that Peter and I had different opinions about how to do
> that.
On rechecking the archives, it looks like Peter now agrees wit
2012-10-10 18:23 keltezéssel, Fujii Masao írta:
On Wed, Oct 10, 2012 at 10:12 PM, Boszormenyi Zoltan wrote:
Hi,
thanks for the new review.
2012-10-10 08:58 keltezéssel, Amit Kapila írta:
On Thursday, October 04, 2012 9:50 PM Boszormenyi Zoltan
2012-10-04 16:43 keltezéssel, Tom Lane írta:
Daniel Frey writes:
> INSERT INTO dummy VALUES ( '0X1P-1022' );
> this value itself is the problem. If I use pg_dump / pg_restore, the restore
> fails with:
> COPY failed for table "dummy": ERROR: "2.22507385850720138e-308" is out of
> range for type double precision
> This behavior migh
"Etsuro Fujita" writes:
>> I think we need to update a document on parameterized path in
>> doc/src/sgml/fdwhandler.sgml. Please find attached a patch.
Yeah, that text is obsolete --- I wonder how I missed it when I was
getting rid of the old param_clauses field? Anyway, updated, thanks
for the
Hi,
this is the follow-up to a recent IRC discussion. The topic at hand is floating
point values and I think there is one problem which might be solvable only with
a new feature. First, the problem:
I created a table
CREATE TABLE dummy ( v DOUBLE PRECISION );
so far, so good. Now, I would l
On Wed, Oct 10, 2012 at 6:11 PM, Greg Sabino Mullane wrote:
> Jim Nasby pointed out:
>
>> It'd be useful to us to have a utility that could cleanly validate
>> the server was up and communicating, without having to actually login.
>
> Well sure, but wouldn't it be even more useful to validate at t
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Jim Nasby pointed out:
> It'd be useful to us to have a utility that could cleanly validate
> the server was up and communicating, without having to actually login.
Well sure, but wouldn't it be even more useful to validate at the
same time
2012/10/10 Alvaro Herrera :
> Kohei KaiGai wrote:
>> 2012/9/5 Andrew Dunstan :
>
>> > Looking at SEPgsql testing is on my long TODO list. I'll have to set up a
>> > separate VM for it, as I don't habitually run SELinux.
>> >
>> If you are available to provide a VM environment for sepgsql, let me he
On 10/9/12 1:35 PM, Peter Eisentraut wrote:
> On 10/9/12 5:09 AM, Simon Riggs wrote:
>> Anyone want to check for any other missing IF EXISTS capability in other DDL?
>
> TRUNCATE is not really DDL. If we allow TRUNCATE IF EXISTS, what is
> stopping someone from requesting DELETE IF EXISTS or INSE
On 10/10/2012 04:34 PM, Tom Lane wrote:
Hannu Krosing writes:
One way would be to check that we are in an any --> cstring
function - perhaps just by setting some static flag et entry and resetting
it at exit - and pass the original byte representation as "bytes" (or
string for py2.x)
Totally a
On 04.10.2012 13:12, Amit kapila wrote:
Following changes are done to support replication timeout in sender as well as
receiver:
1. One new configuration parameter wal_receiver_timeout is added to detect
timeout at receiver task.
2. Existing parameter replication_timeout is renamed to wal_send
On Wed, Oct 10, 2012 at 10:12 PM, Boszormenyi Zoltan wrote:
> Hi,
>
> thanks for the new review.
>
> 2012-10-10 08:58 keltezéssel, Amit Kapila írta:
>>
>> On Thursday, October 04, 2012 9:50 PM Boszormenyi Zoltan
>>>
>>> 2012-10-04 16:43 keltezéssel, Tom Lane írta:
>>>
Boszormenyi Zoltan writ
Kohei KaiGai wrote:
> 2012/10/10 Alvaro Herrera :
> > Kohei KaiGai wrote:
> >> 2012/9/5 Andrew Dunstan :
> >
> >> > Looking at SEPgsql testing is on my long TODO list. I'll have to set up a
> >> > separate VM for it, as I don't habitually run SELinux.
> >> >
> >> If you are available to provide a V
Tom Lane wrote:
> Alvaro Herrera writes:
> > The commitfest currently in progress seems to have ground to a halt.
>
> Indeed :-(. I plead guilty as much as anybody else to not making it
> a high priority. But do we even have anyone acting as commitfest
> manager? Periodic nagging seems to be n
Kohei KaiGai escribió:
> The attached patch adds argument of OAT_POST_CREATE hook;
> to inform extensions type of the context of this object creation. It allows
> extensions to know whether the new object is indirectly created apart
> from user's operations, or not.
Can we add Assert(!is_internal)
On 24 September 2012 12:10, Amit Kapila wrote:
> On Sunday, September 23, 2012 12:33 AM Dean Rasheed wrote:
>> On 18 September 2012 14:23, Amit kapila wrote:
>> > Please find the review of the patch.
>> >
>>
>> Thanks for the review. Attached is an updated patch, and I've include
>> some respon
On Tuesday, October 09, 2012 7:38 PM Heikki Linnakangas wrote:
> On 09.10.2012 16:42, Amit Kapila wrote:
> > I have observed that currently during recovery, while it applies the
> WAL
> > records even if it detects that there is a corrupt record
> >
> > by crc validation, it proceeds.
> >
> > Basic
Alvaro Herrera writes:
> The commitfest currently in progress seems to have ground to a halt.
Indeed :-(. I plead guilty as much as anybody else to not making it
a high priority. But do we even have anyone acting as commitfest
manager? Periodic nagging seems to be necessary to move things forw
On Wed, Oct 10, 2012 at 3:32 AM, Simon Riggs wrote:
> On 10 October 2012 02:10, Robert Haas wrote:
>> On Tue, Oct 9, 2012 at 4:18 PM, Josh Berkus wrote:
>>> The second is for making deployment scripts idempotent. For example,
>>> say you have script A which creates table "josh", and script B wh
Kohei KaiGai wrote:
> 2012/9/5 Andrew Dunstan :
> > Looking at SEPgsql testing is on my long TODO list. I'll have to set up a
> > separate VM for it, as I don't habitually run SELinux.
> >
> If you are available to provide a VM environment for sepgsql, let me help
> set up its build and regression
Scott Corscadden writes:
> ** MY QUESTION ** - Will pg_largeobject automatically choose new OIDs that
> don't conflict, if I've added lo's this way, by direct COPY?
In 8.4, yes. In later versions, you'd need to do something about
creating corresponding rows in pg_largeobject_metadata.
In gener
Hannu Krosing writes:
> One way would be to check that we are in an any --> cstring
> function - perhaps just by setting some static flag et entry and resetting
> it at exit - and pass the original byte representation as "bytes" (or
> string for py2.x)
Totally aside from the ugliness of driving
People,
The commitfest currently in progress seems to have ground to a halt. We
really need to get things moving, because we're three weeks onto it and
there is a large number of patches still outstanding.
Some numbers: we got 65 patches this time, of which we rejected 4 and
returned 3 with feed
I'm pruning an 8.4 database that was using a *lot* of space in pg_largeobject
(400GB according to my size query). What I've done seems to work, but I don't
know if there's a time-bomb waiting for me, so I have to ask you who've
implemented this part. Steps:
1) On new.better.server.com:
On 10/10/2012 03:46 PM, Tom Lane wrote:
Hannu Krosing writes:
On 10/10/2012 02:58 PM, Tom Lane wrote:
It's hard for me to see how you'd make the above work without
circularity, ie the PL manager would end up recursively calling itself
trying to construct or deconstruct the value.
Again, could
On 10 October 2012 15:26, Amit Kapila wrote:
> On Tuesday, October 09, 2012 10:32 PM Heikki Linnakangas wrote:
>> On 06.10.2012 15:58, Amit Kapila wrote:
>> > One more test seems to be failed. Apart from this, other tests are
>> passed.
>> >
> It seems there is one more defect, please check the s
On 10.10.2012 17:37, Amit Kapila wrote:
On Tuesday, October 09, 2012 7:38 PM Heikki Linnakangas wrote:
We rely on the CRC to detect end of WAL during recovery. If the
system crashes while the WAL is being flushed to disk, it's normal that
there's a corrupt (ie. partially written) record at the e
Hannu Krosing writes:
> On 10/10/2012 02:58 PM, Tom Lane wrote:
>> It's hard for me to see how you'd make the above work without
>> circularity, ie the PL manager would end up recursively calling itself
>> trying to construct or deconstruct the value.
> Again, could you be a bit more specific.
I
Merlin Moncure writes:
> On Wed, Oct 10, 2012 at 8:45 AM, Tom Lane wrote:
>> How much does this help?
>>
>> update pg_proc set procost = 10 where proname = 'pg_table_is_visible';
> hm, it fixes the problem. Also, at least for 9.2, the procost is
> still set at one (just looked). Well, thanks!
On Tuesday, October 09, 2012 10:32 PM Heikki Linnakangas wrote:
> On 06.10.2012 15:58, Amit Kapila wrote:
> > One more test seems to be failed. Apart from this, other tests are
> passed.
> >
It seems there is one more defect, please check the same
Defect:
1. start primary A
2. s
Heikki Linnakangas writes:
> On 10.10.2012 16:58, Tom Lane wrote:
>> The PLs aren't meant to be usable as I/O functions. cstring is not the
>> problem there, it's access to the bit-level representation of the other
>> datatype. It's hard for me to see how you'd make the above work without
>> cir
On 10.10.2012 16:58, Tom Lane wrote:
Hannu Krosing writes:
Is the lack of support of cstring in PLs just laziness/ovelook or is
there a good
reason why PL languages do not support cstring type arguments and return
values ?
In general I don't think we should encourage the use of cstring as a
u
On 10/10/2012 02:58 PM, Tom Lane wrote:
Hannu Krosing writes:
Is the lack of support of cstring in PLs just laziness/ovelook or is
there a good
reason why PL languages do not support cstring type arguments and return
values ?
In general I don't think we should encourage the use of cstring as a
2012/10/10 Merlin Moncure :
> On Wed, Oct 10, 2012 at 8:45 AM, Tom Lane wrote:
>> Merlin Moncure writes:
>>> ...but isn't pg_table_is_visible overkill for tab completion?
>>
>> How much does this help?
>>
>> update pg_proc set procost = 10 where proname = 'pg_table_is_visible';
>
> hm, it fixes t
Hello Peter
here is updated patch, sorry for missing file
Regards
Pavel
2012/10/8 Peter Geoghegan :
> On 20 August 2012 14:09, Pavel Stehule wrote:
>> (eelog-2012-08-20.diff)
>
> This patch has the following reference to relerror.c:
>
> """
>
> *** a/src/include/utils/rel.h
> --- b/src/inc
Hannu Krosing writes:
> Is the lack of support of cstring in PLs just laziness/ovelook or is
> there a good
> reason why PL languages do not support cstring type arguments and return
> values ?
In general I don't think we should encourage the use of cstring as a
user-level data type. The numbe
On Wed, Oct 10, 2012 at 8:45 AM, Tom Lane wrote:
> Merlin Moncure writes:
>> ...but isn't pg_table_is_visible overkill for tab completion?
>
> How much does this help?
>
> update pg_proc set procost = 10 where proname = 'pg_table_is_visible';
hm, it fixes the problem. Also, at least for 9.2, th
Merlin Moncure writes:
> ...but isn't pg_table_is_visible overkill for tab completion?
How much does this help?
update pg_proc set procost = 10 where proname = 'pg_table_is_visible';
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
Hackers,
I have a database with 94059 entries in pg_class. Things are mostly
working fine but psql tab completion is frustratingly slow (around 2.5
seconds on this box). I poked around in psql a bit and saw that the
main culprit was the table visibility condition check. Here's a
typical query (t
On Wed, Oct 10, 2012 at 3:36 PM, Simon Riggs wrote:
> On 10 October 2012 11:41, Heikki Linnakangas wrote:
>> Thoughts on that?
>
> I think there has been enough discussion of md5 problems elsewhere
> that we should provide an alternative.
>
> If we can agree on that bit first, we can move onto ex
Hi,
thanks for the new review.
2012-10-10 08:58 keltezéssel, Amit Kapila írta:
On Thursday, October 04, 2012 9:50 PM Boszormenyi Zoltan
2012-10-04 16:43 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan writes:
Did you think about something like the attached code?
Or rather this one, which fi
On 10 October 2012 11:41, Heikki Linnakangas wrote:
> Thoughts on that?
I think there has been enough discussion of md5 problems elsewhere
that we should provide an alternative.
If we can agree on that bit first, we can move onto exactly what else
should be available.
--
Simon Riggs
Is the lack of support of cstring in PLs just laziness/ovelook or is
there a good
reason why PL languages do not support cstring type arguments and return
values ?
I'm currently adding this to pl/pythonu with an aim to prototype type io
functions for a new type.
If it is just some security c
On 3 October 2012 19:54, Peter Geoghegan wrote:
> On 3 October 2012 19:04, Tom Lane wrote:
>> This argument seems sensible to me. Is there any use-case where the
>> proposed counter wouldn't do what people wished to do with an exposed
>> hash value?
>
> Yes. The hash could be used to aggregate q
On 3 October 2012 19:54, Peter Geoghegan wrote:
> On 3 October 2012 19:04, Tom Lane wrote:
>> This argument seems sensible to me. Is there any use-case where the
>> proposed counter wouldn't do what people wished to do with an exposed
>> hash value?
>
> Yes. The hash could be used to aggregate q
The security of MD5 authentication is brought up every now and then,
most recently here:
http://archives.postgresql.org/pgsql-hackers/2012-08/msg00586.php. The
NIST competition mentioned in that thread just finished. MD5 is still
resistent to preimage attacks, which is what matters for our MD5
On 8 October 2012 14:39, Peter Geoghegan wrote:
> Small patch that hopefully fixes everything for everyone is attached.
Will someone take a look at this, please?
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
--
Sent via pgsql
1 - 100 of 105 matches
Mail list logo
