On Wed, Jan 26, 2011 at 13:35, Alexey Klyukin wrote:
>
> On Jan 26, 2011, at 10:08 PM, Alex Hunsaker wrote:
>>> (it's obviously reversed comparing with the original one), but it still
>>> segfaults after I fixed that.
Ahh yep, the reason reversing the che
Find attached v3 of the patch. changes include:
- fix deep recursion due to accidental reversal of check in encode_array_literal
- add proper support for stringifying composite/row types. I did not
find a good way to quote these from the perl on the fly, so instead we
compute it the same way we u
On Thu, Jan 27, 2011 at 03:38, Alexey Klyukin wrote:
> Hi,
>
> On Jan 27, 2011, at 9:31 AM, Alex Hunsaker wrote:
>
>> Find attached v3 of the patch. changes include:
>> - fix deep recursion due to accidental reversal of check in
>> encode_array_literal
>> -
On Mon, Jan 31, 2011 at 12:22, Andrew Dunstan wrote:
> This looks pretty good. But why are we bothering to keep $prolog at all any
> more, if all we're going to pass it is &PL_sv_no all the time? Maybe we'll
> have a use for it in the future, but right now we don't appear to unless I'm
> missing
On Mon, Jan 31, 2011 at 01:34, Alexey Klyukin wrote:
> I've looked at the patch and added a test for arrays exceeding or equal
> maximum dimensions to check, whether the recursive function won't bring
> surprises there. I've also added check_stack_depth calls to both split_array
> and plperl_h
s the array_in to convert it to the array datum, and, finally, calls
> plperl_ref_from_pg_array (provided by the patch) to produce the resulting
> array reference.
>> - Every existing plperl function that takes arrays is going to get
>> slower due to the overhead of parsing the string and
On Mon, Jan 31, 2011 at 01:34, Alexey Klyukin wrote:
> I've looked at the patch and added a test for arrays exceeding or equal
> maximum dimensions to check, whether the recursive function won't bring
> surprises there. I've also added check_stack_depth calls to both split_array
> and plperl_ha
On Fri, Feb 4, 2011 at 10:29, Andrew Dunstan wrote:
>> Anyone object to fixing the above as part of this patch? That is
>> making plperl_(build_tuple_result, modify_tuple, return_next,
>> hash_from_tuple) handle array and hash (composite/row) types
>> consistently? And _that_ would be to recurse a
On Thu, Feb 3, 2011 at 18:29, Alex Hunsaker wrote:
> On Mon, Jan 31, 2011 at 01:34, Alexey Klyukin wrote:
>> I've looked at the patch and added a test for arrays exceeding or equal
>> maximum dimensions to check, whether the recursive function won't bring
>> s
; database encoding on the way back. This avoids a number of
>> observed anomalies, and ensures Perl a consistent view of the
>> world.
>>
>> Some minor code cleanups are also accomplished.
>>
>> Alex Hunsaker, reviewed by Andy Colson.
>
>
> This has br
On Tue, Feb 8, 2011 at 08:18, Alexey Klyukin wrote:
>
> On Feb 6, 2011, at 9:43 AM, Alex Hunsaker wrote:
>> So here is a v6
>>
>> Comments?
>
> Thanks, looks great to me. It passes all the tests on my OS X system. I wonder
> what's the purpose of
On Tue, Feb 8, 2011 at 10:33, Alex Hunsaker wrote:
> On Tue, Feb 8, 2011 at 08:18, Alexey Klyukin wrote:
>> Thanks, looks great to me. It passes all the tests on my OS X system. I
>> wonder
>> what's the purpose of the amagic_call in get_perl_array_ref, instead of
>
On Tue, Feb 8, 2011 at 10:33, Alex Hunsaker wrote:
> On Tue, Feb 8, 2011 at 08:18, Alexey Klyukin wrote:
>>
>> On Feb 6, 2011, at 9:43 AM, Alex Hunsaker wrote:
>
>>> So here is a v6
>>>
>>> Comments?
>>
>> Thanks, looks great to me
On Wed, Feb 9, 2011 at 08:24, Alexey Klyukin wrote:
>
> What was actually broken in encode_array_literal support of composite types
> (it converted perl hashes to the literal composite-type constants, expanding
> nested arrays along the way) ? I think it would be a useful extension of the
> existi
> world.
>>
>> Some minor code cleanups are also accomplished.
>>
>> Alex Hunsaker, reviewed by Andy Colson.
>
> I just want to emphasize that this needs to be highlighted as a compatibility
> change in the release notes. As an example, I currently have this
On Wed, Feb 9, 2011 at 02:09, Jan Urbański wrote:
> On 27/01/11 22:42, Jan Urbański wrote:
>> On 23/12/10 14:50, Jan Urbański wrote:
>>> Here's a patch implementing properly invalidating functions that have
>>> composite type arguments after the type changes, as mentioned in
>>> http://archives.po
On Thu, Feb 10, 2011 at 21:53, David E. Wheeler wrote:
> On Feb 10, 2011, at 5:28 PM, Alex Hunsaker wrote:
>> The other thing that changed is non UTF-8 databases now also get
>> character semantics. That is we convert from the database encoding
>> into utf8 and visa
On Fri, Feb 11, 2011 at 08:47, Robert Haas wrote:
> On Thu, Feb 10, 2011 at 9:06 PM, Alex Hunsaker wrote:
>> On Wed, Feb 9, 2011 at 02:09, Jan Urbański wrote:
>>> On 27/01/11 22:42, Jan Urbański wrote:
>>>> On 23/12/10 14:50, Jan Urbański wrote:
>>>
27;s a patch implementing traceback support for PL/Python mentioned in
>>>>> http://archives.postgresql.org/pgsql-hackers/2010-12/msg01991.php. It's
>>>>> an incremental patch on top of the plpython-refactor patch sent eariler.
>>>>
>>>> Updated
On Fri, Feb 11, 2011 at 10:16, David E. Wheeler wrote:
> On Feb 10, 2011, at 11:43 PM, Alex Hunsaker wrote:
> Like I said, the terminology is awful.
Yeah I use encode and decode to mean the same thing frequently :-(.
>> In the the cited case he was passing "%C3%A9"
On Fri, Feb 11, 2011 at 10:44, Alex Hunsaker wrote:
> On Fri, Feb 11, 2011 at 10:16, David E. Wheeler wrote:
> That *looks* like it is decoding the input string, which it is, but
> actually that will double utf8 encode your string. It does not seem to
> in this case because we are
On Fri, Feb 11, 2011 at 11:07, David E. Wheeler wrote:
> I don't understand where the bug is. If a string is encoded in utf-8 Perl
> will not treat it as such unless the utf-8 flag is set.
Ok so I think we agreed this is right:
$ perl -E 'use URI::Escape; my $str = uri_unescape("%C3%A9"); say
s
On Fri, Feb 11, 2011 at 16:42, David E. Wheeler wrote:
> On Feb 11, 2011, at 12:57 PM, Alex Hunsaker wrote:
>
>> Yay! 1
>
> Yes, this is all good. But it still seems to me that:
>
> * If your database is neither utf-8 no sql_ascii
You mean... we have been talking past ea
On Wed, Feb 9, 2011 at 02:10, Jan Urbański wrote:
> On 06/02/11 20:12, Jan Urbański wrote:
>> On 27/01/11 22:58, Jan Urbański wrote:
>>> On 23/12/10 14:56, Jan Urbański wrote:
Here's a patch implementing traceback support for PL/Python mentioned in
http://archives.postgresql.org/pgsql-ha
On Fri, Feb 11, 2011 at 17:17, Alexey Klyukin wrote:
> So, here is the v8. Instead of rewriting the encode_array_literal I've added
> another function, encode_type_literal (could use a better name).
> ...
> I can easily convert the encode_array_literal to just call this function, but
> not encode_
On Sat, Feb 12, 2011 at 01:50, Jan Urbański wrote:
> On 12/02/11 04:12, Alex Hunsaker wrote:
>> In PLy_traceback fname and prname look like they will leak (well as
>> much as a palloc() in an error path can leak I suppose).
>
> But they're no palloc'd, no? fname is
On Sun, Feb 6, 2011 at 15:31, Andrew Dunstan wrote:
> Force strings passed to and from plperl to be in UTF8 encoding.
>
> String are converted to UTF8 on the way into perl and to the
> database encoding on the way back. This avoids a number of
> observed anomalies, and ensures Perl a consistent vi
On Mon, Feb 14, 2011 at 09:49, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> Here's where I think we are with this CommitFest.
>
> Subject: Re: [HACKERS] CommitFest 2011-01 as of 2011-02-04
>
> I'm gonna go out on a limb and hope you meant '2011-02-14' there. :)
>
>> So t
On Tue, Feb 15, 2011 at 14:12, Robert Haas wrote:
> On Tue, Feb 15, 2011 at 3:26 PM, marcin mank wrote:
>> how about : we use a single dash as the separator, and if the
>> extension author insists on having a dash in the name, as a punishment
>> he must duplicate the dash, i.e.:
>> uuid--ossp-1.0
On Wed, Feb 16, 2011 at 12:21, Alvaro Herrera
wrote:
> Excerpts from Tim Bunce's message of mié feb 16 14:08:11 -0300 2011:
>> I'd suggest encode_typed_literal() as a better name.
>
> FYI I'm looking at this patch (v10), and I'll incorporate Tim's suggestion.
Looks good to me.
--
Sent via pgsql
On Thu, Feb 17, 2011 at 16:18, Alvaro Herrera
wrote:
> Excerpts from Alex Hunsaker's message of sáb feb 12 04:53:14 -0300 2011:
>
>> - make plperl.o depend on plperl_helpers.h (should have been done in
>> the utf8 patch)
>
> Incidentally, I think this bit was lost, no
On Wed, Dec 7, 2016 at 1:12 PM, Tom Lane wrote:
> But this is all kind of moot if Peter is right that systemd will zap
> POSIX shmem along with SysV semaphores. I've been trying to reproduce
> the issue on a Fedora 25 installation, and so far I can't get it to
> zap anything, so I'm a bit at a
On Wed, Dec 7, 2016 at 3:42 PM, Tom Lane wrote:
>
>
> Hmm ... after further experimentation, I still can't get this version of
> systemd (231) to do anything evil. It turns out that Fedora ships it with
> KillUserProcesses turned off by default, and maybe having that on is a
> prerequisite for t
ng on the presence
of an order operator for the type, the resulting MCV lists after the
ANALYZE would be different (I mean not only due to the random nature of the
sample).
I'm not sure yet about the 1% rule for the last value, but would also love
to see if we can avoid the arbitrary limit here. What happens with a last
value which is less than 1% popular in the current code anyway?
Cheers!
--
Alex
nts?
>
Ah, neat, that's even better. :-)
What about regression tests? My assumption was that we won't be able to
add them with the usual expected file approach, but that we also don't need
it that hard. Everyone's in favor?
--
Alex
On Sun, Apr 3, 2016 at 3:43 AM, Alex Shulgin wrote:
>
> I'm not sure yet about the 1% rule for the last value, but would also love
> to see if we can avoid the arbitrary limit here. What happens with a last
> value which is less than 1% popular in the current code anyway?
&g
On Sun, Apr 3, 2016 at 7:18 AM, Tom Lane wrote:
> Alex Shulgin writes:
> > On Sun, Apr 3, 2016 at 3:43 AM, Alex Shulgin
> wrote:
> >> I'm not sure yet about the 1% rule for the last value, but would also
> love
> >> to see if we can avoid the arbitrary l
On Sun, Apr 3, 2016 at 7:49 AM, Tom Lane wrote:
> Alex Shulgin writes:
> > On Sun, Apr 3, 2016 at 7:18 AM, Tom Lane wrote:
> >> Well, we have to do *something* with the last (possibly only) value.
> >> Neither "include always" nor "omit always"
On Sun, Apr 3, 2016, 18:32 Tom Lane wrote:
> Peter Geoghegan writes:
> > On Thu, Feb 11, 2016 at 9:50 AM, Robert Haas
> wrote:
> >> Wow, that's a fabulous idea. I see Oleksandr has tried to implement
> >> it, although I haven't looked at the patch. But I think this would be
> >> REALLY helpfu
On Sun, Apr 3, 2016, 18:40 Tom Lane wrote:
> Alex Shulgin writes:
>
> > Well, if it's the only value it will be accepted simply because we are
> > checking that special case already and don't even bother to loop through
> > the track list.
>
> That was
On Sun, Apr 3, 2016 at 8:24 AM, Alex Shulgin wrote:
>
> On Sun, Apr 3, 2016 at 7:49 AM, Tom Lane wrote:
>>
>> Alex Shulgin writes:
>> > On Sun, Apr 3, 2016 at 7:18 AM, Tom Lane wrote:
>> >> Well, we have to do *something* with the last (possibly only) va
On Sun, Apr 3, 2016 at 10:53 PM, Tom Lane wrote:
> Alex Shulgin writes:
> > This recalled observation can now also explain to me why in the
> regression
> > you've seen, the short path was not followed: my bet is that stadistinct
> > appeared negative.
>
> Ye
On Mon, Apr 4, 2016 at 1:06 AM, Tom Lane wrote:
> Alex Shulgin writes:
> > On Sun, Apr 3, 2016 at 10:53 PM, Tom Lane wrote:
> >> The reason for checking toowide_cnt is that if it's greater than zero,
> >> then in fact the track list does NOT include all val
y by using pg_resetxlog and setting it
parameters to values taken from wal file (pg_xlogdump)we can at least start PG
and saw that PG state is at the moment of last check point. But we have no real
confidence that PG is in consistent state(also docs on pg_resetxlogs told us
about it too)
Alex Ignat
On 01.05.2016 0:55, Bruce Momjian wrote:
On Thu, Apr 28, 2016 at 09:58:00PM +, Alex Ignatov wrote:
Hello everyone!
We have some issue with truncated pg_control file on Windows after power
failure.
My questions is :
1) Is pg_control protected from say , power crash or partial write?
2) How
Alex Ignatov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 03.05.2016 2:21, Andres Freund wrote:
Hi,
On 2016-04-28 21:58:00 +, Alex Ignatov wrote:
We have some issue with truncated pg_control file on Windows after
power failure.My questions is : 1
On 03.05.2016 2:17, Tom Lane wrote:
Alex Ignatov writes:
I think that rename can help a little bit. At least on some FS it is
atomic operation.
Writing a single sector ought to be atomic too. I'm very skeptical that
it'll be an improvement to just move the risk from one
On 06.05.2016 0:42, Greg Stark wrote:
On 5 May 2016 12:32 am, "Tom Lane" mailto:t...@sss.pgh.pa.us>> wrote:
>
> To repeat, I'm pretty hesitant to change this logic. While this is not
> the first report we've ever heard of loss of pg_control, I believe I
could
> count those reports without r
On 05.05.2016 7:16, Amit Kapila wrote:
On Wed, May 4, 2016 at 8:03 PM, Tom Lane mailto:t...@sss.pgh.pa.us>> wrote:
>
> Amit Kapila mailto:amit.kapil...@gmail.com>> writes:
> > On Wed, May 4, 2016 at 4:02 PM, Alex Ignatov
mailto:a.igna...@postgrespro.ru>>
>
review as a bug fix.
Regards,
Hi!
Do we have any confidence that data file is not being corrupted? I.e
contains some corrupted page? Can pg_basebackup check page checksum (db
init with initdb -k) while backing up files?
Alex Ignatov
Postgres Professional: http://www.postgrespro.com
The Russ
On Tue, Mar 10, 2015 at 10:11 AM, Tom Lane wrote:
> I wrote:
>
> This thread seems to have died off without any clear resolution. I'd
> hoped somebody would try the patch on some nontrivial application to
> see if it broke anything or caused any warnings, but it doesn't seem
> like that is happe
Dag-Erling Smørgrav writes:
> Alex Shulgin writes:
>> OK, looks like I've come up with something workable: I've added
>> sslprotocol connection string keyword similar to pre-existing
>> sslcompression, etc. Please see attached v2 of the original patch.
>>
rsion, but I notice we've
added mat. views since then, so it looks like we now also need this:
ALTER MATERIALIZED VIEW SET [VIEW | TOAST] TABLESPACE
Should I add this patch to the next CommitFest?
--
Alex
set_toast_tablespace_v0.11.patch.gz
Description: application/gzip
--
Sent via
rty, but wouldn't
>
> recovery_target_action = ...
>
> have been a better name for this? It'd be in line with the other
> recovery_target_* parameters, and also a bit shorter than the imho
> somewhat ugly "action_at_recovery_target".
FWIW, I too think that "recov
Alex Shulgin writes:
>
> Here's an attempt to revive this patch.
Here's the patch rebased against current HEAD, that is including the
recently committed action_at_recovery_target option.
The default for the new GUC is 'pause', as in HEAD, and
pause_at_recovery_targe
Michael Paquier writes:
> On Tue, Dec 2, 2014 at 1:58 AM, Alex Shulgin wrote:
>> Here's the patch rebased against current HEAD, that is including the
>> recently committed action_at_recovery_target option.
> If this patch gets in, it gives a good argument to jump to 1
Andres Freund writes:
> On 2014-12-02 17:25:14 +0300, Alex Shulgin wrote:
>> I'd be in favor of a solution that works the same way as before the
>> patch, without the need for extra trigger files, etc., but that doesn't
>> seem to be nearly possible. Whatever tri
ipc/procarray.c", Line: 1414)
Aborted (core dumped)
child process exited with exit code 134
--
Alex
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Alvaro Herrera writes:
> Alex Shulgin wrote:
>
>> Also this commit breaks initdb of `make check' for me:
>>
>> creating template1 database in
>> /home/ash/build/postgresql/HEAD/src/test/regress/./tmp_check/data/base/1
>> ... TRAP: FailedAssertion(&quo
Alvaro Herrera writes:
>
> Uh, that's odd. Can you please get a stack trace? Do you have unusual
> settings or a patched build?
Is there a way to pause the bootstrap process so I can attach gdb to it?
--
Alex
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
Craig Ringer writes:
> On 12/04/2014 10:50 PM, Alex Shulgin wrote:
>> Is there a way to pause the bootstrap process so I can attach gdb to it?
>
> With a newer gdb, you can instead tell gdb to follow all forks. I wrote
> some notes on it recently.
>
> http://blog.2
Alvaro Herrera writes:
> Alex Shulgin wrote:
>
>> DEBUG: inserting column 7 value "varchar_transform"
>>
>> Breakpoint 1, GetSnapshotData (snapshot=0xdb2d60 )
>> at /home/ash/src/postgresql/src/backend/storage/ipc/procarray.c:1413
&
Alex Shulgin writes:
>
> Figured it out with a pg_usleep in bootstrap.c anyway. Does this look sane?
>
>
> DEBUG: inserting column 6 value "0"
> DEBUG: inserted -> 0
> DEBUG: inserting column 7 value "varchar_transform"
> TRAP: FailedAsser
Alvaro Herrera writes:
> Alex Shulgin wrote:
>
>> DEBUG: inserting column 7 value "varchar_transform"
>>
>> Breakpoint 1, GetSnapshotData (snapshot=0xdb2d60 )
>> at /home/ash/src/postgresql/src/backend/storage/ipc/procarray.c:1413
&
17 00:00:00 2001
From: Alex Shulgin
Date: Tue, 9 Dec 2014 16:35:14 +0300
Subject: [PATCH] WIP: track TRUNCATEs in pgstat transaction stats.
The n_live_tup and n_dead_tup counters need to be set to 0 after a
TRUNCATE on the relation. We can't issue a special message to the stats
collector becau
Alex Shulgin writes:
>
> Bruce Momjian writes:
>>
>> Added to TODO:
>>
>> o Clear table counters on TRUNCATE
>>
>> http://archives.postgresql.org/pgsql-hackers/2008-04/msg00169.php
>
> Hello,
>
> Attached is a WIP patch
; they exist; see check_for_prepared_transactions().
Alright, that's good to know. So I'm just adding a new bool field to
the 2PC pgstat record instead of the bit magic.
Attached is v0.2, now with a regression test included.
--
Alex
>From 4c8fae27ecd9c94e7c3da0997f03099045a152d9
port->peer)
+ strlcpy(ptr,
X509_NAME_to_cstring(X509_get_subject_name(port->peer)), NAMEDATALEN);
The NAMEDATALEN constant is passed in the calling code in
pgstat_bestart().
Other than that, looks good to me.
--
Alex
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Alex Shulgin writes:
> Alex Shulgin writes:
>>
>> Here's an attempt to revive this patch.
>
> Here's the patch rebased against current HEAD, that is including the
> recently committed action_at_recovery_target option.
>
> The default for
feedback because of a lack of activity in
> the last couple of weeks. Feel free to update if you think that's not
> correct, and please move this patch to commit fest 2014-12.
Attached is a new version that addresses the earlier feedback: renamed
the added
patch by Craig,
addressing the handling of the new hint_log error data field and
removing the client-side HINT.
I'm also moving this to the current CF.
--
Alex
>From 702e0ac31f3d8023ad8c064d90bdf5a8441fddea Mon Sep 17 00:00:00 2001
From: Craig Ringer
Date: Fri, 17 Oct 2014 11:18:18
l have a test failure and won't have any
> indication why.
Oh, good catch. Since I've copied this function from stats.sql, we
might want to update that one too in a separate commit.
> I've attached a patch that adds logging on timeout and contains a test
> case that demons
nce to verify correctness due to side-effects of
rollback (ins/upd/del counters are still updated), and the way stats are
affecting the dead tuples counter.
I'll try to see if the checks can be converged though.
--
Alex
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
T
Alvaro Herrera writes:
> Alex Shulgin wrote:
>
>> Alvaro Herrera writes:
>> >>
>> >> Another idea would be exposing pgstat_report_stat(true) at SQL level.
>> >> That would eleminate the need for explicit pg_sleep(>=0.5), but we'll
need to
use the stats gathered prior to truncate. Thus the need to track
insert/update/deletes that happened before first truncate separately.
To the point of making a dedicated pgstat testing tool: let's have
another TODO item?
--
Alex
>From 0b3161191a3ddb999cd9d0da08e1b6088ce07a84 Mon Sep
Alvaro Herrera writes:
> Alex Shulgin wrote:
>
>> OK, I think I have now all bases covered, though the updated patch is
>> not that "pretty".
>>
>> The problem is that we don't know in advance if the (sub)transaction is
>> going to succeed o
Steve Singer writes:
> On 12/15/2014 11:38 AM, Alex Shulgin wrote:
>
>> These are all valid concerns IMHO. Attached is the modified version
>> of the original patch by Craig, addressing the handling of the new
>> hint_log error data field and removing the client-side
Craig Ringer writes:
> On 12/19/2014 11:41 PM, Alex Shulgin wrote:
>> I don't think so. The scenario this patch relies on assumes that the
>> DBA will remember to look in the log if something goes wrong
>
> Well, actually, the whole point was that the user who'
that you then call
> StartupXLOG() as StartupXLOG() is crazy long already so I think it's
> preferable to not make it worse.
We can move it at top of CheckStartingAsStandby() obviously.
> - I wonder if we should rename trigger_file to standby_tigger_file
I was also suggesting that, jus
Alex Shulgin writes:
> Petr Jelinek writes:
>>
>> I had a quick look, the patch does not apply cleanly anymore but it's
>> just release notes so nothing too bad.
>
> Yes, there were some ongoing changes that touched some parts of this and
> I must have mi
..
vmstat
zoneinfo
postgres=#
Limited performance testing shows no significant difference between
error-catching and plain code path. For example, timing
copy test_copy1 from program 'seq 100' [exceptions to stdout]
shows similar numbers with or without the added "exceptions to&
t to send
gigabytes of data to FE.
Is that right? Is the logic I am using safe and good?
Where does the result set (GBs of data) reside after I call
PQexecPrepared? On BE, I hope?
Thanks,
-- Alex -- alex-goncha...@comcast.net --
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
,--- I/Alex (Mon, 24 May 2010 12:25:18 -0400) *
| No equivalent of FETCH_COUNT is available at the libpq level, so I
| assume that the interface I am using is smart enough not to send
| gigabytes of data to FE.
|
| Where does the result set (GBs of data) reside after I call
| PQexecPrepared
).
`--*
Thank you very much!
-- Alex -- alex-goncha...@comcast.net --
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Jun 25, 2010 at 14:06, Peter Eisentraut wrote:
> Second version:
Hi!
Ive looked this over. Looks great! I have some nits about the
documentation and comments ( non issues like referencing primary keys
when it really means not null unique indexes :-P ), but on the whole
it works and loo
On Sun, Jun 13, 2010 at 18:35, Robert Haas wrote:
*Waves* Hi!
Patch looks and tests good to me. Only thing that seemed to be
missing was documentation of the new pg_dump(all) and guc params.
Find attached a stab at this. Yeah the docs I added need work, but I
figure if you are anything like me
On Sat, Jul 17, 2010 at 04:15, Peter Eisentraut wrote:
> On fre, 2010-07-16 at 22:29 -0600, Alex Hunsaker wrote:
>> The only corner case I have run into is creating a view with what I
>> would call an implicit 'not null' constraint. Demonstration below:
>>
>>
On Fri, Jul 16, 2010 at 22:29, Alex Hunsaker wrote:
> (FYI I do plan on doing some performance testing with large columns
> later, any other requests?)
And here are the results. All tests are with an empty table with 1500
int4 columns. There is a unique non null index on the first
On Sat, Jul 17, 2010 at 11:13, Alex Hunsaker wrote:
> On Sat, Jul 17, 2010 at 04:15, Peter Eisentraut wrote:
>> On fre, 2010-07-16 at 22:29 -0600, Alex Hunsaker wrote:
>>> The only corner case I have run into is creating a view with what I
>>> would call an imp
On Sun, Jul 18, 2010 at 02:40, Peter Eisentraut wrote:
> On lör, 2010-07-17 at 11:13 -0600, Alex Hunsaker wrote:
>> So I would expect the more indexes you
>> had or group by items to slow it down. Not so much the number of
>> columns. Right?
>
> At the outer level (w
On Fri, Jul 23, 2010 at 11:00, Alex Hunsaker wrote:
> Alternatively we could make it
> work with just primary keys until the other patch gets in. I think
> that makes sense, find that attached. Thoughts?
*sigh*, find attached a version that removes talk of unique not null
constraints
On Sat, Jul 24, 2010 at 06:23, Peter Eisentraut wrote:
> Another open question I thought of was whether we should put the
> dependency record on the pg_index row, or the pg_constraint row, or
> perhaps the pg_class row. Right now, it is using pg_index, because that
> was easiest to code up, but
On Fri, Jul 30, 2010 at 10:22, Robert Haas wrote:
> OK, it looks like level_2_parent is actually irrelevant to this issue.
> So here's a slightly simplified test case:
>
> DROP SCHEMA IF EXISTS test_inheritance CASCADE;
> CREATE SCHEMA test_inheritance;
> SET search_path TO test_inheritance;
>
>
On Wed, Aug 4, 2010 at 13:11, Tom Lane wrote:
> Alex Hunsaker writes:
>> On Wed, Aug 4, 2010 at 11:04, Tom Lane wrote:
>>> If we were a bit earlier in the 9.0 cycle I would suggest that this
>>> confusion is a sufficient reason to drop the one-argument form of
>&g
On Wed, Aug 4, 2010 at 13:42, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Aug 4, 2010 at 3:25 PM, Alex Hunsaker wrote:
>>> I think forcing an initdb might be more trouble than this wart is worth.
>
>> +1. I would not make this change unless we have to force
On Wed, Aug 4, 2010 at 16:33, Thom Brown wrote:
> I was afraid that the function would be pulled completely, but from
> looking at the patch, you're only removing the function with a
> single-parameter signature, which is quite innocuous. So I'm "for"
> now.
Ahh, Now I see why you were worried
On Wed, Aug 4, 2010 at 17:07, Tom Lane wrote:
> Alex Hunsaker writes:
>> I dunno about anyone else but (a, ',' order by a) just looks weird.
>
> I suppose, but aren't you just focusing on the argument being constant?
Yes.
>> Or in other words, any tho
On Thu, Aug 5, 2010 at 12:25, Tom Lane wrote:
> regression=# select string_agg(f1 order by f1, ',') from text_tbl;
> ERROR: function string_agg(text) does not exist
> LINE 1: select string_agg(f1 order by f1, ',') from text_tbl;
> ^
> HINT: No function matches the given name and ar
On Sat, Aug 7, 2010 at 20:13, Robert Haas wrote:
> Do we have a projected data for the next 9.0 wrap, and will it be
> beta5 or rc1? How much should we worry about the remaining open
> items?
If we are taking a vote, I +1 for rc1 :).
> http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items
>
On Mon, Aug 16, 2010 at 12:45, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Aug 16, 2010 at 20:27, Tom Lane wrote:
>>> Second, does git offer a way to collate matching log entries across
>>> multiple branches?
>
>> But what really is the usecase there?
>
> Generating back-branch update r
201 - 300 of 654 matches
Mail list logo
