On Wed, January 23, 2013 08:36, Alexander Korotkov wrote:
> Hi!
>
> Some quick answers to the part of notes/issues. I will provide rest of
> answers soon.
>
[...]
> trgm-regexp-0.10.patch.gz27 k
Trying to build this I get, after 'make install' in contrib/ :
/usr/bin/install: cannot stat `./pg
On Thu, Jan 24, 2013 at 3:41 AM, Andres Freund wrote:
> I think the usage of list_append_unique_oids in
> ReindexRelationsConcurrently might get too expensive in larger
> schemas. Its O(n^2) in the current usage and schemas with lots of
> relations/indexes aren't unlikely candidates for this featu
On Fri, Jan 25, 2013 at 01:08:09AM +0100, Dimitri Fontaine wrote:
> Andrew Dunstan writes:
> >>> tags
> >>> /cscope.out
> >>>
> >> +1 on cscope.out!
> >
> > There doesn't seem anything postgres-specific about these. Pretty much
> > everything we list is a byproduct of a standard build, not some ot
On 01/25/2013 03:43 AM, Jameison Martin wrote:
> there have been a lot of different threads on this patch. i'm going to
take a stab at > teasing them out, summarizing them, and addressing them
individually.
> Is this patch on the CF app? I can't seem to find it in 2013-01 or
2013-next, and I
> wa
On 01/16/2013 06:28 AM, Kohei KaiGai wrote:
> The attached patch is row-security v9.
Has anyone had a chance to check this out? It's seen a lot of work over
a long time and looks really valuable if it's solid enough.
Kohei KaiGai, is there any chance you can go through Simon's review and
offer an
Craig Ringer writes:
> I'd love to see this fix still make it into 9.3.
Working on it right now, actually.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/p
On 01/25/2013 11:09 AM, Noah Misch wrote:
> On Thu, Jan 24, 2013 at 01:13:33PM +0800, Craig Ringer wrote:
>> I have some final revisions to propose for the documentation but
>> otherwise this looks ready for commit.
> These documentation changes are barely connected to the addition of VS 2012
> sup
On Thu, Jan 24, 2013 at 01:13:33PM +0800, Craig Ringer wrote:
> I have some final revisions to propose for the documentation but
> otherwise this looks ready for commit.
These documentation changes are barely connected to the addition of VS 2012
support, so I think they should remain separate.
>
On Thursday, January 24, 2013 10:33 PM Tom Lane wrote:
> Andres Freund writes:
> > On 2013-01-24 11:22:52 -0500, Tom Lane wrote:
> >> Say again? Surely the temp file is being written by whichever
> backend
> >> is executing SET PERSISTENT, and there could be more than one.
>
> > Sure, but the pa
On Sun, Sep 16, 2012 at 04:16:22PM -0500, Kevin Grittner wrote:
> I'm attaching an alternative proposal, with changes for the following
> reasons:
>
> (1) The complete re-wrap of that first paragraph made it really hard
> to see what the actual change to the documentation was. I would
> rather
On Sun, Sep 9, 2012 at 07:06:07PM +0200, Kohei KaiGai wrote:
> I noticed a sentence in sepgsql says 180-degree opposite at:
>
> When DROP command is executed, drop will be
> checked on the object being removed for each object types. Permissions
> "will not be" checked for objects dropped i
I wrote:
> Here's a draft patch for that. I've not looked yet to see if there's
> any documentation that ought to be touched.
And now with the documentation. If I don't hear any objections, I plan
to commit this tomorrow.
regards, tom lane
diff --git a/doc/src/sgml/plpg
On 01/25/2013 01:32 AM, Pavel Stehule wrote:
> Hello
>
> so there is updated version
>
> + some lines of doc
> + new regress tests
>
> there are no reply to my previous mail - so I choose
>
> concat(variadic null) ---> NULL
> concat(variadic '{}') ---> empty string
>
I'd love to see this fix still
Greg Stark writes:
> That said I don't know just how common that usage pattern is. And I'm
> not sure how many of those people would be able to arrange for the
> null columns to land at the end of the row.
Obviously, they can't arrange that all the time (else their trailing
columns are unnecessar
On 01/25/2013 03:43 AM, Jameison Martin wrote:
> there have been a lot of different threads on this patch. i'm going to
> take a stab at teasing them out, summarizing them, and addressing them
> individually.
Is this patch on the CF app? I can't seem to find it in 2013-01 or
2013-next, and I wante
On 13-01-24 05:43 AM, Dimitri Fontaine wrote:
Robert Haas writes:
On Mon, Jan 21, 2013 at 12:27 PM, Dimitri Fontaine
wrote:
- Context exposing and filtering
I'm not feeling very sanguine about any of this. I feel strongly that
we should try to do something that's more principled than ju
On Fri, Jan 25, 2013 at 02:40:03AM +0100, Andres Freund wrote:
> > > The problem with that is not only that it sucks huge amounts of energy
> > > out of me and others but also that its very hard to really build the
> > > layers/users above changeset extraction without being able to rely on
> > > th
On 2013-01-23 14:02:46 -0500, Bruce Momjian wrote:
> As a reminder, COPY FREEZE still does not issue any warning/notice if
> the freezing does not happen:
FWIW, and I won't annoy anyone further after this email, now that its
deterministic, I still think that this should be an ERROR not a WARNING.
On Sun, Sep 2, 2012 at 05:40:54PM +, ja...@illusorystudios.com wrote:
> The following bug has been logged on the website:
>
> Bug reference: 7515
> Logged by: James Bellinger
> Email address: ja...@illusorystudios.com
> PostgreSQL version: 9.1.5
> Operating system: Ubuntu
On 01/25/2013 04:08 AM, Andrew Dunstan wrote:
>
> On 01/24/2013 02:41 PM, Andrew Dunstan wrote:
>>
>>>
>>> What advantages does mingw have over MSVC? Is it just that it is
>>> cost-free, or is it easier to use mingw than MSVC for someone used to
>>> building on Linux? (mingw certainly does not se
On 2013-01-24 20:28:41 -0500, Bruce Momjian wrote:
> On Fri, Jan 25, 2013 at 02:16:09AM +0100, Andres Freund wrote:
> > What I am afraid though is that it basically goes on like this in the
> > next commitfests:
> > * 9.4-CF1: no "serious" reviewer comments because they are busy doing
> > release
On Thu, Jan 24, 2013 at 8:17 PM, Tom Lane wrote:
> As I said, I'd be willing to take this risk if the patch showed more
> attractive performance benefits ... but it still seems mighty marginal
> from here.
I think the benchmarks given so far are actually barking up the wrong
tree though. There ar
On 2013-01-24 20:53:18 +0200, Heikki Linnakangas wrote:
> That said (hah, you knew there would be a "but" ;-)), now that I see what
> that looks like, I'm feeling that maybe it wasn't such a good idea after
> all. It sounded like a fairly small patch that greatly reduces the overhead
> in the maste
On Fri, Jan 25, 2013 at 02:16:09AM +0100, Andres Freund wrote:
> What I am afraid though is that it basically goes on like this in the
> next commitfests:
> * 9.4-CF1: no "serious" reviewer comments because they are busy doing release
> work
> * 9.4-CF2: all are relieved that the release is over a
On Thu, Jan 24, 2013 at 06:55:17PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> >> Didn't we want to issue the user some kind of feedback?
>
> > As no one wanted to write this patch, I have developed the attached
> > version.
>
> Please note the comment directly above where you patched.
>
>
Hi!
On 2013-01-24 13:27:00 -0500, Robert Haas wrote:
> On Thu, Jan 24, 2013 at 6:14 AM, Andres Freund wrote:
> Before getting bogged down in technical commentary, let me say this
> very clearly: I am enormously grateful for your work on this project.
> Logical replication based on WAL decoding i
On 01/25/2013 07:32 AM, gabrielle wrote:
> I'm working with some DB2 users, converting them to Pg, and I'm a bit
> confused about a certain class of SQLSTATE codes, specifically 02xxx
> "No data"
> (http://www.postgresql.org/docs/9.2/static/errcodes-appendix.html)
>
> As an example: I enable %e in
On 01/24/2013 08:51 PM, Виктор Егоров wrote:
> 2013/1/24 Nikolay Samokhvalov :
>> some app created tables ussing uppercase letters in table names (this app
>> was migrated from mysql). One tries to use \d to search tables info:
>>
>> ...
>>
>> Could this be considered as gotcha?
>>
>> The thing is
On 01/25/2013 02:44 AM, Jeff Janes wrote:
>
> What advantages does mingw have over MSVC? Is it just that it is
> cost-free, or is it easier to use mingw than MSVC for someone used to
> building on Linux? (mingw certainly does not seem to have the
> advantage of being fast!)
As far as I'm concerne
Hi Alvaro,
Nice to see a patch on this!
On 2013-01-24 18:57:15 -0300, Alvaro Herrera wrote:
> I have a bug pending that autovacuum fails to give priority to
> for-wraparound tables. When xid consumption rate is high and dead tuple
> creation is also high, it is possible that some tables are wait
gabrielle writes:
> I'm working with some DB2 users, converting them to Pg, and I'm a bit
> confused about a certain class of SQLSTATE codes, specifically 02xxx "No
> data" (http://www.postgresql.org/docs/9.2/static/errcodes-appendix.html)
> As an example: I enable %e in log_line_prefix so I can
Andrew Dunstan writes:
>>> tags
>>> /cscope.out
>>>
>> +1 on cscope.out!
>
> There doesn't seem anything postgres-specific about these. Pretty much
> everything we list is a byproduct of a standard build, not some other tool.
> "man gitignore" says
You can use .git/info/exclude for a personal per
Bruce Momjian writes:
>> Didn't we want to issue the user some kind of feedback?
> As no one wanted to write this patch, I have developed the attached
> version.
Please note the comment directly above where you patched.
The proposed message doesn't seem to me to be following the message
style g
Christopher Browne writes:
> On Thu, Jan 24, 2013 at 5:22 PM, Heikki Linnakangas
> wrote:
>> Backpatching sounds a bit scary. It's not a clear-cut bug, it's just that
>> autovacuum could be smarter about its priorities. There are other ways you
>> can still bump into the xid-wraparound issue, eve
I'm working with some DB2 users, converting them to Pg, and I'm a bit
confused about a certain class of SQLSTATE codes, specifically 02xxx "No
data" (http://www.postgresql.org/docs/9.2/static/errcodes-appendix.html)
As an example: I enable %e in log_line_prefix so I can see the SQLSTATE
values.
On Thu, Aug 30, 2012 at 07:59:02PM -0700, Joe Conway wrote:
> On 08/30/2012 07:23 PM, Bruce Momjian wrote:
> > On Thu, Jul 12, 2012 at 06:01:00PM -0700, Joe Conway wrote:
> >> I'll take a look at the latter option sometime in the next few weeks and
> >> submit for the next commitfest.
> >
> > Any
On Thu, Jan 24, 2013 at 5:22 PM, Heikki Linnakangas
wrote:
> Backpatching sounds a bit scary. It's not a clear-cut bug, it's just that
> autovacuum could be smarter about its priorities. There are other ways you
> can still bump into the xid-wraparound issue, even with this patch.
I don't think t
On Thu, Aug 30, 2012 at 04:37:37PM -0400, Bruce Momjian wrote:
> On Tue, May 29, 2012 at 03:54:59PM -0700, Mark Dilger wrote:
> > I was imagining that this would be a trap for linux developers
> > who saw nothing wrong with their code until it made it to the
> > build/test farm. That's pretty far
On Thu, Jan 24, 2013 at 02:34:49PM -0800, Paul Ramsey wrote:
> On Tuesday, January 15, 2013 at 2:14 PM, Bruce Momjian wrote:
>
> I mentioned last year that I wanted to start working on parallelism:
>
> https://wiki.postgresql.org/wiki/Parallel_Query_Execution
>
> I believe it is time
On Thu, Jan 24, 2013 at 05:30:22PM -0500, Peter Eisentraut wrote:
> On 1/24/13 5:09 PM, Bruce Momjian wrote:
> > On Wed, Jan 23, 2013 at 02:02:46PM -0500, Bruce Momjian wrote:
> >> As a reminder, COPY FREEZE still does not issue any warning/notice if
> >> the freezing does not happen:
>
> > As no
On Tuesday, January 15, 2013 at 2:14 PM, Bruce Momjian wrote:
> I mentioned last year that I wanted to start working on parallelism:
>
> https://wiki.postgresql.org/wiki/Parallel_Query_Execution
>
> I believe it is time to start adding parallel execution to the backend.
> We already have some pa
On 1/24/13 5:09 PM, Bruce Momjian wrote:
> On Wed, Jan 23, 2013 at 02:02:46PM -0500, Bruce Momjian wrote:
>> As a reminder, COPY FREEZE still does not issue any warning/notice if
>> the freezing does not happen:
> As no one wanted to write this patch, I have developed the attached
> version.
I th
On 24.01.2013 23:57, Alvaro Herrera wrote:
I have a bug pending that autovacuum fails to give priority to
for-wraparound tables. When xid consumption rate is high and dead tuple
creation is also high, it is possible that some tables are waiting for
for-wraparound vacuums that don't complete in t
On Thu, Jan 24, 2013 at 04:51:04PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Would someone make the doc change outlined above? Thanks.
>
> Sorry, I'd nearly forgotten about this issue. Will see about fixing the
> docs. (It looks like some of the comments in execMain.c could use work
>
On Wed, Jan 23, 2013 at 02:02:46PM -0500, Bruce Momjian wrote:
> As a reminder, COPY FREEZE still does not issue any warning/notice if
> the freezing does not happen:
>
> Requests copying the data with rows already frozen, just as they
> would be after running the VACUUM FREEZE command
Hi,
I have a bug pending that autovacuum fails to give priority to
for-wraparound tables. When xid consumption rate is high and dead tuple
creation is also high, it is possible that some tables are waiting for
for-wraparound vacuums that don't complete in time because the workers
are busy process
Bruce Momjian writes:
> Would someone make the doc change outlined above? Thanks.
Sorry, I'd nearly forgotten about this issue. Will see about fixing the
docs. (It looks like some of the comments in execMain.c could use work
too.)
regards, tom lane
--
Sent via pgsql
Heikki Linnakangas writes:
> BTW, one thing that I wondered about this: How expensive is random()?
> I'm assuming not very, but I don't really know. Alexander's patch called
> random() for every tuple on the page, while I call it only once for each
> equal-penalty tuple. If it's really cheap, I
On 01/24/2013 11:19 AM, Noah Misch wrote:
On Thu, Jan 24, 2013 at 08:50:36AM -0500, Andrew Dunstan wrote:
On 01/24/2013 03:42 AM, Craig Ringer wrote:
On 01/24/2013 01:06 AM, Alexander Law wrote:
Hello,
Please let me know if I can do something to get the bug fix
(https://commitfest.postgresql.
critical, so the fact that we may lose the dirty bit is
OK.
Regards,
Jeff Davis
replace-tli-with-checksums-20130124.patch.gz
Description: GNU Zip compressed data
checksums-20130124.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
On Wed, Aug 29, 2012 at 01:13:51PM +, Rajeev rastogi wrote:
>
> From: pgsql-bugs-ow...@postgresql.org [pgsql-bugs-ow...@postgresql.org] on
> behalf of Bruce Momjian [br...@momjian.us]
> Sent: Wednesday, August 29, 2012 8:46 AM
> To: Tom Lane
> Cc: Rober
On Wed, Aug 15, 2012 at 11:09:18PM +0530, Sushant Sinha wrote:
> I will do the profiling and present the results.
Sushant, do you have any profiling results on this issue from August?
---
>
> On Wed, 2012-08-15 at 12:45 -0
On 24.01.2013 22:35, Tom Lane wrote:
Alexander Korotkov writes:
There is another cause of overhead when use randomization in gistchoose:
extra penalty calls. It could be significant when index fits to cache. In
order evade it I especially change behaviour of my patch from "look
sequentially and
On Thu, Jan 24, 2013 at 03:14:15PM -0500, Kevin Grittner wrote:
> Noah Misch wrote:
> > On Thu, Jan 24, 2013 at 01:29:10PM -0500, Kevin Grittner wrote:
> >> Noah Misch wrote:
> >>> For the benefit of the archives, I note that we almost need not truncate
> >>> an
> >>> unlogged materialized view du
On Wed, Jan 23, 2013 at 04:58:57PM -0500, Bruce Momjian wrote:
> Attached is a ready-to-apply version of the patch. I continued to use
> postmaster.pid to determine if I need to try the start/stop test ---
> that allows me to know which servers _might_ be running, because a
> server start failure
Alexander Korotkov writes:
> There is another cause of overhead when use randomization in gistchoose:
> extra penalty calls. It could be significant when index fits to cache. In
> order evade it I especially change behaviour of my patch from "look
> sequentially and choose random" to "look in rand
Jameison Martin writes:
> there have been a lot of different threads on this patch. i'm going to take a
> stab at teasing them out, summarizing them, and addressing them individually.
Thanks for reviewing the bidding so carefully.
> 4.3) does it violate a principle in the code (Tom's latest ema
Noah Misch wrote:
> On Thu, Jan 24, 2013 at 01:29:10PM -0500, Kevin Grittner wrote:
>> Noah Misch wrote:
>>> For the benefit of the archives, I note that we almost need not truncate an
>>> unlogged materialized view during crash recovery. MVs are refreshed in a
>>> VACUUM FULL-like manner: fill a n
On Thu, Jan 24, 2013 at 11:26 PM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
> On 21.01.2013 15:19, Heikki Linnakangas wrote:
>
>> On 21.01.2013 15:06, Tom Lane wrote:
>>
>>> Jeff Davis writes:
>>>
On Mon, 2013-01-21 at 00:48 -0500, Tom Lane wrote:
> I looked at this patch.
On 01/24/2013 02:41 PM, Andrew Dunstan wrote:
What advantages does mingw have over MSVC? Is it just that it is
cost-free, or is it easier to use mingw than MSVC for someone used to
building on Linux? (mingw certainly does not seem to have the
advantage of being fast!)
See Craig's email to
On Thu, Jan 24, 2013 at 01:29:10PM -0500, Kevin Grittner wrote:
> Noah Misch wrote:
> > For the benefit of the archives, I note that we almost need not truncate an
> > unlogged materialized view during crash recovery. MVs are refreshed in a
> > VACUUM FULL-like manner: fill a new relfilenode, fsync
Heikki Linnakangas writes:
> I did some experimenting with that. I used the same test case Alexander
> did, with geonames data, and compared unpatched version, the original
> patch, and the attached patch that biases the first "best" tuple found,
> but still sometimes chooses the other equally
On 01/24/2013 01:44 PM, Jeff Janes wrote:
On Sat, Jan 19, 2013 at 12:15 PM, Andrew Dunstan wrote:
On 01/19/2013 02:36 AM, Boszormenyi Zoltan wrote:
A long time ago I had a lot of sympathy with this answer, but these days not
so much. Getting a working mingw/msys environment sufficient to build
On 21.01.2013 15:19, Heikki Linnakangas wrote:
On 21.01.2013 15:06, Tom Lane wrote:
Jeff Davis writes:
On Mon, 2013-01-21 at 00:48 -0500, Tom Lane wrote:
I looked at this patch. ISTM we should not have the option at all but
just do it always. I cannot believe that always-go-left is ever a
pref
On Thu, Jan 24, 2013 at 1:12 PM, Fujii Masao wrote:
> set_pglocale_pgservice() should be called?
>
> I think that the command name (i.e., pg_isready) should be given to
> PQpingParams() as fallback_application_name. Otherwise, the server
> by default uses "unknown" as the application name of pg_is
On 21.01.2013 15:19, Heikki Linnakangas wrote:
On 21.01.2013 15:06, Tom Lane wrote:
Jeff Davis writes:
On Mon, 2013-01-21 at 00:48 -0500, Tom Lane wrote:
I looked at this patch. ISTM we should not have the option at all but
just do it always. I cannot believe that always-go-left is ever a
pref
On 24 January 2013 17:44, Simon Riggs wrote:
>> At replay, an end-of-recovery record should be a signal to the hot standby
>> mechanism that there are no transactions running in the master at that
>> point, same as a shutdown checkpoint.
>
> I had a reason why I didn't do that, but it seems to ha
On 24.01.2013 20:27, Robert Haas wrote:
Before getting bogged down in technical commentary, let me say this
very clearly: I am enormously grateful for your work on this project.
Logical replication based on WAL decoding is a feature of enormous
value that PostgreSQL has needed for a long time, an
On 2013-01-24 13:29:56 -0500, Robert Haas wrote:
> On Wed, Jan 23, 2013 at 1:45 PM, Alvaro Herrera
> wrote:
> > Andres Freund escribió:
> >> I somewhat dislike the fact that CONCURRENTLY isn't really concurrent
> >> here (for the listeners: swapping the indexes acquires exlusive locks) ,
> >> but
Bruce Momjian writes:
> On Thu, Jan 24, 2013 at 01:29:56PM -0500, Robert Haas wrote:
>> I'm kind of unconvinced of the value proposition of this patch. I
>> mean, you can DROP INDEX CONCURRENTLY and CREATE INDEX CONCURRENTLY
>> today, so ... how is this better?
> This has been on the TODO list f
On Sat, Jan 19, 2013 at 12:15 PM, Andrew Dunstan wrote:
> On 01/19/2013 02:36 AM, Boszormenyi Zoltan wrote:
>>
>
> A long time ago I had a lot of sympathy with this answer, but these days not
> so much. Getting a working mingw/msys environment sufficient to build a bare
> bones PostgreSQL from scr
* Robert Haas (robertmh...@gmail.com) wrote:
> Now, the bad news is, I don't think it's very reasonable to try to
> commit this to 9.3. I think it is just too much stuff too late in the
> cycle. I've reviewed some of the patches from time to time but there
> is a lot more stuff and it's big and c
On Thu, Jan 24, 2013 at 01:29:56PM -0500, Robert Haas wrote:
> On Wed, Jan 23, 2013 at 1:45 PM, Alvaro Herrera
> wrote:
> > Andres Freund escribió:
> >> I somewhat dislike the fact that CONCURRENTLY isn't really concurrent
> >> here (for the listeners: swapping the indexes acquires exlusive locks)
On Wed, Jan 23, 2013 at 1:45 PM, Alvaro Herrera
wrote:
> Andres Freund escribió:
>> I somewhat dislike the fact that CONCURRENTLY isn't really concurrent
>> here (for the listeners: swapping the indexes acquires exlusive locks) ,
>> but I don't see any other naming being better.
>
> REINDEX ALMOST
Thanks for looking at this!
Noah Misch wrote:
> For the benefit of the archives, I note that we almost need not truncate an
> unlogged materialized view during crash recovery. MVs are refreshed in a
> VACUUM FULL-like manner: fill a new relfilenode, fsync it, and point the MV's
> pg_class to that
On Thu, Jan 24, 2013 at 6:14 AM, Andres Freund wrote:
> Thats way much more along the lines of what I am afraid of than the
> performance stuff - but Heikki cited those, so I replied to that.
>
> Note that I didn't say this must, must go in - I just don't think
> Heikki's reasoning about why not h
On Fri, Jan 25, 2013 at 1:45 AM, Phil Sorber wrote:
> On Wed, Jan 23, 2013 at 8:12 PM, Fujii Masao wrote:
>> On Thu, Jan 24, 2013 at 8:47 AM, Phil Sorber wrote:
>>> On Wed, Jan 23, 2013 at 6:07 PM, Tom Lane wrote:
Phil Sorber writes:
> On Wed, Jan 23, 2013 at 1:58 PM, Bruce Momjian w
9.1 introduced delayed validation on FKs, and 9.2 on table constraints,
however neither one has been useful due to lesser-locks on ALTER TABLE
being reverted (see
http://www.postgresql.org/message-id/1330350691-su...@alvh.no-ip.org),
preventing the lock benefits during the VALIDATE stage.
I don't
Hi Kevin,
The patch conflicts with git master; I tested against master@{2013-01-20}.
On Wed, Jan 16, 2013 at 12:40:55AM -0500, Kevin Grittner wrote:
> I've been struggling with two areas:
>
> - pg_dump sorting for MVs which depend on other MVs
>From your later messages, I understand that you h
On Thu, Jan 17, 2013 at 07:54:55AM -0500, Robert Haas wrote:
> On Wed, Jan 16, 2013 at 1:38 PM, Tom Lane wrote:
> >> Where I really need someone to hit me upside the head with a
> >> clue-stick is the code I added to the bottom of RelationBuildDesc()
> >> in relcache.c. The idea is that on first a
Folks,
Andrew Gierth asked me to send this out as his email is in a parlous
state at the moment. My comments will follow in replies. Without
further ado:
SQL2008 says, for 7.6
6)
a) If TR is contained in a FC with no intervening , then the scope clause SC of TR is the or innermost that
On 24 January 2013 16:52, Heikki Linnakangas wrote:
> On 24.01.2013 18:24, Simon Riggs wrote:
>>
>> On 6 January 2013 21:58, Simon Riggs wrote:
>>>
>>> I've been torn between the need to remove the checkpoint for speed and
>>>
>>> being worried about the implications of doing so.
>>>
>>> We promo
On 2013-01-24 12:30:02 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Backend A: does SET PERSISTENT foobar =..;
> > Backend B: does SET PERSISTENT foobar =..;
>
> > Now B overwrites the config change A has made as they are all stored in
> > the same file.
>
> Say what? I thought the plan was
Hello
so there is updated version
+ some lines of doc
+ new regress tests
there are no reply to my previous mail - so I choose
concat(variadic null) ---> NULL
concat(variadic '{}') ---> empty string
this behave should not be precedent for any other variadic "any"
function, because concat() and
Andres Freund writes:
> Backend A: does SET PERSISTENT foobar =..;
> Backend B: does SET PERSISTENT foobar =..;
> Now B overwrites the config change A has made as they are all stored in
> the same file.
Say what? I thought the plan was one setting per file, so that we don't
get involved in havi
On Thu, Jan 24, 2013 at 6:25 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> On Thu, Jan 24, 2013 at 6:04 PM, Peter Eisentraut wrote:
>>> I think it might be better to just document this as an example. I don't
>>> quite see the overhead of maintaining another tool justified.
>
>> Well, obvious
Magnus Hagander writes:
> On Thu, Jan 24, 2013 at 6:04 PM, Peter Eisentraut wrote:
>> I think it might be better to just document this as an example. I don't
>> quite see the overhead of maintaining another tool justified.
> Well, obviously I don't entirely agree ;)
> Yes, it's a convenience c
On 2013-01-24 12:02:59 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-01-24 11:22:52 -0500, Tom Lane wrote:
> >> Say again? Surely the temp file is being written by whichever backend
> >> is executing SET PERSISTENT, and there could be more than one.
>
> > Sure, but the patch acquire
On Thu, Jan 24, 2013 at 6:04 PM, Peter Eisentraut wrote:
> After reviewing this, it appears to me that this is really just a very
> verbose version of
>
> archive_command = 'sleep $initialsleep; while test $(psql -AtX -c "select
> pg_xlogfile_name(something) < $$%f$$ collate \"C\";") = t; sleep $
After reviewing this, it appears to me that this is really just a very
verbose version of
archive_command = 'sleep $initialsleep; while test $(psql -AtX -c "select
pg_xlogfile_name(something) < $$%f$$ collate \"C\";") = t; sleep $sleep; done'
I think it might be better to just document this as a
Andres Freund writes:
> On 2013-01-24 11:22:52 -0500, Tom Lane wrote:
>> Say again? Surely the temp file is being written by whichever backend
>> is executing SET PERSISTENT, and there could be more than one.
> Sure, but the patch acquires SetPersistentLock exlusively beforehand
> which seems fi
Alvaro Herrera wrote:
> Improve concurrency of foreign key locking
I noticed a bug in visibility routines when pg_upgrade is involved:
tuples marked FOR UPDATE in the old cluster (i.e. HEAP_XMAX_INVALID not
set, HEAP_XMAX_EXCL_LOCK set, HEAP_XMAX_IS_MULTI not set) are invisible
(dead) on the new c
On Thu, Jan 24, 2013 at 11:53 PM, MauMau wrote:
> From: "Fujii Masao"
>>
>> On Thu, Jan 24, 2013 at 7:42 AM, MauMau wrote:
>>>
>>> I searched through PostgreSQL mailing lists with "WAL contains references
>>> to
>>> invalid pages", and i found 19 messages. Some people encountered similar
>>> pr
On 24.01.2013 18:24, Simon Riggs wrote:
On 6 January 2013 21:58, Simon Riggs wrote:
I've been torn between the need to remove the checkpoint for speed and
being worried about the implications of doing so.
We promote in multiple use cases. When we end a PITR, or are
performing a switchover, it
On Wed, Jan 23, 2013 at 8:12 PM, Fujii Masao wrote:
> On Thu, Jan 24, 2013 at 8:47 AM, Phil Sorber wrote:
>> On Wed, Jan 23, 2013 at 6:07 PM, Tom Lane wrote:
>>> Phil Sorber writes:
On Wed, Jan 23, 2013 at 1:58 PM, Bruce Momjian wrote:
> On Wed, Jan 23, 2013 at 12:27:45PM -0500, Tom L
On 1/24/13 10:48 AM, Tom Lane wrote:
> The fundamental problem here is that the compiler, unless told otherwise
> by a compilation switch, believes it is entitled to assume that no
> integer overflow will happen anywhere in the program. Therefore, any
> error check that is looking for overflow *sh
On 2013-01-24 11:22:52 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-01-24 16:45:42 +0530, Amit Kapila wrote:
> >>> * Writing the temporary file to .$pid seems like a bad idea, better use
> >>> one file for that, SET PERSISTENT is protected by an exclusive lock
> >>> anyway.
>
> >> I
On 6 January 2013 21:58, Simon Riggs wrote:
> On 9 August 2012 10:45, Simon Riggs wrote:
>> On 22 June 2012 05:03, Kyotaro HORIGUCHI
>> wrote:
>>
>>>I hope this is promising.
>>
>> I've reviewed this and thought about it over some time.
>
> I've been torn between the need to remove the check
Andres Freund writes:
> On 2013-01-24 16:45:42 +0530, Amit Kapila wrote:
>>> * Writing the temporary file to .$pid seems like a bad idea, better use
>>> one file for that, SET PERSISTENT is protected by an exclusive lock
>>> anyway.
>> I think we can use one temporary file, infact that was one of
On Thu, Jan 24, 2013 at 08:50:36AM -0500, Andrew Dunstan wrote:
> On 01/24/2013 03:42 AM, Craig Ringer wrote:
>> On 01/24/2013 01:06 AM, Alexander Law wrote:
>>> Hello,
>>> Please let me know if I can do something to get the bug fix
>>> (https://commitfest.postgresql.org/action/patch_view?id=902)
1 - 100 of 143 matches
Mail list logo
