Hi!
Thanks for your work on this patch!
On Tue, Mar 12, 2013 at 8:03 PM, Heikki Linnakangas wrote:
> So, after some hacking, I ended up with this version. I find it more
> readable, I hope I didn't miss anything. This seems to produce results that
> are close, but not identical, to the original
On 03/12/2013 06:27 AM, Craig Ringer wrote:
>> > Think also about the case where someone wants to change multiple
>> > values together and having just some set and not others would be
>> > inconsistent.
> Yeah, that's a killer. The reload would need to be scheduled for COMMIT
> time, it can't be do
willing to be convinced to exclude temp tables again.
Regards,
Jeff Davis
checksums-20130312.patch.gz
Description: GNU Zip compressed data
replace-tli-with-checksums-20130312.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
On Tuesday, March 12, 2013 9:37 PM Tom Lane wrote:
> Greg Stark writes:
> > As Craig intimated, the minimal grammar impact would be simply
>
> > BEGIN;
> > set persistent maintenance_work_mem='2GB';
> > set persistent work_mem='2GB';
> > COMMIT;
>
> > Sending the sighup at transaction end seems
Palle Girgensohn writes:
> ... I got lots of space freed
> up, but it seems that after that the disk usage grows linearly (it seems
> to leave many inodes unreferenced).
Hm. We've seen issues in the past with PG processes failing to close
no-longer-useful files promptly, but ...
> Strange thing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
Running postgresql-9.2.2 on FreeBSD 9.1 using vanilla ufs file system.
I have the postgresql base/ on the /usr disk, and a separate volume /opt
where the default tablespace resides. I found many databases that had
not used the default tablespace,
Tom,
> If you're proposing changing the contents of the default prompt, I think
> that has very little chance of passing. A new option for something to
> add into a custom prompt might get accepted. I'm not sure that that
> approach would do much for the scenario you describe, since it's
> unlik
Alex writes:
> Today when I get back home and connected to my psql prompt I've left
> running under $terminal_multiplexor I've run some SQL, but no output did
> appear on my screen. I have immediately realized that it must be
> sending it to a file instead of STDOUT as I have instructed it earlie
Hello fellow hackers,
Today when I get back home and connected to my psql prompt I've left
running under $terminal_multiplexor I've run some SQL, but no output did
appear on my screen. I have immediately realized that it must be
sending it to a file instead of STDOUT as I have instructed it earl
> The behavior of timestamp-plus-interval is certainly supported by that
> argument, but I'm less convinced about timestamp-minus-timestamp. The
> raw result of the timestamp subtraction here is 71 hours (not the normal
> 72). Perhaps it should be outputting it that way instead of converting
> t
Albe Laurenz writes:
> Do you think that it is possible to insert remote defaults
> by omitting columns like this:
> INSERT INTO foreigntable (col1, col3) VALUES (a, c);
Well, that's how it works right now, but it's not good that it's
inconsistent with the explicit-DEFAULT case.
> If that can be
Josh Berkus writes:
>> and extract(day) from that gives -2 not -3. You could argue that this
>> definition of timestamp subtraction isn't too consistent with the
>> timestamp-plus-interval operator, and you'd be right; but I doubt we'd
>> consider changing it now.
> We specifically added that fe
Daniel Farina writes:
> Okay, I see. So inverting the thinking I wrote earlier: how about
> hearkening carefully to any ParameterStatus messages on the local side
> before entering the inner loop of dblink.c:materializeResult as to set
> the local GUC (and carefully dropping it back off after
> m
On Mon, Mar 11, 2013 at 7:04 PM, Tom Lane wrote:
> Daniel Farina writes:
>> I will try to make time for this, although it seems like the general
>> approach should match pgsql_fdw if possible. Is the current thinking
>> to forward the settings and then use the GUC hooks to track updates?
>
> Tha
> and extract(day) from that gives -2 not -3. You could argue that this
> definition of timestamp subtraction isn't too consistent with the
> timestamp-plus-interval operator, and you'd be right; but I doubt we'd
> consider changing it now.
We specifically added that feature to support productio
Michael Paquier writes:
> On Tue, Mar 12, 2013 at 3:11 PM, Michael Paquier
> wrote:
>> postgres=# select extract(day from ((CAST(-3 || 'day' as interval)+now())
>> - now()));
>> date_part
>> ---
>> -2
>> (1 row)
>> Here I believe that the correct result should be -3.
> Sorry for the nois
Hi,
Attached is a small patch to test corner cases related to Sequences
(basically aimed at increasing code-coverage of sequence.sql in regression
tests).
Look forward to any and all feedback.
--
Robins
Tharakan
commit-sequence.patch
Description: Binary data
--
Sent via pgsql-hackers mailing
Greg Stark writes:
> As Craig intimated, the minimal grammar impact would be simply
> BEGIN;
> set persistent maintenance_work_mem='2GB';
> set persistent work_mem='2GB';
> COMMIT;
> Sending the sighup at transaction end seems like a fairly safe thing
> to do too. It's hard to imagine it failing
On 01.03.2013 16:22, Alexander Korotkov wrote:
I've been staring at this code for a very long time now, trying to
understand how the math in calc_hist_selectivity_contained works. I
think I understand it now, but it probably needs a lot more comments and
perhaps some refactoring, so that the next
On Tue, Mar 12, 2013 at 9:06 AM, Greg Smith wrote:
> That's jumping right over a few rounds of simpler ways to do this, and just
> going right to the approach we know allows adding more such options later
> with minimal grammar impact.
As Craig intimated, the minimal grammar impact would be simpl
Etsuro Fujita wrote:
> I ran into a typo in the reference page on the SELECT command. Please find
> attached a patch.
Thanks for the note -- I fixed this in a different way.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On Mon, Mar 11, 2013 at 9:13 PM, Greg Stark wrote:
> On Thu, Mar 7, 2013 at 12:51 AM, Jim Nasby wrote:
>> Something worth considering on this... I suspect it's possible to use an
>> index-only scan to do this, regardless of whether the heap page is all
>> visible. The reason is that the newly cre
On 2013-03-11 20:28:05 -0400, Peter Eisentraut wrote:
> On Mon, 2013-03-11 at 18:11 +0100, Andres Freund wrote:
> > If we don't find a better solution, yes. Why don't we lookup type
> > input/ouput function for parameters and return type during CREATE
> > FUNCTION? That should solve the issue in a
On 01.03.2013 16:22, Alexander Korotkov wrote:
These changes were made in attached patch.
Thanks.
I've been staring at this code for a very long time now, trying to
understand how the math in calc_hist_selectivity_contained works. I
think I understand it now, but it probably needs a lot more
Tom Lane wrote:
>> Thom Brown writes:
>>> Out of curiosity, is there any way to explicitly force a foreign
>>> DEFAULT with column-omission?
> I've concluded that the "ideal behavior" probably is that if you have
> declared a DEFAULT expression for a foreign table's column, then that's
> what the
On 3/11/13 12:19 PM, Greg Stark wrote:
Think also about the case where someone wants to change multiple
values together and having just some set and not others would be
inconsistent.
Isn't that an argument for syntax to make an exception though? If
starting from a blank slate I would say this
On Tue, Mar 12, 2013 at 3:11 PM, Michael Paquier
wrote:
> postgres=# select extract(day from ((CAST(-3 || 'day' as interval)+now())
> - now()));
> date_part
> ---
> -2
> (1 row)
> Here I believe that the correct result should be -3.
>
Note that it passes with values upper than -2
27 matches
Mail list logo
