Tom Lane writes:
> 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.
Certainly no objections from me: I had only a
On Sun, Jan 20, 2013 at 4:59 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> + PGresult *res = ExecuteSqlQueryForSingleRow(fout, "SELECT
>> pg_is_in_recovery()");
>
> That function call needs to be schema-qualified for security.
Applied and backpatched, with that fix and a sentence
On Thursday, January 24, 2013 6:51 PM Andres Freund wrote:
> On 2013-01-24 18:37:29 +0530, Amit Kapila wrote:
> > On Thursday, January 24, 2013 5:25 PM Andres Freund wrote:
> > > On 2013-01-24 16:45:42 +0530, Amit Kapila wrote:
> > > > > * The gram.y changes arround set_rest_(more|common) seem pret
On 25 January 2013 06:00, Kevin Grittner wrote:
> Noah Misch wrote:
>
>> The patch conflicts with git master; I tested against master@{2013-01-20}.
>
> New patch rebased, fixes issues raised by Thom Brown, and addresses
> some of your points.
Thanks for the new version. All previous issues I rai
2013/1/24 Magnus Hagander :
> On Thu, Jan 24, 2013 at 10:11 AM, Kohei KaiGai wrote:
>> 2013/1/24 Tom Lane :
>>> John R Pierce writes:
On 1/23/2013 8:32 PM, Tom Lane wrote:
> FWIW, in Fedora-land I see: ...
>>>
I'd be far more interested in what is in RHEL and CentOS.Fedora,
On 24.01.2013 19:44, Simon Riggs wrote:
On 24 January 2013 16:52, Heikki Linnakangas wrote:
I may be missing something, but it looks like after a "fast" promotion, you
don't request a new checkpoint. So it can take quite a while for the next
checkpoint to be triggered by checkpoint_timeout/segm
On Fri, Jan 25, 2013 at 11:20:56AM +0800, Craig Ringer wrote:
> On 01/25/2013 11:09 AM, Noah Misch wrote:
> > The official 9.0 and 9.1 64-bit builds are made with VS 2008, and the 9.2
> > builds with VS 2010.
> Paid versions, though, right?
So I hear.
> That should be clearer, that 64-bit support
On 2013-01-25 13:56:11 +0100, Magnus Hagander wrote:
> On Fri, Jan 25, 2013 at 1:31 PM, Andres Freund wrote:
> > On 2013-01-25 08:49:10 +, Magnus Hagander wrote:
> >> Make pg_dump exclude unlogged table data on hot standby slaves
> >
> > This missed the fact that there is no ExecuteSqlQueryFor
On Fri, Jan 25, 2013 at 1:59 PM, Andres Freund wrote:
> On 2013-01-25 13:56:11 +0100, Magnus Hagander wrote:
>> On Fri, Jan 25, 2013 at 1:31 PM, Andres Freund
>> wrote:
>> > On 2013-01-25 08:49:10 +, Magnus Hagander wrote:
>> >> Make pg_dump exclude unlogged table data on hot standby slaves
2013/1/25 Tom Lane :
> Craig Ringer writes:
>> I'd love to see this fix still make it into 9.3.
>
> Working on it right now, actually.
Thank you all for collaboration
Best regards
Pavel
>
> regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
2013/1/25 Bruce Momjian :
> 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
On 2013-01-24 20:45:20 -0500, Bruce Momjian wrote:
> 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...@illusorystudi
On Fri, Jan 25, 2013 at 02:22:40PM +0100, Andres Freund wrote:
> On 2013-01-24 20:45:20 -0500, Bruce Momjian wrote:
> > 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
> > > Logg
On Fri, Jan 25, 2013 at 8:01 AM, Magnus Hagander wrote:
> On Fri, Jan 25, 2013 at 1:59 PM, Andres Freund wrote:
>> On 2013-01-25 13:56:11 +0100, Magnus Hagander wrote:
>>> On Fri, Jan 25, 2013 at 1:31 PM, Andres Freund
>>> wrote:
>>> > On 2013-01-25 08:49:10 +, Magnus Hagander wrote:
>>> >>
On Fri, Jan 25, 2013 at 8:40 AM, Bruce Momjian wrote:
> Just a reminder we might have *BSD performance issues with our use of
> Posix shared memory in Postgres 9.3. I am attaching the PDF the user
> posted.
This is a good point. The question which I believe I asked before and
haven't gotten an
On Fri, Jan 25, 2013 at 08:47:51AM -0500, Robert Haas wrote:
> On Fri, Jan 25, 2013 at 8:40 AM, Bruce Momjian wrote:
> > Just a reminder we might have *BSD performance issues with our use of
> > Posix shared memory in Postgres 9.3. I am attaching the PDF the user
> > posted.
>
> This is a good p
Cody Cutrer wrote:
> 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
Hi,
Robert Haas wrote:
On Fri, Jan 25, 2013 at 8:40 AM, Bruce Momjian
wrote:
Just a reminder we might have *BSD performance issues with our use
of Posix shared memory in Postgres 9.3. I am attaching the PDF the
user posted.
This is a good point. The question which I believe I asked before
On Thu, Jan 24, 2013 at 6:17 PM, Tom Lane wrote:
> 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.
>
>
No objec
On Fri, Jan 25, 2013 at 02:48:37AM +0100, Andres Freund wrote:
> 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
[ changing subject line to keep threads of discussion separate ]
On Thu, Jan 24, 2013 at 5:51 AM, Dimitri Fontaine
wrote:
> Something like this part:
>
> + -- now try something crazy to ensure we don't crash the backend
> + create function test_event_trigger_drop_function()
> + returns event_tri
On Fri, Sep 14, 2012 at 02:04:51PM +, Amit kapila wrote:
> On Thu, 6 Sep 2012 14:50:05 -0400 Robert Hass wrote:
>
> On Tue, Aug 28, 2012 at 6:40 AM, Amit Kapila com> wrote:
> >> AFAICT during Update also, it doesn't contain useful. The only chance it
> >> would have contain something useful
Heikki Linnakangas writes:
> There's no hard correctness reason here for any particular behavior, I
> just feel that that would make most sense. It seems prudent to initiate
> a checkpoint right after timeline switch, so that you get a new
> checkpoint on the new timeline fairly soon - it could
pg_restore --single-transaction has the setup to make use of the new
COPY FREEZE optimization.
However, I don't see us using COPY FREEZE for pg_restore
--single-transaction. Shouldn't we do that? The problem is we would
need to have pg_dump emit the FREEZE, which would cause it not to load
in ea
We are currently analyzing an issue at one of our customers PostgreSQL
database.
The current version is 9.1.6 (update to 9.1.7 is scheduled for next monday,
no downtime possible before). It runs on POWER7 (pSeries 740) on an RHEL6.3
64-bit LPAR. The packages are built from PGDG SVN sources, no
On 1/24/13 4:04 PM, Andrew Dunstan wrote:
>
> 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 ca
On 23.01.2013 07:31, Jon Erdman wrote:
Done. Attached.
Thanks, committed.
On 29.12.2012 20:56, Stephen Frost wrote:
> No biggie, and to get the bike-shedding started, I don't really like the
> column name or the values.. :) I feel like something clearer would be
> "Runs_As" with "caller" or "
On 2013-01-25 16:24:52 +0100, Bernd Helmle wrote:
> We are currently analyzing an issue at one of our customers PostgreSQL
> database.
>
> The current version is 9.1.6 (update to 9.1.7 is scheduled for next monday,
> no downtime possible before). It runs on POWER7 (pSeries 740) on an RHEL6.3
> 64-
Tom Lane escribió:
> As posted, what we've got here is sorting on a boolean condition, with
> the behavior within each group totally up to the whims of qsort(). That
> seems especially dangerous since the priority order is mostly undefined.
>
> I was a bit surprised that Alvaro didn't propose so
2013/1/25 Kohei KaiGai :
> 2013/1/24 Magnus Hagander :
>> On Thu, Jan 24, 2013 at 10:11 AM, Kohei KaiGai wrote:
>>> 2013/1/24 Tom Lane :
John R Pierce writes:
> On 1/23/2013 8:32 PM, Tom Lane wrote:
>> FWIW, in Fedora-land I see: ...
> I'd be far more interested in what is i
* Bruce Momjian (br...@momjian.us) wrote:
> On Fri, Jan 25, 2013 at 02:48:37AM +0100, Andres Freund wrote:
> > 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'
On 01/25/2013 10:26 AM, Peter Eisentraut wrote:
On 1/24/13 4:04 PM, Andrew Dunstan wrote:
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,
On Thu, Jan 24, 2013 at 5:43 AM, Dimitri Fontaine
wrote:
>> But I wonder: wouldn't it be better to just expose the raw string the
>> user typed? I mean, in all the cases we really care about, the
>> information we can *reliably* expose at this point is going to be
>> pretty nearly the same as ext
On Thu, Jan 24, 2013 at 4:36 AM, Xi Wang wrote:
> icc optimizes away the overflow check x + y < x (y > 0), because
> signed integer overflow is undefined behavior in C. Instead, use
> a safe precondition test x > INT_MAX - y.
As you post these patches, please add them to:
https://commitfest.pos
On 1/25/13 10:29 AM, Alvaro Herrera wrote:
> And I do want to get something back-patchable.
Autovacuum has existed for N years and nobody complained about this
until just now, so I don't see a strong justification for backpatching.
Or is this a regression from an earlier release?
In general, I t
--On 25. Januar 2013 16:28:16 +0100 Andres Freund
wrote:
Did you reindex after upgrading to 9.1.6? Did you ever have any crashes
or failovers before upgrading to 9.1.6?
I have seen pretty similar symptoms caused by "Fix persistence marking
of shared buffers during WAL replay" in 9.1.6.
Hm
On Fri, Jan 25, 2013 at 10:30:40AM -0500, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Fri, Jan 25, 2013 at 02:48:37AM +0100, Andres Freund wrote:
> > > On 2013-01-23 14:02:46 -0500, Bruce Momjian wrote:
> > > > As a reminder, COPY FREEZE still does not issue any warning/
Peter Eisentraut escribió:
> On 1/25/13 10:29 AM, Alvaro Herrera wrote:
> > And I do want to get something back-patchable.
>
> Autovacuum has existed for N years and nobody complained about this
> until just now, so I don't see a strong justification for backpatching.
I disagree about people not
On 25 January 2013 12:15, Heikki Linnakangas wrote:
>> 1) an immediate checkpoint can cause a disk/resource usage spike,
>> which is definitely not what you need just when a spike of connections
>> and new SQL hits the system.
>
>
> It doesn't need to be an "immediate" checkpoint, ie. you don't n
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_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
>
Alvaro Herrera writes:
> Peter Eisentraut escribió:
>> Autovacuum has existed for N years and nobody complained about this
>> until just now, so I don't see a strong justification for backpatching.
> I disagree about people not complaining. Maybe the complaints have not
> been specifically about
Alvaro Herrera writes:
> So if we're to discuss this, here's what I had in mind:
> 1. for-wraparound tables always go first; oldest age(relfrozenxid) are
> sorted earlier. For tables of the same age, consider size as below.
It seems unlikely that age(relfrozenxid) will be identical for multiple
On 25 January 2013 15:24, Bruce Momjian wrote:
> pg_restore --single-transaction has the setup to make use of the new
> COPY FREEZE optimization.
>
> However, I don't see us using COPY FREEZE for pg_restore
> --single-transaction. Shouldn't we do that? The problem is we would
> need to have pg_d
Robert Haas writes:
> OK, but can we lay the issue of a *normalized* command string to the
> side for just one minute, and talk about exposing the *raw* command
> string? It seems to me that this would be (1) very easy to do, (2)
> reasonable to slip into 9.3, and (3) useful to some people. Argu
Bruce Momjian writes:
> On Fri, Jan 25, 2013 at 02:48:37AM +0100, Andres Freund wrote:
>> 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.
> As the FREEZE is just an optimization, I thought NOTICE, vs
On 2013-01-25 11:51:33 -0500, Tom Lane wrote:
> Alvaro Herrera writes:
> > 2. for other tables, consider floor(log(size)). This makes tables of
> > sizes in the same ballpark be considered together.
>
> > 3. For tables of similar size, consider
> > (n_dead_tuples - threshold) / threshold.
> > "th
On Fri, Jan 25, 2013 at 11:51 AM, Tom Lane wrote:
> The floor(log(size)) part seems like it will have rather arbitrary
> behavioral shifts when a table grows just past a log boundary. Also,
> I'm not exactly sure whether you're proposing smaller tables first or
> bigger tables first, nor that eit
On Sat, Jan 5, 2013 at 11:11 PM, Magnus Hagander wrote:
> On Fri, Jan 4, 2013 at 7:13 PM, Peter Eisentraut wrote:
>> On 1/3/13 12:30 PM, Robert Haas wrote:
>>> On Thu, Jan 3, 2013 at 11:32 AM, Magnus Hagander
>>> wrote:
Any particular reason? It goes pretty tightly together with
pg_re
On 2013-01-26 02:21:00 +0900, Fujii Masao wrote:
> On Sat, Jan 5, 2013 at 11:11 PM, Magnus Hagander wrote:
> > On Fri, Jan 4, 2013 at 7:13 PM, Peter Eisentraut wrote:
> >> On 1/3/13 12:30 PM, Robert Haas wrote:
> >>> On Thu, Jan 3, 2013 at 11:32 AM, Magnus Hagander
> >>> wrote:
> Any parti
On Thu, Jan 24, 2013 at 09:12:41PM -0800, David Fetter wrote:
> On Thu, Jan 24, 2013 at 09:51:46AM -0800, David Fetter wrote:
> > 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 a
On 2013-01-25 12:19:25 -0500, Robert Haas wrote:
> On Fri, Jan 25, 2013 at 11:51 AM, Tom Lane wrote:
> > The floor(log(size)) part seems like it will have rather arbitrary
> > behavioral shifts when a table grows just past a log boundary. Also,
> > I'm not exactly sure whether you're proposing sm
On Fri, Jan 25, 2013 at 11:59 AM, Tom Lane wrote:
> Bruce Momjian writes:
>> On Fri, Jan 25, 2013 at 02:48:37AM +0100, Andres Freund wrote:
>>> 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.
>
>> A
On Fri, Sep 28, 2012 at 12:40:38PM -0500, Karl O. Pinc wrote:
> Hi,
>
> The attached patch (against git head)
> normalizes "search_path" as the thing indexed
> and uses a secondary index term to distinguish
> the configuration parameter from the run-time
> setting.
>
> "search path" the concept r
Andres Freund writes:
> I think if we backpatch this we should only prefer wraparound tables and
> leave the rest unchanged.
That's not a realistic option, at least not with anything that uses this
approach to sorting the tables. You'd have to assume that qsort() is
stable which it probably isn'
On Fri, Jan 25, 2013 at 12:00 PM, Andres Freund wrote:
> On 2013-01-25 11:51:33 -0500, Tom Lane wrote:
>> Alvaro Herrera writes:
>> > 2. for other tables, consider floor(log(size)). This makes tables of
>> > sizes in the same ballpark be considered together.
>>
>> > 3. For tables of similar size
On 2013-01-25 12:52:46 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I think if we backpatch this we should only prefer wraparound tables and
> > leave the rest unchanged.
>
> That's not a realistic option, at least not with anything that uses this
> approach to sorting the tables. You'd ha
On Fri, Jan 25, 2013 at 12:35 PM, Andres Freund 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 vacuum and the other one of
>> which needs dead tuples
On Fri, Jan 25, 2013 at 11:58 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> OK, but can we lay the issue of a *normalized* command string to the
>> side for just one minute, and talk about exposing the *raw* command
>> string? It seems to me that this would be (1) very easy to do, (2)
>>
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Jan 25, 2013 at 11:59 AM, Tom Lane wrote:
> > Bruce Momjian writes:
> >> On Fri, Jan 25, 2013 at 02:48:37AM +0100, Andres Freund wrote:
> >>> FWIW, and I won't annoy anyone further after this email, now that its
> >>> deterministic, I still t
* David Fetter (da...@fetter.org) wrote:
> As I see it, the current options are:
>
> 1. Do nothing, and insist on non-standard use of the LATERAL keyword.
I'm not a big fan of this. Providing a good error message saying "you
need to use LATERAL for this query to work" makes it slightly better,
b
Robert Haas writes:
> On Fri, Jan 25, 2013 at 12:35 PM, Andres Freund
> wrote:
>> I don't think the first part is problematic. Which scenario do you have
>> in mind where that would really cause adverse behaviour? autovacuum
>> seldomly does full table vacuums on tables otherwise these days so
>
On Mon, Oct 1, 2012 at 02:04:00PM +0900, Tatsuo Ishii wrote:
> > Tatsuo Ishii writes:
> >> From the manual:
> >> "An unnamed portal is destroyed at the end of the transaction"
> >
> > Actually, all portals are destroyed at end of transaction (unless
> > they're from holdable cursors). Named or
Stephen Frost writes:
> * David Fetter (da...@fetter.org) wrote:
>> 3. Make all cases of SRFs in the FROM-clause implicitly LATERAL.
>>
>> (As far as I can tell, those cases whose behaviour would be changed by
>> this actually produce errors in versions prior to 9.3, so no working
>> code should
May I propose the attached patch.
Points to note and possibly discuss:
(a) Only exit codes in do_* functions have been changed.
(b) The link to, and the version of, LSB specifications has been updated.
(c) A significant change is the exit code of do_stop() on stopping a
stopped server. Previous re
Bruce Momjian writes:
> I have applied a modified version of your patch that creates separate
> secondary index references for search_path.
This patch seems pretty bizarre. What is the difference between a
"configuration parameter" and a "run-time setting"? Why would you
point people to two dif
Don't think the attachment made it in the last mail. Attaching now.
On 25 January 2013 18:33, Dhruv Ahuja wrote:
> May I propose the attached patch.
>
> Points to note and possibly discuss:
> (a) Only exit codes in do_* functions have been changed.
> (b) The link to, and the version of, LSB spe
On Fri, Jan 25, 2013 at 01:35:49PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > I have applied a modified version of your patch that creates separate
> > secondary index references for search_path.
>
> This patch seems pretty bizarre. What is the difference between a
> "configuration param
Bruce Momjian writes:
> On Fri, Jan 25, 2013 at 01:35:49PM -0500, Tom Lane wrote:
>> This patch seems pretty bizarre. What is the difference between a
>> "configuration parameter" and a "run-time setting"? Why would you
>> point people to two different places for those two terms?
> Should I mak
On Fri, Jan 25, 2013 at 01:42:48PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Fri, Jan 25, 2013 at 01:35:49PM -0500, Tom Lane wrote:
> >> This patch seems pretty bizarre. What is the difference between a
> >> "configuration parameter" and a "run-time setting"? Why would you
> >> point
On 1/25/13 12:50 PM, Bruce Momjian wrote:
> On Fri, Sep 28, 2012 at 12:40:38PM -0500, Karl O. Pinc wrote:
>> Hi,
>>
>> The attached patch (against git head)
>> normalizes "search_path" as the thing indexed
>> and uses a secondary index term to distinguish
>> the configuration parameter from the run
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> However ... David is wrong to claim that it's zero-risk. It's true that
> an SRF can't contain any side-references today, but it can contain an
> outer reference. Consider a case like
>
> SELECT ... FROM a WHERE a.x IN (SELECT ... FROM b, srf(y) WHERE ...
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-generic/LSB-Core-generic/iniscrptact.html
The LSB spec doesn't say anything about a "promote" action.
An
On Fri, Jan 25, 2013 at 01:46:46PM -0500, Peter Eisentraut wrote:
> On 1/25/13 12:50 PM, Bruce Momjian wrote:
> > On Fri, Sep 28, 2012 at 12:40:38PM -0500, Karl O. Pinc wrote:
> >> Hi,
> >>
> >> The attached patch (against git head)
> >> normalizes "search_path" as the thing indexed
> >> and uses a
On Fri, Jan 25, 2013 at 1:28 PM, Bruce Momjian wrote:
> On Mon, Oct 1, 2012 at 02:04:00PM +0900, Tatsuo Ishii wrote:
>> > Tatsuo Ishii writes:
>> >> From the manual:
>> >> "An unnamed portal is destroyed at the end of the transaction"
>> >
>> > Actually, all portals are destroyed at end of trans
On Fri, Jan 25, 2013 at 1:17 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jan 25, 2013 at 12:35 PM, Andres Freund
>> wrote:
>>> I don't think the first part is problematic. Which scenario do you have
>>> in mind where that would really cause adverse behaviour? autovacuum
>>> seldomly do
On Fri, Jan 25, 2013 at 02:02:39PM -0500, Robert Haas wrote:
> On Fri, Jan 25, 2013 at 1:28 PM, Bruce Momjian wrote:
> > On Mon, Oct 1, 2012 at 02:04:00PM +0900, Tatsuo Ishii wrote:
> >> > Tatsuo Ishii writes:
> >> >> From the manual:
> >> >> "An unnamed portal is destroyed at the end of the tra
On Sat, Oct 6, 2012 at 02:20:53PM -0700, Selena Deckelmann wrote:
> On Mon, Oct 1, 2012 at 2:28 PM, Selena Deckelmann wrote:
> > On Mon, Oct 1, 2012 at 1:37 PM, Selena Deckelmann
> > wrote:
> >> On Mon, Oct 1, 2012 at 1:00 PM, Tom Lane wrote:
> >>> Selena Deckelmann writes:
> The check_t
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> SELECT ... FROM a WHERE a.x IN (SELECT ... FROM b, srf(y) WHERE ...)
Actually, this appears to fail already, at least in 9.2.2:
=> select * from (values (1)) v(a) where v.a in (select x from (values (2))
v2(a),
-> generate_series(1,a)
On Fri, Jan 25, 2013 at 9:42 AM, Robert Haas wrote:
> On Fri, Jan 25, 2013 at 11:59 AM, Tom Lane wrote:
>> Bruce Momjian writes:
>>> On Fri, Jan 25, 2013 at 02:48:37AM +0100, Andres Freund wrote:
FWIW, and I won't annoy anyone further after this email, now that its
deterministic, I sti
2013/1/20 Tom Lane :
> Robert Haas writes:
>> Yeah. We'd need to think a little bit about how to make this work,
>> since I think that adding a gajillion booleans to pg_authid will not
>> make anyone very happy. But I like the idea. GRANT
>> kill_sessions_of_other_users TO bob? GRANT install_u
On 01/25/2013 12:35:49 PM, Tom Lane wrote:
> Bruce Momjian writes:
> > I have applied a modified version of your patch that creates
> separate
> > secondary index references for search_path.
>
> This patch seems pretty bizarre. What is the difference between a
> "configuration parameter" and a "
On Fri, Jan 25, 2013 at 11:55:12AM -0800, Jeff Janes wrote:
> On Fri, Jan 25, 2013 at 9:42 AM, Robert Haas wrote:
> > On Fri, Jan 25, 2013 at 11:59 AM, Tom Lane wrote:
> >> Bruce Momjian writes:
> >>> On Fri, Jan 25, 2013 at 02:48:37AM +0100, Andres Freund wrote:
> FWIW, and I won't annoy a
On Fri, Jan 25, 2013 at 2:33 PM, Bruce Momjian wrote:
> On Fri, Jan 25, 2013 at 02:02:39PM -0500, Robert Haas wrote:
>> On Fri, Jan 25, 2013 at 1:28 PM, Bruce Momjian wrote:
>> > On Mon, Oct 1, 2012 at 02:04:00PM +0900, Tatsuo Ishii wrote:
>> >> > Tatsuo Ishii writes:
>> >> >> From the manual:
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> SELECT ... FROM a WHERE a.x IN (SELECT ... FROM b, srf(y) WHERE ...)
> Actually, this appears to fail already, at least in 9.2.2:
> => select * from (values (1)) v(a) where v.a in (select x from (values (2))
> v2(a),
> ->
On Fri, Jan 25, 2013 at 03:24:27PM -0500, Robert Haas wrote:
> On Fri, Jan 25, 2013 at 2:33 PM, Bruce Momjian wrote:
> > On Fri, Jan 25, 2013 at 02:02:39PM -0500, Robert Haas wrote:
> >> On Fri, Jan 25, 2013 at 1:28 PM, Bruce Momjian wrote:
> >> > On Mon, Oct 1, 2012 at 02:04:00PM +0900, Tatsuo
Bruce Momjian writes:
> Oops, thanks. Here is the right paragraph, same issue:
> If successfully created, a named portal object lasts till the end of the
> current transaction, unless explicitly destroyed. An unnamed portal is
> destroyed at the end of the transaction, or as soon as
On Thu, Jan 10, 2013 at 1:06 AM, Jeff Davis wrote:
> On Tue, 2012-12-04 at 01:03 -0800, Jeff Davis wrote:
>> For now, I rebased the patches against master, and did some very minor
>> cleanup.
>
> I think there is a problem here when setting PD_ALL_VISIBLE. I thought I
> had analyzed that before, b
On Fri, Jan 25, 2013 at 03:29:17PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Oops, thanks. Here is the right paragraph, same issue:
>
> > If successfully created, a named portal object lasts till the end of the
> > current transaction, unless explicitly destroyed. An unnamed po
Bruce Momjian writes:
>> diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
>> index 6b202e0..0677059 100644
>> --- a/src/backend/utils/misc/guc.c
>> +++ b/src/backend/utils/misc/guc.c
>> @@ -5150,7 +5150,7 @@ set_config_option(const char *name, const char *value,
>> elevel =
On Fri, Jan 25, 2013 at 03:35:59PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> >> diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
> >> index 6b202e0..0677059 100644
> >> --- a/src/backend/utils/misc/guc.c
> >> +++ b/src/backend/utils/misc/guc.c
> >> @@ -5150,7 +5150,7
A hashed SubPlan will not be used if it would need more than one
batch. Is there a fundamental reason for that, or just that no one
got around to adding it?
A small decrease in work_mem leads to a 38000 fold change in estimated
query execution (and that might be accurate, as the actual change in
2013/1/15 Peter Eisentraut :
> On Tue, 2012-10-09 at 20:45 -0400, Peter Eisentraut wrote:
>> About that plugins directory ($libdir/plugins) ... I don't think we
>> ever
>> really got that to work sensibly. I don't remember the original
>> design
>> discussion, but I have seen a number of explanati
FYI, the FET timezone abbeviation was added in this commit:
http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=7127293a5d9f655ce3ec7e009f18bac8d3d0bc1c
---
On Sat, Oct 6, 2012 at 11:15:49AM +0200, M
On Wed, Oct 10, 2012 at 11:49:50AM -0700, Josh Berkus wrote:
>
> >> 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 check
On 1/25/13 12:24 PM, Andres Freund wrote:
> On 2013-01-26 02:21:00 +0900, Fujii Masao wrote:
>> The process which deletes the old WAL files is the checkpointer. The
>> checkpointer can access to the shared memory and know the location
>> of the WAL record which has been already replicated to the st
On Thu, Oct 11, 2012 at 07:06:15PM -0400, Tom Lane wrote:
> Markus Wanner writes:
> > On 10/11/2012 03:11 PM, Tom Lane wrote:
> >> The original design intention was that rm_desc should not attempt to
> >> print any such data, but obviously some folks didn't get the word.
>
> > FWIW: in case the s
Jeff Janes writes:
> A hashed SubPlan will not be used if it would need more than one
> batch. Is there a fundamental reason for that, or just that no one
> got around to adding it?
It can't, really. Batching a hash join requires freedom to reorder the
rows on both sides of the join. A SubPlan
On Sat, Oct 20, 2012 at 12:27:16PM +0100, Simon Riggs wrote:
> On 20 October 2012 07:43, Abhijit Menon-Sen wrote:
> > At 2012-10-15 10:28:17 -0400, robertmh...@gmail.com wrote:
> >>
> >> > Is there any concise description that applies? […]
> >>
> >> I don't think there is. I think we need to repl
On 1/24/13 6:25 PM, Bruce Momjian wrote:
> 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
s
On Fri, Oct 12, 2012 at 04:42:46PM -0400, Stephen Frost wrote:
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Fri, Oct 12, 2012 at 03:57:15PM -0400, Stephen Frost wrote:
> > > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > > > There was also some discussion of fixing the name-check to be indexable,
1 - 100 of 120 matches
Mail list logo
