On Thu, May 29, 2014 at 11:32 AM, Peter Geoghegan wrote:
> On Wed, May 28, 2014 at 10:49 PM, Fujii Masao
> wrote:
> > You're concerned about the scenario using pg_upgrade?
>
Yeah - I was.
> I'm not sure the detail
> > of pg_upgrade. But if it doesn't work properly, we should have gotten
> > th
On Wed, May 28, 2014 at 10:49 PM, Fujii Masao wrote:
> You're concerned about the scenario using pg_upgrade? I'm not sure the detail
> of pg_upgrade. But if it doesn't work properly, we should have gotten
> the trouble
I'm not worried about pg_upgrade, because by design pg_stat_statements
will di
On Thu, May 29, 2014 at 1:01 PM, Ashesh Vashi
wrote:
> On Thu, May 29, 2014 at 8:52 AM, Fujii Masao wrote:
>>
>> On Thu, May 29, 2014 at 4:55 AM, Tomas Vondra wrote:
>> > On 28.5.2014 19:52, Fujii Masao wrote:
>> >> On Thu, May 29, 2014 at 12:37 AM, Peter Geoghegan
>> >> wrote:
>> >>> On Wed, M
On Mon, May 26, 2014 at 1:34 PM, Dmitry Samonenko
wrote:
> 1. Connection to PSQL server is made without an option to specify
SO_RCVTIMEO and SO_SNDTIMEO. Why is that? Is setting socket timeouts
considered harmful?
> 2. PQexec ultimately leads to PQwait, which after some function calls
"lands" in p
On Wed, May 28, 2014 at 5:30 PM, Gurjeet Singh wrote:
> On Wed, May 28, 2014 at 2:15 AM, Amit Kapila
wrote:
> > How about the cases when shared buffers already contain some
> > data:
> > a. Before Readers start filling shared buffers, if this cluster wishes
> > to join replication as a slave and
On Thu, May 29, 2014 at 8:52 AM, Fujii Masao wrote:
> On Thu, May 29, 2014 at 4:55 AM, Tomas Vondra wrote:
> > On 28.5.2014 19:52, Fujii Masao wrote:
> >> On Thu, May 29, 2014 at 12:37 AM, Peter Geoghegan
> wrote:
> >>> On Wed, May 28, 2014 at 7:01 AM, Fujii Masao
> wrote:
> But pg_stat_s
Buildfarm critters smew and shearwater are reporting regression test
failures that suggest that the UUID library can't get a system MAC
address:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=smew&dt=2014-05-28%2023%3A38%3A28
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=shearwater
On Thu, May 29, 2014 at 4:55 AM, Tomas Vondra wrote:
> On 28.5.2014 19:52, Fujii Masao wrote:
>> On Thu, May 29, 2014 at 12:37 AM, Peter Geoghegan wrote:
>>> On Wed, May 28, 2014 at 7:01 AM, Fujii Masao wrote:
But pg_stat_statements file is saved under $PGDATA/global yet.
Is this inten
Consider this example:
[local]/postgres=# SELECT to_char(1e9::float8,'9D9');
to_char
--
10.0
(1 row)
[local]/postgres=# SELECT to_char(1e20::float8,'9D9');
to_char
1000
On 05/26/2014 08:19 PM, Vik Fearing wrote:
> On 05/26/2014 07:10 AM, Stephen Frost wrote:
>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>>> I don't really object to doing an unlocked check for another such
>>> database, but I'm not convinced that additional locking to try to
>>> prevent a race is worth
While mucking around with contrib/uuid-ossp, I realized that its usage
of the OSSP UUID library is really rather broken: it creates and destroys
a uuid_t object for each call of the UUID creation functions. This is not
the way you're supposed to use that library. The uuid_t object is meant
to hol
On Wed, May 28, 2014 at 5:59 PM, Claudio Freire wrote:
> For nestloop, correct me if I'm wrong, but index scan nodes don't have
> visibility of the next tuple to be searched for.
Nested loop joins are considered a particularly compelling case for
prefetching, actually.
--
Peter Geoghegan
--
On Wed, May 28, 2014 at 6:51 PM, Peter Geoghegan wrote:
> Have you thought about things like specialized prefetching for nested
> loop joins?
Currently, such a thing would need some non-trivial changes to the
execution nodes, I believe.
For nestloop, correct me if I'm wrong, but index scan nodes
On Wed, May 28, 2014 at 04:04:13PM +0100, Simon Riggs wrote:
> On 28 May 2014 15:34, Fujii Masao wrote:
>
> >> Also, compress_backup_block GUC needs to be merged with full_page_writes.
> >
> > Basically I agree with you because I don't want to add new GUC very similar
> > to
> > the existing one
On 2014-05-28 19:12:44 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-05-28 18:52:22 -0400, Tom Lane wrote:
> >> and IMO we should also lobby the Bison people to not emit the
> >> deprecation warnings yet.
>
> > That's a good idea. What i've been thinking about is to add
> > -Wno-depr
Andres Freund writes:
> On 2014-05-28 18:52:22 -0400, Tom Lane wrote:
>> and IMO we should also lobby the Bison people to not emit the
>> deprecation warnings yet.
> That's a good idea. What i've been thinking about is to add
> -Wno-deprecated to the bison rule in the interim. Maybe after a
> con
On 2014-05-28 18:52:22 -0400, Tom Lane wrote:
> I guess we have to revert this
Looks like it.
> and IMO we should also lobby the Bison people to not emit the
> deprecation warnings yet.
That's a good idea. What i've been thinking about is to add
-Wno-deprecated to the bison rule in the interim.
Andres Freund writes:
> On 2014-05-28 22:55:28 +0200, Andres Freund wrote:
>> On 2014-05-28 19:42:35 +, Tom Lane wrote:
>>> Fix bogus %name-prefix option syntax in all our Bison files.
>> Are you sure about this? When I saw those warnings first after debian
>> unstable got bison 3.0 I've read
Hi,
On 2014-05-21 07:29:53 -0400, Peter Eisentraut wrote:
> Looking at
> http://www.postgresql.org/docs/devel/static/protocol-replication.html
> under START_REPLICATION it goes
>
> """
> The payload of each CopyData message from server to the client contains
> a message of one of the following fo
On 05/27/2014 07:25 PM, Andrew Dunstan wrote:
On 05/27/2014 07:17 PM, Tom Lane wrote:
Stephen Frost writes:
* Andrew Dunstan (and...@dunslane.net) wrote:
Given that this would be a hard coded behaviour change, is it too
late to do this for 9.4?
No, for my 2c.
If we do it by adding casts t
Hi,
On 2014-05-17 01:34:25 +0200, Andres Freund wrote:
> On 2014-05-16 17:02:33 -0400, Steve Singer wrote:
> > >I don't think that's going to cut it though. The creation can take
> > >longer than whatever wal_sender_timeout is set to (when there's lots of
> > >longrunning transactions). I think ch
Teodor Sigaev writes:
> create table xxx ( t text);
> insert into xxx select 'x' || v::text from generate_series(1, 291) as v;
> insert into xxx values ('');
> create index xxxidx on xxx using spgist (t);
Fun!
> And postgres will eat memory forever. It seems to me that checkAllTheSame
> wron
On Tue, May 27, 2014 at 3:17 PM, John Lumby wrote:
> Below I am pasting the README we have written for this new functionality
> which mentions some of the measurements, advantages (and disadvantages)
> and we welcome all and any comments on this.
I think that this is likely to be a useful area to
On 05/28/2014 11:52 PM, John Lumby wrote:
The patch is attached.
It is based on clone of today's 9.4dev source.
I have noticed that this source is
(not suprisingly) quite a moving target at present,
meaning that this patch becomes stale quite quickly.
So although this copy is fine for reviewing,
On Wed, May 28, 2014 at 12:29:28PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > I think this is caused because the variable is not defined as SOCKET.
> > The attached patch fixes this. This should prevent the warning.
>
> Surely that's just going to move the errors somewhere else. The ca
On 28.5.2014 19:52, Fujii Masao wrote:
> On Thu, May 29, 2014 at 12:37 AM, Peter Geoghegan wrote:
>> On Wed, May 28, 2014 at 7:01 AM, Fujii Masao wrote:
>>> But pg_stat_statements file is saved under $PGDATA/global yet.
>>> Is this intentional or just oversight?
>>
>>
>> I think it's an oversight
On 05/28/2014 04:13 AM, Peter Geoghegan wrote:
On Wed, May 21, 2014 at 4:53 AM, Heikki Linnakangas
wrote:
Hmm. The patch looks correct as far as it goes. But that function is still a
bit funny. When it compares two identical arrays (or objects), and reaches
the WJB_END_ARRAY token, it will stil
On 5/28/14, 2:43 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> What they want is that you use
>> %name-prefix "base_yy"
>> instead of
>> %name-prefix="base_yy"
>> That makes the warning go away.
>
> Oh really!?
>
>> The %something=something syntax is not documented anywhere, so it lo
Peter Eisentraut writes:
> What they want is that you use
> %name-prefix "base_yy"
> instead of
> %name-prefix="base_yy"
> That makes the warning go away.
Oh really!?
> The %something=something syntax is not documented anywhere, so it looks
> like it worked more or less by accident. We
On 5/21/14, 12:29 PM, Tom Lane wrote:
> Vik Fearing writes:
>> I'm getting some more of these, including some I thought you had fixed.
>> Bison 3.0.2 on current head.
>
> I didn't do anything to suppress those warnings:
>
>> gram.y:172.1-13: warning: deprecated directive, use ‘%name-prefix’
* ash (a...@commandprompt.com) wrote:
> OK, forget functions, I now realize it's not feasible to consider.
I never meant to imply that it was but rather to point out that we might
have users who actually want to get an error when they're changing a
type definition which goes beyond the scope of th
* David Fetter (da...@fetter.org) wrote:
> On Tue, May 27, 2014 at 09:41:06AM -0400, Stephen Frost wrote:
> > * David Fetter (da...@fetter.org) wrote:
> > > - We make type mappings settable at the level of:
> > > - FDW
> > > - Instance (a.k.a. cluster)
> > > - Database
> > > - Schem
On Thu, May 29, 2014 at 12:37 AM, Peter Geoghegan wrote:
> On Wed, May 28, 2014 at 7:01 AM, Fujii Masao wrote:
>> But pg_stat_statements file is saved under $PGDATA/global yet.
>> Is this intentional or just oversight?
>
>
> I think it's an oversight.
OK, patch attached.
I'm afraid that it's no
Greetings.
I have an application which uses libpq for interaction with remote
PostgreSQL server 9.2. Clients and Server nodes are running Linux and
connection is established using TCPv4. The client application has some
small fault-tolerance features, which are activated when server related
problem
Bruce Momjian writes:
> I think this is caused because the variable is not defined as SOCKET.
> The attached patch fixes this. This should prevent the warning.
Surely that's just going to move the errors somewhere else. The call
site still expects the argument to be int[].
ash wrote:
>
> Tom Lane writes:
> >
> > We don't store dependency information for function bodies, so there's
> > no way to do this except by reparsing everything in sight.
> OK, forget functions, I now realize it's not feasible to consider.
>
> Can we get back to re-defining views at least?
H
Tom Lane writes:
>
> We don't store dependency information for function bodies, so there's
> no way to do this except by reparsing everything in sight.
>
> A larger issue with the idea is that a function might fail reparsing
> for reasons having nothing to do with the proposed ALTER TABLE.
> For
On Wed, May 28, 2014 at 7:01 AM, Fujii Masao wrote:
> But pg_stat_statements file is saved under $PGDATA/global yet.
> Is this intentional or just oversight?
I think it's an oversight.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
On Wed, May 28, 2014 at 7:38 AM, Bruce Momjian wrote:
> On Mon, May 26, 2014 at 09:50:42PM +0900, Michael Paquier wrote:
> > > x86_64-w64-mingw32-gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
> -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute
> -Wformat-security -fno-s
Hi,
Since a64ca63e59c11d8fe6db24eee3d82b61db7c2c83 pg_sleep() uses
WaitLatch() to wait. That's fine in itself. But
procsignal_sigusr1_handler, which is used e.g. when resolving recovery
conflicts, doesn't unconditionally do a SetLatch().
That means that we'll we'll currently not be able to cancel
On 28 May 2014 15:34, Fujii Masao wrote:
>> Also, compress_backup_block GUC needs to be merged with full_page_writes.
>
> Basically I agree with you because I don't want to add new GUC very similar to
> the existing one.
>
> But could you imagine the case where full_page_writes = off. Even in thi
On Mon, May 26, 2014 at 09:50:42PM +0900, Michael Paquier wrote:
> > x86_64-w64-mingw32-gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith
> > -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute
> > -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard
>
On Tue, May 27, 2014 at 12:57 PM, Rahila Syed wrote:
> Hello All,
>
> 0001-CompressBackupBlock_snappy_lz4_pglz extends patch on compression of
> full page writes to include LZ4 and Snappy . Changes include making
> "compress_backup_block" GUC from boolean to enum. Value of the GUC can be
> OFF, pg
On Tue, May 27, 2014 at 09:41:06AM -0400, Stephen Frost wrote:
> * David Fetter (da...@fetter.org) wrote:
> > - We make type mappings settable at the level of:
> > - FDW
> > - Instance (a.k.a. cluster)
> > - Database
> > - Schema
> > - Table
> > - Column
>
> While I like th
ash writes:
> Stephen Frost writes:
>> We're not going to re-parse every function in the system, like, ever.
> Well, only every *affected* function, which might be pretty minimal in
> the usual case.
We don't store dependency information for function bodies, so there's
no way to do this except
Hi,
Thanks to 187492b6c2e8cafc5b39063ca3b67846e8155d24, pgstat
files are now saved to $PGDATA/pg_stat directory at shutdown.
But pg_stat_statements file is saved under $PGDATA/global yet.
Is this intentional or just oversight? Saving that file to global is
harmless, though.
Regards,
--
Fujii Ma
On Wed, May 28, 2014 at 10:46 AM, Fujii Masao wrote:
> On Wed, May 28, 2014 at 4:36 AM, Fabrízio de Royes Mello
> wrote:
> >
> > On Mon, May 26, 2014 at 12:33 PM, Amit Langote
> > wrote:
> >>
> >> Hi,
> >>
> >> Just noticed pg_llog is not mentioned in the "Database File Layout"
> >> section. Wo
* ash (a...@commandprompt.com) wrote:
> What I am suggesting is that we try to detect such breakage at the time
> the user runs ALTER TABLE (issuing NOTICE or ERROR at user discretion.)
> If changing column type of a table breaks some functions down the way,
> the user will hit it anyway, but bette
Hi,
On 2014-05-27 00:33:12 +0900, Amit Langote wrote:
> Just noticed pg_llog is not mentioned in the "Database File Layout"
> section. Wonder if it's an oversight?
Yes, it should be mentioned there. I'll fix it.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuad
On Wed, May 28, 2014 at 4:36 AM, Fabrízio de Royes Mello
wrote:
>
> On Mon, May 26, 2014 at 12:33 PM, Amit Langote
> wrote:
>>
>> Hi,
>>
>> Just noticed pg_llog is not mentioned in the "Database File Layout"
>> section. Wonder if it's an oversight?
>>
>
> Yes, it is an oversight. Patch attached.
Stephen Frost writes:
> * ash (a...@commandprompt.com) wrote:
>> Stephen Frost writes:
>>
>> > Also consider MatViews which would need to be rewritten for the new
>> > type
>>
>> That might be costly but not impossible. A user would need to do that
>> anyway, though manually.
>
> I was point
* ash (a...@commandprompt.com) wrote:
> Stephen Frost writes:
> > I hadn't even considered the idea that we would go through and try to
> > change everything which referenced that view to now be the new type- but
> > in that case, I'd want to know that there were other changes which were
> > happe
Stephen Frost writes:
>
> I hadn't even considered the idea that we would go through and try to
> change everything which referenced that view to now be the new type- but
> in that case, I'd want to know that there were other changes which were
> happening beyond the single view which I was updat
Robert Haas writes:
>
> Well, pg_dump is trying to do something different than what you're
> trying to do here. pg_dump wants to make sure that the view, when fed
> back into psql, creates the same view that exists now, regardless of
> whether that's what the user created originally. For exampl
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, May 26, 2014 at 10:39 AM, Stephen Frost wrote:
> > It'd need to be explicitly requested, eg a 'CASCADE' option.
>
> Why? Would any sane person NOT want this behavior?
[...]
> Now maybe there are options other than trying to reproduce what
On Wed, May 28, 2014 at 2:15 AM, Amit Kapila wrote:
> On Wed, May 28, 2014 at 7:31 AM, Gurjeet Singh wrote:
> > Caveats
>> --
>>
>> - Buffer list is saved only when Postgres is shutdown in "smart" and
>> "fast" modes.
>>
>> That is, buffer list is not saved when database crashes,
Searching for that error turned up:
https://sourceware.org/bugzilla/show_bug.cgi?id=14247
https://bugzilla.redhat.com/show_bug.cgi?id=827510
Indeed. Thanks for the pointer.
I have reported the issue on launchpad (ubuntu bug tracking site) with a
link to the redhat bug and Tom's test program
On Sun, May 25, 2014 at 5:42 AM, Tom Lane wrote:
> David Rowley writes:
> > I agree that there are not many cases left to remove the join that remain
> > after is_simple_subquery() has decided not to pullup the subquery. Some
> of
> > the perhaps more common cases would be having windowing funct
On Tue, May 20, 2014 at 11:18:29AM -0700, Jeff Davis wrote:
> I think this can be done without breaking upgrade compatibility, because
> I think the structure already satisfies the invariants I mentioned in
> the other email (aside from the special case of a root tuple with two
> nodes and no prefi
On 05/28/2014 02:15 AM, Peter Geoghegan wrote:
On Tue, May 27, 2014 at 12:19 PM, Heikki Linnakangas
wrote:
Fair enough, but I don't think that affects correctness either way (I
don't think that you meant to imply that this was a necessary
precaution that you'd taken - right?).
Right.
So, th
On 05/28/2014 09:41 AM, Simon Riggs wrote:
On 27 May 2014 13:20, Heikki Linnakangas wrote:
On 05/27/2014 03:18 PM, Simon Riggs wrote:
IIRC Koichi had a patch for prefetch during recovery. Heikki, is that
the reason you also discussed changing the WAL record format to allow
us to identify the
61 matches
Mail list logo
