On 29/08/14 08:56, Alvaro Herrera wrote:
Robert Haas wrote:
I agree that you might not like that. But you might not like having
the table vacuumed slower than the configured rate, either. My
impression is that the time between vacuums isn't really all that
negotiable for some people. I had o
(2014/08/26 12:20), Etsuro Fujita wrote:
(2014/08/25 21:58), Albe Laurenz wrote:
I played with it, and apart from Hanada's comments I have found the
following:
test=> EXPLAIN (ANALYZE, VERBOSE) UPDATE rtest SET val=NULL WHERE id > 3;
(2014/08/13 12:40), Etsuro Fujita wrote:
(2014/08/12 18:34), Shigeru Hanada wrote:
Issues addressed by Eitoku-san were fixed properly, but he found a bug
and a possible enhancement in the v2 patch.
* push-down check misses delete triggers
update_is_pushdown_safe() seems to have a bug that it
On Wed, Aug 27, 2014 at 7:43 PM, Peter Geoghegan wrote:
> There are some restrictions on what this auxiliary update may do, but
> FWIW there are considerably fewer than those that the equivalent MySQL
> or SQLite feature imposes on their users.
I realized that I missed a few cases here. For one
Haribabu Kommi writes:
> Thanks for your review. Please find the rebased patch to latest HEAD.
Committed with minor (mostly cosmetic) alterations.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscripti
On 08/28/2014 03:46 AM, Claudio Freire wrote:
> You can't with mean and stddev, only with associative aggregates.
>
> That's min, max, sum, bit_and, bit_or, bool_and, bool_or, count.
You could with a new helper function to merge the temporary states for
each scan though.
In the case of mean, for
On 08/29/2014 04:59 AM, Kevin Grittner wrote:
> I just took a quick look at the spec to refresh my memory, and it
> seems to require that the WITH TIME ZONE types store UTC (I suppose
> for fast comparisons), it requires the time zone in the form of a
> hour:minute offset to be stored with it, so y
Not just a one line patch, a one character patch.
Use ?= instead of = in distdir assignment, so it can be overridden on
the command line when building dist tarballs with patches.
Yes, you can just modify GNUMakefile.in, but that's extra noise in a
diff, adds merge conflicts, etc.
Please apply. S
On Thu, Aug 28, 2014 at 03:25:49PM -0700, Josh Berkus wrote:
> On 08/28/2014 02:25 PM, Kevin Grittner wrote:
> > But the standard doesn't say anything about storing a time zone
> > *name* or *abbreviation* -- it requires that it be stored as UTC
> > with the *offset* (in hours and minutes). That m
On 28 August 2014 23:45, Tom Lane wrote:
> I don't claim to be an expert on this stuff, but I had the idea that
> multithreaded environments were supposed to track signal state per-thread
> not just per-process, precisely because of issues like this.
After some googling, I found reply #3 in
https
Vik Fearing wrote:
> Here are two patches for this.
>
> The first one, reindex_user_tables.v1.patch, implements the variant that
> only hits user tables, as suggested by you.
>
> The second one, reindex_no_dbname.v1.patch, allows the three
> database-wide variants to omit the database name (vote
Thomas Munro writes:
> My theory is that if two connections accessed by different threads get
> shut down around the same time, there is a race scenario where each of
> them fails to write to its socket, sees errno == EPIPE and then sees a
> pending SIGPIPE with sigpending(), but only one thread r
Kevin Grittner writes:
> But the standard doesn't say anything about storing a time zone
> *name* or *abbreviation* -- it requires that it be stored as UTC
> with the *offset* (in hours and minutes). That makes it pretty
> close to what we have -- it's all about a difference in
> presentation. A
On 08/28/2014 02:25 PM, Kevin Grittner wrote:
> But the standard doesn't say anything about storing a time zone
> *name* or *abbreviation* -- it requires that it be stored as UTC
> with the *offset* (in hours and minutes). That makes it pretty
> close to what we have -- it's all about a difference
Alvaro Herrera wrote:
> Kevin Grittner wrote:
>
>> But the standard doesn't say anything about storing a time zone
>> *name* or *abbreviation* -- it requires that it be stored as UTC
>> with the *offset* (in hours and minutes). That makes it pretty
>> close to what we have -- it's all about a dif
On Thu, Aug 28, 2014 at 3:34 AM, Fujii Masao wrote:
> Theoretically it's not safe without a barrier on a machine with weak
> memory ordering. No?
Why not?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-
On 26.8.2014 21:38, Jeff Davis wrote:
> On Tue, 2014-08-26 at 12:39 +0300, Heikki Linnakangas wrote:
>> I think this is enough for this commitfest - we have consensus on
>> the design. For the next one, please address those open items, and
>> resubmit.
>
> Agreed, return with feedback.
>
> I need
On Thu, Aug 28, 2014 at 4:56 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> I agree that you might not like that. But you might not like having
>> the table vacuumed slower than the configured rate, either. My
>> impression is that the time between vacuums isn't really all that
>> negotiable
Hello,
A while back someone showed me a program blocking in libpq 9.2 on
Solaris 11, inside sigwait called by pq_reset_sigpipe. It had
happened a couple of times before during a period of
instability/crashing with a particular DB (a commercial PostgreSQL
derivative, but the client was using regul
Kevin Grittner wrote:
> But the standard doesn't say anything about storing a time zone
> *name* or *abbreviation* -- it requires that it be stored as UTC
> with the *offset* (in hours and minutes). That makes it pretty
> close to what we have -- it's all about a difference in
> presentation. An
Alvaro Herrera wrote:
> Kevin Grittner wrote:
>
>> I just took a quick look at the spec to refresh my memory, and it
>> seems to require that the WITH TIME ZONE types store UTC (I suppose
>> for fast comparisons), it requires the time zone in the form of a
>> hour:minute offset to be stored with i
Kevin Grittner wrote:
> I just took a quick look at the spec to refresh my memory, and it
> seems to require that the WITH TIME ZONE types store UTC (I suppose
> for fast comparisons), it requires the time zone in the form of a
> hour:minute offset to be stored with it, so you can determine the
>
"k...@rice.edu" wrote:
> On Thu, Aug 28, 2014 at 03:33:56PM -0400, Bruce Momjian wrote:
>> So the standard requires storing of original timezone in the
>> data type? I was not aware of that.
>
> I do not have a copy of the SQL 92 spec, but several references
> to the spec mention that it define
Robert Haas wrote:
> I agree that you might not like that. But you might not like having
> the table vacuumed slower than the configured rate, either. My
> impression is that the time between vacuums isn't really all that
> negotiable for some people. I had one customer who had horrible bloat
>
"k...@rice.edu" writes:
> On Thu, Aug 28, 2014 at 03:33:56PM -0400, Bruce Momjian wrote:
>> So the standard requires storing of original timezone in the data type?
>> I was not aware of that.
> I do not have a copy of the SQL 92 spec, but several references to the
> spec mention that it defined
On Thu, Aug 28, 2014 at 03:33:56PM -0400, Bruce Momjian wrote:
> On Thu, Aug 28, 2014 at 11:26:53AM -0700, Kevin Grittner wrote:
> > Steve Crawford wrote:
> >
> > > I have always considered "timestamp with time zone" to be a bad
> > > description of that data type but it appears to be a carryover
On Thu, Aug 28, 2014 at 11:26:53AM -0700, Kevin Grittner wrote:
> Steve Crawford wrote:
>
> > I have always considered "timestamp with time zone" to be a bad
> > description of that data type but it appears to be a carryover
> > from the specs. It is really a "point in time"
>
> I agree. While
On Thu, Aug 28, 2014 at 1:36 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> Now, in the case where you are setting an overall limit, there is at
>> least an argument to be made that you can determine the overall rate
>> of autovacuum-induced I/O activity that the system can tolerate, and
>> set
On 08/28/2014 09:05 PM, Peter Geoghegan wrote:
On Thu, Aug 28, 2014 at 7:29 AM, Andreas Karlsson wrote:
Personally I would find it surprising if RETURNING did not also return the
updated tuples. In many use cases for upsert the user does not care if the
row was new or not.
I'm not attached to
On Thu, Aug 28, 2014 at 7:29 AM, Andreas Karlsson wrote:
> Personally I would find it surprising if RETURNING did not also return the
> updated tuples. In many use cases for upsert the user does not care if the
> row was new or not.
I'm not attached to that particular behavior, but it does seem k
On 08/27/2014 09:53 AM, Andres Freund wrote:
>> > Perhaps instead of doing this in-core it would be better to make log
>> > handling more extensible? I'm thinking add a specific "binary" format and
>> > an external tool that can parse that and do whatever the user wants with
>> > it. That means
2014-08-28 20:26 GMT+02:00 Kevin Grittner :
> Steve Crawford wrote:
>
> > I have always considered "timestamp with time zone" to be a bad
> > description of that data type but it appears to be a carryover
> > from the specs. It is really a "point in time"
>
> I agree. While what timestamptz impl
Steve Crawford wrote:
> I have always considered "timestamp with time zone" to be a bad
> description of that data type but it appears to be a carryover
> from the specs. It is really a "point in time"
I agree. While what timestamptz implements is a very useful data
type, I think it was a very
I tried that by setting:
vm.dirty_expire_centisecs = 100
vm.dirty_writeback_centisecs = 100
So it should start writing returned buffers at most 2s after they are
returned, if I understood the doc correctly, instead of at most 35s.
The result is that with a 5000s 25tps pretty small load (th
On Aug 27, 2014, at 4:20 PM, Tom Lane wrote:
> Yeah, but plpgsql.so is mentioned nowhere on your command line.
>
> I'm not too sure about the dynamic-linking rules on OS X, but I'd not be
> surprised if you need to provide a reference to plpgsql.so in its final
> installed location (ie, a refere
On Aug 27, 2014, at 9:53 PM, Ashesh Vashi wrote:
> Please add -arch x86_64 to your LD_FLAGS and CFLAGS in your make file.
This made no difference:
LDFLAGS = -arch x86_64
CFLAGS = -arch x86_64
Best,
David
signature.asc
Description: Message signed with OpenPGP using GPGMail
Robert Haas wrote:
> Now, in the case where you are setting an overall limit, there is at
> least an argument to be made that you can determine the overall rate
> of autovacuum-induced I/O activity that the system can tolerate, and
> set your limits to stay within that budget, and then let the sys
On 08/28/2014 01:51 AM, rohtodeveloper wrote:
Hi,all
I have a question about data type "timestamp with time zone".
Why data of timestamptz does not store value of timezone passed to it?
Considering the following example.
postgres=# select '2014-08-28 14:30:30.423602+02'::timestamp with time
z
On Wed, Aug 27, 2014 at 2:55 AM, Magnus Hagander wrote:
> On Wed, Aug 27, 2014 at 5:16 AM, Fujii Masao wrote:
>> On Wed, Aug 27, 2014 at 6:16 AM, Magnus Hagander wrote:
>>> On Tue, Aug 26, 2014 at 10:46 PM, Andres Freund
>>> wrote:
On 2014-08-26 16:41:44 -0400, Peter Eisentraut wrote:
>>>
On Mon, Aug 25, 2014 at 12:33 PM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
> On 08/25/2014 01:07 PM, Andres Freund wrote:
>
>> On 2014-08-25 13:02:50 +0300, Heikki Linnakangas wrote:
>>
>>> But actually, I wonder if we should delegate the whole hostname matching
>>> to
>>> OpenSSL? The
On 08/28/2014 09:09 AM, Alvaro Herrera wrote:
> Josh Berkus wrote:
>> On 04/16/2014 01:30 PM, Alvaro Herrera wrote:
>>> Josh Berkus wrote:
> You can see the current multixact value in pg_controldata output. Keep
> timestamped values of that somewhere (a table?) so that you can measure
On Thu, Aug 28, 2014 at 12:22 PM, Fujii Masao wrote:
> On Thu, Aug 28, 2014 at 11:14 PM, Tom Lane wrote:
>> Michael Paquier writes:
>>> The patch attached fixes pg_upgrade by putting quotes when generating
>>> reloptions and it passes check-world. I imagine that having quotes by
>>> default in t
On Mon, Aug 25, 2014 at 12:02 PM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
> On 08/24/2014 03:11 PM, Alexey Klyukin wrote:
>
>> On Wed, Aug 20, 2014 at 11:53 AM, Heikki Linnakangas <
>> hlinnakan...@vmware.com> wrote:
>>
>>>
>>> The patch doesn't seem to support wildcards in alternati
On Thu, Aug 28, 2014 at 11:14 PM, Tom Lane wrote:
> Michael Paquier writes:
>> The patch attached fixes pg_upgrade by putting quotes when generating
>> reloptions and it passes check-world. I imagine that having quotes by
>> default in the value of reloptions in pg_class is the price to pay for
>
On Tue, Aug 26, 2014 at 12:19 PM, Alvaro Herrera
wrote:
>> >On Mon, May 5, 2014 at 11:57 AM, Mark Kirkwood
>> > wrote:
>> >I could think of 2 ways to change this:
>> >
>> >a. if user has specified cost_limit value for table, then it just uses it
>> > rather than rebalancing based on value of s
Josh Berkus wrote:
> On 04/16/2014 01:30 PM, Alvaro Herrera wrote:
> > Josh Berkus wrote:
> >>
> >>> You can see the current multixact value in pg_controldata output. Keep
> >>> timestamped values of that somewhere (a table?) so that you can measure
> >>> consumption rate. I don't think we provid
On Thu, Aug 28, 2014 at 3:27 AM, Fabien COELHO wrote:
> Hello Aidan,
>
>
>> If all you want is to avoid the write storms when fsyncs start happening
>> on
>> slow storage, can you not just adjust the kernel vm.dirty* tunables to
>> start making the kernel write out dirty buffers much sooner instea
On 2014-08-28 14:04:27 +0200, Petr Jelinek wrote:
> On 28/08/14 13:20, Andres Freund wrote:
> >Hi,
> >
> >Stuff I wondered about:
> >* How about making it --help=variables instead of --help-variables?
>
> -1, help is not a variable to be assigned imho
I don't think variable assignment is a good m
On 2014-08-28 10:30:30 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-08-28 10:20:08 -0400, Tom Lane wrote:
> >> Having said that, there's a nearby thread about inventing a "SUBACKEND"
> >> GUC category, and that's likely what we'd really want to use here, just
> >> on the grounds that
Andres Freund writes:
> On 2014-08-28 10:20:08 -0400, Tom Lane wrote:
>> Having said that, there's a nearby thread about inventing a "SUBACKEND"
>> GUC category, and that's likely what we'd really want to use here, just
>> on the grounds that superusers would know better.
> What we really want is
On 2014-08-28 10:20:08 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-08-28 10:12:19 -0400, Tom Lane wrote:
> >> Hm. Yeah, I guess there is some use in holding onto the values that were
> >> actually used to initialize the current session, or at least there would
> >> be if we exposed
On 08/28/2014 04:43 AM, Peter Geoghegan wrote:
-- Nesting within wCTE:
WITH t AS (
INSERT INTO z SELECT i, 'insert'
FROM generate_series(0, 16) i
ON CONFLICT UPDATE SET v = v || 'update' -- use of
operators/functions in targetlist
RETURNING * -- only projects inserted tuples,
On Wed, Aug 27, 2014 at 5:19 PM, Fujii Masao wrote:
>
> On Sat, Aug 23, 2014 at 3:44 PM, Amit Kapila
wrote:
> > On Tue, Aug 5, 2014 at 8:04 PM, Fujii Masao
wrote:
> > Changing PGC_SU_BACKEND parameter (log_connections) is
> > visible even with a non-super user client due to above code.
> > Shoul
On Thu, Aug 28, 2014 at 4:14 PM, Andres Freund wrote:
> On 2014-08-28 10:12:19 -0400, Tom Lane wrote:
>> Magnus Hagander writes:
>> > On Thu, Aug 28, 2014 at 4:05 PM, Tom Lane wrote:
>> >> Why would they need to be BACKEND, as opposed to just PGC_SIGHUP?
>>
>> > I just thought semantically - bec
Andres Freund writes:
> On 2014-08-28 10:12:19 -0400, Tom Lane wrote:
>> Hm. Yeah, I guess there is some use in holding onto the values that were
>> actually used to initialize the current session, or at least there would
>> be if we exposed the cert contents in any fashion.
> Won't that allow t
On 2014-08-28 10:12:19 -0400, Tom Lane wrote:
> Magnus Hagander writes:
> > On Thu, Aug 28, 2014 at 4:05 PM, Tom Lane wrote:
> >> Why would they need to be BACKEND, as opposed to just PGC_SIGHUP?
>
> > I just thought semantically - because they do not change in a running
> > backend. Any running
Michael Paquier writes:
> The patch attached fixes pg_upgrade by putting quotes when generating
> reloptions and it passes check-world. I imagine that having quotes by
> default in the value of reloptions in pg_class is the price to pay for
> supporting units. If this is not considered as a correc
Magnus Hagander writes:
> On Thu, Aug 28, 2014 at 4:05 PM, Tom Lane wrote:
>> Why would they need to be BACKEND, as opposed to just PGC_SIGHUP?
> I just thought semantically - because they do not change in a running
> backend. Any running backend will continue with encryption set up
> based on t
On Thu, Aug 28, 2014 at 4:05 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> On Thu, Aug 28, 2014 at 3:20 AM, Robert Haas wrote:
>>> On Wed, Aug 27, 2014 at 6:40 AM, Magnus Hagander
>>> wrote:
Key and cert files are loaded in the postmaster. We'd need to change
that.
>
>>> Why?
>
>>
Magnus Hagander writes:
> On Thu, Aug 28, 2014 at 3:20 AM, Robert Haas wrote:
>> On Wed, Aug 27, 2014 at 6:40 AM, Magnus Hagander wrote:
>>> Key and cert files are loaded in the postmaster. We'd need to change
>>> that.
>> Why?
> Hmm. That's actually a good point. Not sure I have an excuse. Th
Michael Paquier wrote:
> This remark is just to limit the amount of trash in the database used
> for regression tests. But then if we'd remove everything we would lack
> handy material for tests on utilities like database-wide thingies of
> the type VACUUM, REINDEX, pg_dump, etc. And we can just d
rohtodeveloper wrote
> I have a question about data type "timestamp with time zone".
> Why data of timestamptz does not store value of timezone passed to it?
>
> The timezone of output(+08) is different with the original input
> value(+02).
> It seems not to be good behavior.
Its good for the inu
Hello,
> On Thu, 2014-07-03 at 13:05 +0900, Kyotaro HORIGUCHI wrote:
> > For the earlier than 9.4, no one seems to have considered
> > seriously to use local_preload_library via ALTER statements so
> > far. Only document fix would be enough for them.
>
> I think local_preload_libraries never actu
On 08/26/2014 12:44 PM, Emre Hasegeli wrote:
I agree with you that we can support other join type and anti join later,
If others don’t have any objection in doing other parts later I will mark as "Ready
For Committer".
I updated the patch to cover semi and anti joins with eqjoinsel_semi().
I t
Hello, sorry for the dazed reply in the previous mail.
I made revised patch for this issue.
Attached patches are following,
- 0001_Revise_socket_emulation_for_win32_backend.patch
Revises socket emulation on win32 backend so that each socket
can have its own blocking mode state.
- 0002_Allo
2014-08-28 14:22 GMT+02:00 Fujii Masao :
> On Thu, Aug 28, 2014 at 5:48 AM, Pavel Stehule
> wrote:
> > comments?
>
> +fprintf(output, _(" ECHO control what input is
> written to standard output [all, queries]\n"));
>
> The valid values in the help messages should be consistent
On Thu, Aug 28, 2014 at 3:20 AM, Robert Haas wrote:
> On Wed, Aug 27, 2014 at 6:40 AM, Magnus Hagander wrote:
>> On Wed, Aug 27, 2014 at 11:56 AM, Alexey Klyukin wrote:
>>> Greetings,
>>>
>>> Is there a strong reason to disallow reloading server key and cert files
>>> during the PostgreSQL reloa
On Thu, Aug 28, 2014 at 11:20 AM, Tom Lane wrote:
> Pavan Deolasee writes:
> > Can some kind of compiler optimisation reorder things such that the "else
> > if" expression is evaluated using the old, uninitialised value of optval?
>
> Any such behavior is patently illegal per the C standard.
T
On Thu, Aug 28, 2014 at 5:48 AM, Pavel Stehule wrote:
> comments?
+fprintf(output, _(" ECHO control what input is
written to standard output [all, queries]\n"));
The valid values in the help messages should be consistent with
the values that the tab-completion displays. So in
On 28/08/14 13:20, Andres Freund wrote:
Hi,
Stuff I wondered about:
* How about making it --help=variables instead of --help-variables?
-1, help is not a variable to be assigned imho
* Do we really need the 'Report bugs to' blurb for --help-variables?
Probably not.
* Since we're not exha
2014-08-28 13:20 GMT+02:00 Andres Freund :
> Hi,
>
> On 2014-08-27 22:48:54 +0200, Pavel Stehule wrote:
> > Hi
> >
> > I chose \? xxx, because it is related to psql features. I wrote commands:
> >
> > \? options
> > \? variables
> >
> > comments?
>
> Generall I like it.
>
> Some stuff I changed:
>
On 2014-08-28 13:20:07 +0200, Andres Freund wrote:
> I've attached a incremental patch.
Apparently I didn't attach the patch, as so much a file containing the
name of the patchfile...
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Develo
On Thu, Aug 28, 2014 at 8:20 PM, Andres Freund wrote:
> Hi,
>
> On 2014-08-27 22:48:54 +0200, Pavel Stehule wrote:
>> Hi
>>
>> I chose \? xxx, because it is related to psql features. I wrote commands:
>>
>> \? options
>> \? variables
>>
>> comments?
>
> Generall I like it.
>
> Some stuff I changed
On Tue, Aug 26, 2014 at 4:55 AM, Heikki Linnakangas
wrote:
> On 08/25/2014 10:48 PM, Heikki Linnakangas wrote:
>>
>> On 08/25/2014 09:22 PM, Fujii Masao wrote:
>>>
>>> On Tue, Aug 26, 2014 at 1:34 AM, Heikki Linnakangas
>>> wrote:
I agree that refactoring this would be nice in the long-
(2014/08/27 23:05), Tom Lane wrote:
> I wrote:
>> Robert Haas writes:
>>> Hmm, I'm worried that may be an API contract violation.
> Actually, there's another problem there. What of UPDATE or DELETE with a
> LIMIT clause, which is something that seems to be coming down the pike:
> https://commitf
Hi,
On 2014-08-27 22:48:54 +0200, Pavel Stehule wrote:
> Hi
>
> I chose \? xxx, because it is related to psql features. I wrote commands:
>
> \? options
> \? variables
>
> comments?
Generall I like it.
Some stuff I changed:
* I rephrased the sgml changes
* s/Printing options/Display options/.
On 2014-08-26 23:56:10 -0400, Peter Eisentraut wrote:
> On Tue, 2014-08-26 at 02:05 +0200, Andres Freund wrote:
> > Currently running "make -j16 all check" in contrib/ results in a mess
> > because
> > all pg_regress invocations fight over the same port. Adding a simple
> > .NOTPARALLEL: check-%-re
Hi all
Per the protocol todo:
https://wiki.postgresql.org/wiki/Todo#Wire_Protocol_Changes
do you think it's reasonable to allow for delayed sending of big varlena
values and arrays in the protocol?
The JDBC spec already has support for this in arrays, XML, and binary
blobs, but AFAIK the backe
(2014/08/27 22:56), Robert Haas wrote:
On Mon, Aug 25, 2014 at 8:58 AM, Albe Laurenz wrote:
Reading the code, I noticed that the pushed down UPDATE or DELETE statement is
executed
during postgresBeginForeignScan rather than during postgresIterateForeignScan.
It probably does not matter, but is
(2014/08/22 11:51), Noah Misch wrote:
On Wed, Aug 20, 2014 at 08:11:01PM +0900, Etsuro Fujita wrote:
(2014/07/02 11:23), Noah Misch wrote:
Your chosen ANALYZE behavior is fair, but the messaging from a database-wide
ANALYZE VERBOSE needs work:
INFO: analyzing "test_foreign_inherit.parent"
INF
Hi,all
I have a question about data type "timestamp with time zone".
Why data of timestamptz does not store value of timezone passed to it?
Considering the following example.
postgres=# select '2014-08-28 14:30:30.423602+02'::timestamp with time zone;
timestamptz
-
On Thu, Aug 28, 2014 at 12:03 AM, Kevin Grittner wrote:
>> In essence, make the relations work like PL/pgSQL
>> variables do. If you squint a little, the new/old relation is a variable
>> from the function's point of view, and a parameter from the
>> planner/executor's point of view. It's just a v
On Thu, Jun 19, 2014 at 5:29 PM, Ian Barwick wrote:
> On 12/06/14 20:37, Fujii Masao wrote:
>>
>> On Wed, Jun 11, 2014 at 11:55 PM, Tom Lane wrote:
>>>
>>> Andres Freund writes:
Your wish just seems like a separate feature to me. Including
replication commands in 'all' seems corre
On Thu, Aug 28, 2014 at 2:44 AM, Jim Nasby wrote:
> On 8/27/14, 7:33 AM, Fujii Masao wrote:
>>
>> On Tue, Aug 19, 2014 at 1:07 AM, Robert Haas
>> wrote:
>>>
>>> On Fri, Aug 15, 2014 at 7:17 AM, Fujii Masao
>>> wrote:
On Fri, Aug 15, 2014 at 3:40 AM, Andres Freund
wrote:
>
>>>
On 28 August 2014 00:25, Alvaro Herrera wrote:
> Thomas Munro wrote:
>
>> Thanks, I hadn't seen this, I should have checked the archives better.
>> I have actually already updated my patch to handle EvalPlanQualFetch
>> with NOWAIT and SKIP LOCKED with isolation specs, see attached. I
>> will com
On Thu, Aug 28, 2014 at 4:20 PM, Fujii Masao wrote:
> I don't have strong opinion about this. There are many tables which
> regression test creates but doesn't drop. But if you strongly think that
> the table must be dropped, I'm OK with that.
This remark is just to limit the amount of trash in th
On Thu, Aug 28, 2014 at 12:55 PM, Michael Paquier
wrote:
> On Wed, Aug 27, 2014 at 10:59 PM, Alvaro Herrera
> wrote:
>>
>> Not necessarily, because it's harmless. It's there for purely
>> aesthetical reasons, so it's your choice whether to add it or not.
>> Having it there is slightly easier on
On Wed, Aug 27, 2014 at 2:46 PM, Rajeev rastogi
wrote:
> I have done some more review, below are my comments:
Thanks!
> 1. There are currently two loops on *num_sync, Can we simplify the function
> SyncRepGetSynchronousNodes by moving the priority calculation inside the
> upper loop
>
88 matches
Mail list logo
