On 26 January 2013 10:58, Pavel Stehule wrote:
> updated patches due changes for better variadic "any" function.
>
> apply fix_mixing_positinal_ordered_placeholders_warnings_20130126.patch first
>
Hi,
No one is listed as a reviewer for this patch so I thought I would
take a look at it, since it
On 23.01.2013 17:30, Robert Haas wrote:
On Wed, Jan 23, 2013 at 4:04 AM, Jeevan Chalke
wrote:
I guess my earlier patch, which was directly incrementing
ControlFile->unloggedLSN counter was the concern as it will take
ControlFileLock several times.
In this version of patch I did what Robert ha
On 26.01.2013 23:44, Aaron W. Swenson wrote:
On Fri, Jan 25, 2013 at 01:54:06PM -0500, Peter Eisentraut wrote:
On 1/12/13 3:30 PM, Aaron W. Swenson wrote:
The Linux Standard Base Core Specification 3.1 says this should return
'3'. [1]
[1]
http://refspecs.freestandards.org/LSB_3.1.1/LSB-Core-g
On Tue, Jan 22, 2013 at 7:31 AM, Amit Kapila wrote:
> On Monday, January 21, 2013 6:22 PM Magnus Hagander
>> On Fri, Jan 18, 2013 at 7:50 AM, Amit Kapila
>> wrote:
>> > On Wednesday, January 16, 2013 4:02 PM Heikki Linnakangas wrote:
>> >> On 07.01.2013 16:23, Boszormenyi Zoltan wrote:
>> >> > Si
On 24.01.2013 00:30, Andres Freund wrote:
Also, while the apply side surely isn't benchmarkable without any being
submitted, the changeset generation can very well be benchmarked.
A very, very adhoc benchmark:
-c max_wal_senders=10
-c max_logical_slots=10 --disabled for anything but logical
On 2013-01-27 07:54:43 +0900, Michael Paquier wrote:
> On Sun, Jan 27, 2013 at 1:52 AM, Andres Freund wrote:
> > On 2013-01-25 13:48:50 +0900, Michael Paquier wrote:
> > > > As far as I understand that code its purpose is to enforce that all
> > > > potential users have an up2date definition availa
On 2013-01-26 16:20:33 -0500, Steve Singer wrote:
> On 13-01-24 11:15 AM, Steve Singer wrote:
> >On 13-01-24 06:40 AM, Andres Freund wrote:
> >>
> >>Fair enough. I am also working on a user of this infrastructure but that
> >>doesn't help you very much. Steve Singer seemed to make some stabs at
> >
While testing Alexander's gistchoose patch, "perf report" showed that
the test case spent a surprisingly large amount of CPU time in
ExecScanHashBucket. That function just scans a hash bucket for matches,
and it should be very quick as long as there are not many collisions.
It turns out that t
Hi Marko,
I could not apply the patch with git apply, but able to apply it by patch
-p1 command.
However, will you please justify the changes done in "xml.out" ? I guess
they are not needed.
You might need to configure your sources with libxml.
Also, I am not sure about putting "WRAP_COLUMN_DEFA
Hi,
On 2013-01-27 23:07:51 -0500, Steve Singer wrote:
> A few more comments;
>
> In decode.c DecodeDelete
>
> + if (r->xl_len <= (SizeOfHeapDelete + SizeOfHeapHeader))
> + {
> + elog(DEBUG2, "huh, no primary key for a delete on wal_level =
> logical?");
> + return;
> + }
> +
On 2013-01-27 12:28:21 -0500, Steve Singer wrote:
> On 13-01-22 11:30 AM, Andres Freund wrote:
> >Hi,
> >
> >I pushed a new rebased version (the xlogreader commit made it annoying
> >to merge).
> >
> >The main improvements are
> >* way much coherent code internally for intializing logical rep
> >*
On 1/28/13 12:14 PM, Jeevan Chalke wrote:
I could not apply the patch with git apply, but able to apply it by patch
-p1 command.
IME that's normal for patches that went through filterdiff. I do: git
diff |filterdiff --format=context to re-format the patches to the
context diff preferred on
On 2013-01-28 11:59:52 +0200, Heikki Linnakangas wrote:
> On 24.01.2013 00:30, Andres Freund wrote:
> >Also, while the apply side surely isn't benchmarkable without any being
> >submitted, the changeset generation can very well be benchmarked.
> >
> >A very, very adhoc benchmark:
> > -c max_wal_se
On Mon, Jan 28, 2013 at 7:39 PM, Andres Freund wrote:
> On 2013-01-27 07:54:43 +0900, Michael Paquier wrote:
> I think you're misunderstanding how this part works a bit. We don't
> acquire locks on the table itself, but we get a list of all transactions
> we would conflict with if we were to acqui
On 28/01/13 12:31, Marko Tiikkaja wrote:
On 1/28/13 12:14 PM, Jeevan Chalke wrote:
I could not apply the patch with git apply, but able to apply it by patch
-p1 command.
IME that's normal for patches that went through filterdiff. I do: git
diff |filterdiff --format=context to re-format the p
Hi,
On 2013-01-28 20:31:48 +0900, Michael Paquier wrote:
> On Mon, Jan 28, 2013 at 7:39 PM, Andres Freund wrote:
>
> > On 2013-01-27 07:54:43 +0900, Michael Paquier wrote:
> > I think you're misunderstanding how this part works a bit. We don't
> > acquire locks on the table itself, but we get a li
On Mon, Jan 28, 2013 at 8:44 PM, Andres Freund wrote:
> > Another argument that would be enough for a rejection of this patch by a
> > committer is the problem of invalid toast indexes that cannot be removed
> up
> > cleanly by an operator. As long as there is not a clean solution for
> > that...
On 2013-01-28 20:50:21 +0900, Michael Paquier wrote:
> On Mon, Jan 28, 2013 at 8:44 PM, Andres Freund wrote:
>
> > > Another argument that would be enough for a rejection of this patch by a
> > > committer is the problem of invalid toast indexes that cannot be removed
> > up
> > > cleanly by an o
Hi,
I have tried other sources but to no avail. Could someone please tell me which
tables in pg_catalog are effected by creating or dropping a trigger. If there
is a work flow diagram or source code location you want to point me to rather
than listing them that will be fine also. Some plonker d
On Mon, Jan 28, 2013 at 10:24 AM, Graham Little
wrote:
>
> Hi,
>
>
>
> I have tried other sources but to no avail. Could someone please tell me
which tables in pg_catalog
> are effected by creating or dropping a trigger. If there is a work flow
diagram or source code location
> you want to point m
> So I think we need to sort by age(relfrozenxid) in tables that are over
> the anti-wraparound limit. Given your code that doesn't seem to be that
> hard?
I might also suggest that we think about changing the defaults for
wraparound vacuum behavior. Partcularly, the fact that
vacuum_freeze_min_
On 15.01.2013 21:03, Tom Lane wrote:
Robert Haas writes:
On the third hand, the fact that a table is OCDR is recorded in
backend-local storage somewhere, and that storage (unlike the
relcache) had better be reliable. So maybe there's some way to
finesse it that way.
Hm, keep a flag in that s
On Wed, Jan 23, 2013 at 10:05 AM, Noah Misch wrote:
> You're the second commentator to be skittish about the patch's correctness, so
> I won't argue against a conservatism-motivated bounce of the patch.
Can you please rebase the patch against the latest head ? I see
Alvaro's and Simon's recent c
On 2013-01-29 00:11:12 +1100, Josh Berkus wrote:
>
> > So I think we need to sort by age(relfrozenxid) in tables that are over
> > the anti-wraparound limit. Given your code that doesn't seem to be that
> > hard?
>
> I might also suggest that we think about changing the defaults for
> wraparound
On 23 January 2013 04:35, Noah Misch wrote:
>> Also, perhaps we should
>> consider Simon's one-liner fix for backpatching this instead of the
>> original patch you posted?
>
> I have no nontrivial preference between the two approaches.
Sorry, I didn't see this. I guess you saw I applied my one l
On Mon, Jan 28, 2013 at 04:48:56AM +, Peter Geoghegan wrote:
> On 28 January 2013 03:34, Noah Misch wrote:
> > Would you commit to the same git repository the pgbench-tools data for the
> > graphs appearing in that blog post? I couldn't readily tell what was
> > happening below 16 clients due
On Saturday, January 19, 2013 11:23 AM Amit kapila wrote:
>On Saturday, January 19, 2013 4:13 AM Boszormenyi Zoltan wrote:
>> Hi,
>>
>> Unfortunately, I won't have time to do anything with my lock_timeout
patch
>> for about 3 weeks. Does anyone have a little spare time to test it on
Windows?
>
>I s
Fabrizio,
Thank you very much for your email, I was able to run a script to generate
update statements to the tables you mentioned and this has fixed my problem for
me.
select'UPDATE pg_catalog.pg_class SET reltriggers=' || b.reltriggers-1 || '
WHERE relname=' || || a.table_name || ''
On Mon, Jan 28, 2013 at 8:59 PM, Andres Freund wrote:
> On 2013-01-28 20:50:21 +0900, Michael Paquier wrote:
> > On Mon, Jan 28, 2013 at 8:44 PM, Andres Freund
> wrote:
> >
> > > > Another argument that would be enough for a rejection of this patch
> by a
> > > > committer is the problem of inval
Heikki Linnakangas wrote:
> Not sure if that LSB section is relevant anyway. It specifies the
> exit codes for init scripts, but pg_ctl is not an init script.
Except that when I went to the trouble of wrapping pg_ctl with an
init script which was thoroughly LSB compliant (according to my
reading
On 28 January 2013 10:47, Heikki Linnakangas wrote:
> There's also some overhead from empty
> buckets when scanning the hash table
Seems like we should measure that overhead. That way we can plot the
cost against number per bucket, which sounds like it has a minima at
1.0, but that doesn't mean
On 1/26/13 4:44 PM, Aaron W. Swenson wrote:
> You are right. Had I read a little further down, it seems that the
> exit status should actually be 7.
7 is OK for "not running", but what should we use when the server is not
in standby mode? Using the idempotent argument that we are discussing
for t
Kevin Grittner writes:
> Heikki Linnakangas wrote:
>> Not sure if that LSB section is relevant anyway. It specifies the
>> exit codes for init scripts, but pg_ctl is not an init script.
> Except that when I went to the trouble of wrapping pg_ctl with an
> init script which was thoroughly LSB com
On 1/26/13 1:53 PM, Tom Lane wrote:
> [ pokes around... ] Hm, it appears that that does work on Linux,
> because for some reason we're specifying RTLD_GLOBAL to dlopen().
> TBH that seems like a truly horrid idea that we should reconsider.
> Aside from the danger of unexpected symbol collisions be
I am working on reviewing the patch. Patch apply without warning/error on
master branch. My findings are as following i.e.
1. Behavior change in pg_ctl return value i.e.
*
*
* Server already running*
a. Without Patch
inst asif$ ./bin/pg_ctl -D data_test/ -l data_test.log start
pg_ctl: anoth
On 01/28/2013 10:11 AM, Peter Eisentraut wrote:
On 1/26/13 1:53 PM, Tom Lane wrote:
[ pokes around... ] Hm, it appears that that does work on Linux,
because for some reason we're specifying RTLD_GLOBAL to dlopen().
TBH that seems like a truly horrid idea that we should reconsider.
Aside from t
On 14 January 2013 15:29, Alvaro Herrera wrote:
> Tom Lane wrote:
>> Peter Eisentraut writes:
>> > Here is a patch to add an option -I/--idempotent to pg_ctl, the result
>> > of which is that pg_ctl doesn't error on start or stop if the server is
>> > already running or already stopped.
>>
>> Ide
Hello
2013/1/28 Dean Rasheed :
> On 26 January 2013 10:58, Pavel Stehule wrote:
>> updated patches due changes for better variadic "any" function.
>>
>> apply fix_mixing_positinal_ordered_placeholders_warnings_20130126.patch first
>>
>
> Hi,
>
> No one is listed as a reviewer for this patch so I
Andres Freund wrote:
> On 2013-01-29 00:11:12 +1100, Josh Berkus wrote:
>>
>>> So I think we need to sort by age(relfrozenxid) in tables that
>>> are over the anti-wraparound limit. Given your code that
>>> doesn't seem to be that hard?
>>
>> I might also suggest that we think about changing the d
On Mon, Jan 28, 2013 at 4:47 AM, Phil Sorber wrote:
> On Sun, Jan 27, 2013 at 2:38 PM, Phil Sorber wrote:
>> On Fri, Jan 25, 2013 at 11:20 AM, Fujii Masao wrote:
>>> On Fri, Jan 25, 2013 at 4:10 AM, Phil Sorber wrote:
On Thu, Jan 24, 2013 at 1:12 PM, Fujii Masao wrote:
> set_pglocale_
Pavel Stehule writes:
> 2013/1/28 Dean Rasheed :
>> Starting with the first patch - it issues a new WARNING if the format
>> string contains a mixture of format specifiers with and without
>> parameter indexes (e.g., 'Hello %s, %1$s').
>>
>> Having thought about it a bit, I really don't like this
On 2013-01-28 08:15:29 -0800, Kevin Grittner wrote:
> Andres Freund wrote:
> > On 2013-01-29 00:11:12 +1100, Josh Berkus wrote:
> >>
> >>> So I think we need to sort by age(relfrozenxid) in tables that
> >>> are over the anti-wraparound limit. Given your code that
> >>> doesn't seem to be that har
On Mon, Jan 28, 2013 at 11:20 AM, Fujii Masao wrote:
> Maybe. But I'm not inclined to add new libpq interface at this stage.
> Because we are in the last CommitFest and I'm not sure whether
> we have enough time to implement that. Instead, how about using
> both PQconninfoParse() and PQconndefault
Heikki Linnakangas writes:
> The first question is, why do we aim at 10 tuples per bucket?
I see nothing particularly wrong with that. The problem here is with
having 1000 tuples per bucket.
> Ideally, the planner would always make a good guess the number of rows,
> but for the situations that
Dimitri Fontaine writes:
> Please find attached a new version of the patch, answering to most of
> your reviewing points. I'll post another version shortly with support
> for pg_dump and alter owner/rename.
So, as far as pg_dump is concerned, I have a trick question here.
We now have those new c
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Both. If we had done this when we first implemented format(), it'd be
> fine, but it's too late to change it now. There very likely are
> applications out there that depend on the current behavior. As Dean
> says, it's not incompatible with SUS, just a su
On Sun, Jan 27, 2013 at 10:40 PM, Alexander Korotkov
wrote:
> Now I'm working on additional comments.
Some comments were added for addKey and addArc(s). I hope they clarify
something.
--
With best regards,
Alexander Korotkov.
trgm-regexp-0.12.patch.gz
Description: GNU Zip compressed data
A couple more things about this patch ...
I went back through the thread and reviewed all the angst about which
fields to provide, especially whether we need CONSTRAINT_SCHEMA.
I agree with the conclusion that we don't. It's in the spec because
the spec supposes that CONSTRAINT_SCHEMA+CONSTRAINT_
Phil Sorber escribió:
> On Mon, Jan 28, 2013 at 11:20 AM, Fujii Masao wrote:
> > Maybe. But I'm not inclined to add new libpq interface at this stage.
> > Because we are in the last CommitFest and I'm not sure whether
> > we have enough time to implement that. Instead, how about using
> > both PQc
On Mon, Jan 28, 2013 at 1:12 PM, Alvaro Herrera
wrote:
> Phil Sorber escribió:
>> On Mon, Jan 28, 2013 at 11:20 AM, Fujii Masao wrote:
>> > Maybe. But I'm not inclined to add new libpq interface at this stage.
>> > Because we are in the last CommitFest and I'm not sure whether
>> > we have enough
Dimitri Fontaine writes:
> Now that I've written this in that email, I think I'm going to go for
> the new command. But maybe we have some precedent for objects that we
> list in pg_dump only for solving several steps dependency lookups?
Yes, pg_dump has lots of objects that might not appear in a
hi,
> I'm less optimistic on the NetBSD front: even though I reported major
> show-stopper bugs (system died under load and was unable to complete
> a pgbench run), no one seemed to care.
can you give me a pointer?
YAMAMOTO Takashi
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
Hi,
On Mon, Jan 28, 2013 at 03:27:28PM +, YAMAMOTO Takashi wrote:
>
> can you give me a pointer?
This bug report for a start:
http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=46833
This is the only one I've filled; I also remember having irc discussions
with some netbsd developers
2013/1/28 Tom Lane :
> A couple more things about this patch ...
>
> I went back through the thread and reviewed all the angst about which
> fields to provide, especially whether we need CONSTRAINT_SCHEMA.
> I agree with the conclusion that we don't. It's in the spec because
> the spec supposes th
Hello
2013/1/26 Tom Lane :
> Andrew Dunstan writes:
>> +1. This looks quite nifty. Maybe useful too to have a default prefix
>> via some setting.
>
> Meh. I would expect that "\gset :foo" would work to specify a computed
> prefix if you wanted it --- isn't that sufficient indirection? I'm not
>
Pavel Stehule writes:
> 2013/1/28 Tom Lane :
>> ... The current patch provides sufficient
>> information to uniquely identify a table constraint, but not so much
>> domain constraints. Should we fix that? I think it'd be legitimate
>> to re-use SCHEMA_NAME for domain schema, but we'd need a new
2013/1/28 Tom Lane :
> Pavel Stehule writes:
>> 2013/1/28 Tom Lane :
>>> ... The current patch provides sufficient
>>> information to uniquely identify a table constraint, but not so much
>>> domain constraints. Should we fix that? I think it'd be legitimate
>>> to re-use SCHEMA_NAME for domain
On 28 January 2013 17:32, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Both. If we had done this when we first implemented format(), it'd be
>> fine, but it's too late to change it now. There very likely are
>> applications out there that depend on the current behavior. As D
2013/1/28 Dean Rasheed :
> On 28 January 2013 17:32, Stephen Frost wrote:
>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>>> Both. If we had done this when we first implemented format(), it'd be
>>> fine, but it's too late to change it now. There very likely are
>>> applications out there that depend
On 28 January 2013 20:40, Pavel Stehule wrote:
> 2013/1/28 Dean Rasheed :
>> On 28 January 2013 17:32, Stephen Frost wrote:
>>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
Both. If we had done this when we first implemented format(), it'd be
fine, but it's too late to change it now. There
Dean Rasheed writes:
> On 28 January 2013 20:40, Pavel Stehule wrote:
>> 2013/1/28 Dean Rasheed :
>>> flags - not currently implemented. Pavel's second patch adds support
>>> for the '-' flag for left justified string output. However, I think
>>> this should support all datatypes (i.e., %I and %L
On 28.01.2013 15:39, Amit Kapila wrote:
Rebased the patch as per HEAD.
I don't like the way heap_delta_encode has intimate knowledge of how the
lz compression works. It feels like a violent punch through the
abstraction layers.
Ideally, you would just pass the old and new tuple to pglz as c
On Sat, Jan 26, 2013 at 11:24 PM, Satoshi Nagayasu wrote:
> Hi,
>
> I have reviewed this patch.
>
> https://commitfest.postgresql.org/action/patch_view?id=1068
>
> 2012/12/21 Gurjeet Singh :
> > The patch is very much what you had posted, except for a couple of
> > differences due to bit-rot.
On 1/5/13 12:48 PM, Peter Geoghegan wrote:
>> is there agreement of routine_name and trigger_name fields?
> Well, Tom and I are both opposed to including those fields. Peter E
> seemed to support it in some way, but didn't respond to Tom's
> criticisms (which were just a restatement of my own). So,
On 13-01-28 06:17 AM, Andres Freund wrote:
Hi,
3. Pass the delete (with no key values) onto the replication client and let
it deal with it (see 1 and 2)
Hm.
While I agree that nicer behaviour would be good I think the real
enforcement should happen on a higher level, e.g. with event triggers
On 28 January 2013 21:33, Peter Eisentraut wrote:
> Another point, in case someone wants to revisit this in the future, is
> that these fields were applied in a way that is contrary to the SQL
> standard, I think.
>
> The presented patch interpreted ROUTINE_NAME as: the error happened
> while exec
On 13-01-28 06:23 AM, Andres Freund wrote:
The CF is also there to find UI warts and such, so something like this
seems perfectly fine. Even moreso as it doesn't look this will get
into 9.3 anyway. I wanted to add such an option, but I was too
lazy^Wbusy to think about the sematics. Your curren
On 01/26/2013 12:14 PM, Anderson C. Carniel wrote:
Hi,
I'm trying to build a. dll file to extend the postgres server with C
functions. I'm using visual studio 2012 to build the dll, and
PostgreSQL 9.2. I imported all directories postgres "\include\server*"
But I'm having the errors:
In t
I'm poking at event triggers a bit; would like to set up some examples
(and see if they
work, or break down badly; both are interesting results) to do some
validation of schema
for Slony.
What I'm basically thinking about is to set up some event triggers that run on
DROP TABLE / DROP SEQUENCE, and
Christopher Browne writes:
> I'm poking at event triggers a bit; would like to set up some examples
> (and see if they
> work, or break down badly; both are interesting results) to do some
> validation of schema
> for Slony.
Cool, thanks!
> What I'm basically thinking about is to set up some eve
On 01/27/2013 01:14 AM, Anderson C. Carniel wrote:
> Hi,
>
> I'm trying to build a. dll file to extend the postgres server with C
> functions. I'm using visual studio 2012 to build the dll, and
> PostgreSQL 9.2. I imported all directories postgres "\include\server*"
> But I'm having the errors:
>
>
Over in the thread about enhanced error fields, I claimed that
"constraints are uniquely named among those associated with a table,
or with a domain". But it turns out that that ain't necessarily so,
because the code path for index constraints doesn't pay any attention
to pre-existing check constr
On 29 January 2013 00:25, Tom Lane wrote:
> Of course this wouldn't be material for back-patching, but it seems to
> me there's still time to fix this for 9.3, and we should do so if we
> want to claim that the enhanced-errors patch uniquely identifies
> constraints.
I can see the case for fixing
On 2013-01-28 12:23:02 +0100, Andres Freund wrote:
> On 2013-01-27 12:28:21 -0500, Steve Singer wrote:
> > On 13-01-22 11:30 AM, Andres Freund wrote:
> > >Hi,
> > >
> > >I pushed a new rebased version (the xlogreader commit made it annoying
> > >to merge).
> > >
> > >The main improvements are
> > >
On Mon, Jan 28, 2013 at 03:40:08PM +, Simon Riggs wrote:
> On 14 January 2013 15:29, Alvaro Herrera wrote:
> > Tom Lane wrote:
> >> Peter Eisentraut writes:
> >> > Here is a patch to add an option -I/--idempotent to pg_ctl, the result
> >> > of which is that pg_ctl doesn't error on start or s
On Sun, Jan 27, 2013 at 5:28 PM, Jeff Davis wrote:
> There's a maximum of one FPI per page per cycle, and we need the FPI for
> any modified page in this design regardless.
>
> So, deferring the XLOG_HINT WAL record doesn't change the total number
> of FPIs emitted. The only savings would be on th
On Sun, Jan 27, 2013 at 11:15 PM, Craig Ringer wrote:
> On 01/28/2013 02:15 AM, Robert Haas wrote:
>
> I am not sure whether it's really true that a capability mechanism
> could "never really satisfy" anyone. It worked for Linux.
>
> I have no concern about using a capabilities approach for this,
On Mon, Jan 28, 2013 at 4:04 AM, Heikki Linnakangas
wrote:
> Do we need to do anything to unloggedLSN in pg_resetxlog?
Does the server go into recovery after pg_resetxlog? If so, no. If
not, probably, but I have no idea what. There's no "safe" value in
that case; what we ought to do is force a
On Mon, Jan 28, 2013 at 8:39 AM, Heikki Linnakangas
wrote:
> On 15.01.2013 21:03, Tom Lane wrote:
>> Robert Haas writes:
>>>
>>> On the third hand, the fact that a table is OCDR is recorded in
>>> backend-local storage somewhere, and that storage (unlike the
>>> relcache) had better be reliable.
On Mon, Jan 28, 2013 at 09:29:35PM -0500, Bruce Momjian wrote:
> On Mon, Jan 28, 2013 at 03:40:08PM +, Simon Riggs wrote:
> > On 14 January 2013 15:29, Alvaro Herrera wrote:
> > > Tom Lane wrote:
> > >> Peter Eisentraut writes:
> > >> > Here is a patch to add an option -I/--idempotent to pg_c
On Sun, Jan 27, 2013 at 2:17 PM, Jeff Janes wrote:
> On Fri, Jan 25, 2013 at 9:19 AM, Robert Haas wrote:
>> I think that to do this right, we need to consider not only the status
>> quo but the trajectory. For example, suppose we have two tables to
>> process, one of which needs a wraparound vac
Peter Geoghegan writes:
> On 29 January 2013 00:25, Tom Lane wrote:
>> Of course this wouldn't be material for back-patching, but it seems to
>> me there's still time to fix this for 9.3, and we should do so if we
>> want to claim that the enhanced-errors patch uniquely identifies
>> constraints.
On Mon, Jan 28, 2013 at 02:12:33PM +, Simon Riggs wrote:
> On 23 January 2013 04:35, Noah Misch wrote:
> >> Also, perhaps we should
> >> consider Simon's one-liner fix for backpatching this instead of the
> >> original patch you posted?
> >
> > I have no nontrivial preference between the two a
On Mon, Jan 28, 2013 at 8:11 AM, Josh Berkus wrote:
>> So I think we need to sort by age(relfrozenxid) in tables that are over
>> the anti-wraparound limit. Given your code that doesn't seem to be that
>> hard?
>
> I might also suggest that we think about changing the defaults for
> wraparound vac
On Mon, Jan 28, 2013 at 10:23 PM, Tom Lane wrote:
> I think that we'll soon be buried in gripes if they're not. Pretty much
> the whole point of this patch is to allow applications to get rid of
> ad-hoc, it-usually-works coding techniques. I'd argue that not checking
> the entire constraint ide
On Mon, Jan 28, 2013 at 04:29:12AM +, Peter Geoghegan wrote:
> On 28 January 2013 03:34, Noah Misch wrote:
> > On the EBS configuration with volatile fsync timings, the variability didn't
> > go away with 15s runs. On systems with stable fsync times, 15s was no
> > better
> > than 2s. Absen
I wrote:
> Rather what we've got is that constraints are uniquely named among
> those associated with a table, or with a domain. So the correct
> unique key for a table constraint is table schema + table name +
> constraint name, whereas for a domain constraint it's domain schema +
> domain name +
> Tom Lane Wrote:
> Peter Geoghegan writes:
> > On 29 January 2013 00:25, Tom Lane wrote:
> > I can see the case for fixing this, but I don't feel that it's
> > particularly important that constraints be uniquely identifiable from
> > the proposed new errdata fields.
>
> I think that we'll soon
> I have to admit, I fail to see why this is a good idea. There isn't much
> of an efficiency bonus in freezing early (due to hint bits) and vacuums
> over vacuum_freeze_table_age are considerably more expensive as they
> have to scan the whole heap instead of using the visibilitymap. And if
> you
> OK, I had some time to think about this. Basically, we have three
> outcomes for pg_ctl start:
>
> server not running and pg_ctl start success
> server start failed
> server already running
>
> Can't we just assign different return values to these cases, e.g. 0, 1,
> 2? We
On Mon, 2013-01-07 at 07:14 -0500, Peter Eisentraut wrote:
> Here is a patch for psql's \l command to accept patterns, like \d
> commands do. While at it, I also added an "S" option to show system
> objects and removed system objects from the default display. This might
> be a bit controversial,
Hello,
Thanks for fixing bug #6510!
Please look at the following l10n bug:
http://www.postgresql.org/message-id/502a26f1.6010...@gmail.com
and the proposed patch.
Best regards,
Alexander
>From 1e2d5f712744d4731b665724703c0da4971ea41e Mon Sep 17 00:00:00 2001
From: Alexander Lakhin
Date: Mon, 28
On Tue, Jan 29, 2013 at 10:49 AM, Josh Berkus wrote:
>
> > OK, I had some time to think about this. Basically, we have three
> > outcomes for pg_ctl start:
> >
> > server not running and pg_ctl start success
> > server start failed
> > server already running
> >
> > Can't we ju
93 matches
Mail list logo
