> On Mon, Nov 24, 2014 at 6:57 AM, Kouhei Kaigai wrote:
> > Indeed, I don't think it is a good idea to start from this harder portion.
> > Let's focus on just varno/varattno remapping to replace join relation
> > by custom-scan, as an immediate target.
>
> We still need something like this for FD
Re: Tom Lane 2014-11-18 <23920.1416350...@sss.pgh.pa.us>
> That doesn't make any sense as it stands, but I take your point, and
> indeed that's more or less the reasoning that led me to write the test
> as it is: we *should* complain if you've got TZ data that's more than
> 6 months old. However,
On 11/24/2014 06:05 PM, Alex Shulgin wrote:
The first patch is not on topic, I just spotted this missing check.
*** a/src/interfaces/libpq/fe-connect.c
--- b/src/interfaces/libpq/fe-connect.c
*** conninfo_array_parse(const char *const *
*** 4402,4407
--- 4402,4415
Heikki Linnakangas writes:
> On 11/24/2014 06:05 PM, Alex Shulgin wrote:
>> The first patch is not on topic, I just spotted this missing check.
>
>> *** a/src/interfaces/libpq/fe-connect.c
>> --- b/src/interfaces/libpq/fe-connect.c
>> *** conninfo_array_parse(const char *const *
>> *
On Sun, Nov 9, 2014 at 10:02 PM, Peter Geoghegan wrote:
> On Sat, Oct 11, 2014 at 6:34 PM, Peter Geoghegan wrote:
>> Attached patch, when applied, accelerates all tuplesort cases using
>> abbreviated keys, building on previous work here, as well as the patch
>> posted to that other thread.
>
> I
On Tue, Nov 25, 2014 at 12:37 PM, Noah Misch wrote:
> On Wed, Jan 22, 2014 at 11:48:26PM +0900, Fujii Masao wrote:
>> (3) PQhost() cannot return the hostaddr.
>
>> We can fix the problem (3) by changing PQhost() so that it also
>> returns the hostaddr. But this change might break the existing
>> a
On 11/25/2014 01:37 PM, Alex Shulgin wrote:
Heikki Linnakangas writes:
On 11/24/2014 06:05 PM, Alex Shulgin wrote:
The first patch is not on topic, I just spotted this missing check.
*** a/src/interfaces/libpq/fe-connect.c
--- b/src/interfaces/libpq/fe-connect.c
*** conninfo_a
On Tue, Nov 25, 2014 at 7:58 AM, Alvaro Herrera
wrote:
>> And here is v10 which fixes conflicts with Heikki's WAL API changes (no
>> changes otherwise).
>
> After some slight additional changes, here's v11, which I intend to
> commit early tomorrow. The main change is moving the test module from
Michael Paquier wrote:
> Exposing compression and decompression APIs of pglz makes possible its
> use by extensions and contrib modules. pglz_decompress contained a call
> to elog to emit an error message in case of corrupted data. This function
> is changed to return a boolean status to let its c
Heikki Linnakangas writes:
>>>
>>> I think we need to fix all of those, and backpatch. Per attached.
>>
>> Yikes! Looks sane to me.
>
> Ok thanks, committed. It didn't apply cleanly to 9.0, 9.1 and 9.2, so
> the patch for those branches looks a bit different.
Great. Are you looking at the actu
On Thu, Nov 20, 2014 at 5:35 AM, Simon Riggs wrote:
> On 19 November 2014 16:41, Fujii Masao wrote:
>> On Wed, Nov 19, 2014 at 10:49 PM, Robert Haas wrote:
>>> On Wed, Nov 19, 2014 at 8:13 AM, Simon Riggs wrote:
If we ask for PAUSE and we're not in HotStandby it just ignores it,
which
On 8 October 2014 at 20:39, Andrew Dunstan wrote:
>
> On 10/08/2014 02:04 PM, Thom Brown wrote:
>
> There is work already being done on providing update operations.
>>>
>> I've been looking out for that. Has there been a discussion on how
>> that would look yet that you could point me to?
>>
>>
Fujii Masao wrote:
> On Tue, Nov 25, 2014 at 7:58 AM, Alvaro Herrera
> wrote:
> >> And here is v10 which fixes conflicts with Heikki's WAL API changes (no
> >> changes otherwise).
> >
> > After some slight additional changes, here's v11, which I intend to
> > commit early tomorrow. The main chang
On Tue, Nov 25, 2014 at 11:19 PM, Alvaro Herrera
wrote:
> Fujii Masao wrote:
>> On Tue, Nov 25, 2014 at 7:58 AM, Alvaro Herrera
>> wrote:
>> >> And here is v10 which fixes conflicts with Heikki's WAL API changes (no
>> >> changes otherwise).
>> >
>> > After some slight additional changes, here's
On Tue, Nov 25, 2014 at 9:19 AM, Alvaro Herrera
wrote:
> Fujii Masao wrote:
>> On Tue, Nov 25, 2014 at 7:58 AM, Alvaro Herrera
>> wrote:
>> >> And here is v10 which fixes conflicts with Heikki's WAL API changes (no
>> >> changes otherwise).
>> >
>> > After some slight additional changes, here's v
On Tue, Nov 25, 2014 at 10:48 PM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
>
>> Exposing compression and decompression APIs of pglz makes possible its
>> use by extensions and contrib modules. pglz_decompress contained a call
>> to elog to emit an error message in case of corrupted data. Thi
* Stephen Frost (sfr...@snowman.net) wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > According to
> > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dromedary&dt=2014-11-21%2019%3A59%3A50
> > the order of cascaded drops at one point in the rowsecurity test is not
> > too stable. This i
On 11/24/2014 06:05 PM, Alex Shulgin wrote:
Heikki Linnakangas writes:
It appears that replication connection doesn't support URI but only the
traditional conninfo string.
src/backend/replication/libpqwalreceiver/libpqwalreceiver.c:99: in
libpqrcv_connect():
snprintf(conninfo_repl, si
Robert Haas wrote:
> On Tue, Nov 25, 2014 at 9:19 AM, Alvaro Herrera
> wrote:
> > Fujii Masao wrote:
> >> On Tue, Nov 25, 2014 at 7:58 AM, Alvaro Herrera
> >> wrote:
> >> >> And here is v10 which fixes conflicts with Heikki's WAL API changes (no
> >> >> changes otherwise).
> >> >
> >> > After som
On 25/11/14 16:23, Alvaro Herrera wrote:
Robert Haas wrote:
On Tue, Nov 25, 2014 at 9:19 AM, Alvaro Herrera
wrote:
Fujii Masao wrote:
On Tue, Nov 25, 2014 at 7:58 AM, Alvaro Herrera
wrote:
And here is v10 which fixes conflicts with Heikki's WAL API changes (no
changes otherwise).
After so
Petr Jelinek wrote:
> On 25/11/14 16:23, Alvaro Herrera wrote:
> >Robert Haas wrote:
> >>Maybe 0 should get translated to a NULL return, instead of a bogus
> >>timestamp.
> >
> >That's one idea --- surely no transaction is going to commit at 00:00:00
> >on 2000-01-01 anymore. Yet this is somewha
On 25/11/14 16:30, Alvaro Herrera wrote:
Petr Jelinek wrote:
On 25/11/14 16:23, Alvaro Herrera wrote:
Robert Haas wrote:
Maybe 0 should get translated to a NULL return, instead of a bogus timestamp.
That's one idea --- surely no transaction is going to commit at 00:00:00
on 2000-01-01 anym
Re: To Robert Haas 2014-11-24 <20141124200824.ga22...@msg.df7cb.de>
> > Does it fail every time when run on a machine where it fails sometimes?
>
> So far there's a consistent host -> fail-or-not mapping, but most
> mips/mipsel build hosts have seen only one attempt so far which
> actually came so
In 9.3.5, if I set up archiving, create a database, pull a base
backup, look at the clock, drop database, stop the server, rm -rf
datadir, put back the backup, edit recovery.conf:
cd /tmp; initdb foo
edit postgresql.conf with archive_mode = on, archive_command,
max_wal_senders = 1, wal_level = hot
On 25 November 2014 at 13:35, Fujii Masao wrote:
> Can I check my understanding? Probably we cannot use this feature to calculate
> the actual replication lag by, for example, comparing the result of
> pg_last_committed_xact() in the master and that of
> pg_last_xact_replay_timestamp()
> in the s
On 25/11/14 17:16, Simon Riggs wrote:
On 25 November 2014 at 13:35, Fujii Masao wrote:
Can I check my understanding? Probably we cannot use this feature to calculate
the actual replication lag by, for example, comparing the result of
pg_last_committed_xact() in the master and that of
pg_last_x
On 11/25/2014 05:11 PM, Heikki Linnakangas wrote:
On 11/24/2014 06:05 PM, Alex Shulgin wrote:
Heikki Linnakangas writes:
It appears that replication connection doesn't support URI but only the
traditional conninfo string.
src/backend/replication/libpqwalreceiver/libpqwalreceiver.c:99: in
li
On 25 November 2014 at 16:18, Petr Jelinek wrote:
> Won't the pg_last_committed_xact() on slave + pg_xact_commit_timestamp() on
> master with the xid returned by slave accomplish the same thing?
Surely the pg_last_committed_xact() will return the same value on
standby as it did on the master?
-
On 11/25/2014 06:06 PM, Christoph Berg wrote:
In 9.3.5, if I set up archiving, create a database, pull a base
backup, look at the clock, drop database, stop the server, rm -rf
datadir, put back the backup, edit recovery.conf:
cd /tmp; initdb foo
edit postgresql.conf with archive_mode = on, archi
Andres,
Thanks for the feedback.
> * int64 (C) to int8 (SQL) mapping for genbki.
>
> That definitely should be a separate patch. Which can be committed much
> earlier than the rest - even if we don't actually end up needing it for
> this feature, it's still good to have it.
Agreed. I had previ
* Andrew Dunstan (and...@dunslane.net) wrote:
> On 11/18/2014 04:58 PM, Adam Brightwell wrote:
> >Attached is a quite trivial patch that addresses the int64 (C) to
> >int8 (SQL) mapping issue.
>
> I think we should just apply this now. As Tom said the reason for
> not doing it is long gone.
Alrig
* Adam Brightwell (adam.brightw...@crunchydatasolutions.com) wrote:
> > * int64 (C) to int8 (SQL) mapping for genbki.
> >
> > That definitely should be a separate patch. Which can be committed much
> > earlier than the rest - even if we don't actually end up needing it for
> > this feature, it's st
David,
> A few related threads/discussions/posts:
> >
> > * http://www.postgresql.org/message-id/
>
> > 20141016115914.GQ28859@.snowman
>
> > *
> >
> http://www.postgresql.org/message-id/CA+TgmobkYXNOWKEKzX2qGPSr_nvacFGueV=
>
> > orxND-xmZvOVYvg@.gmail
>
> > * http://www.postgresql.org/message-id/
Pavel Stehule writes:
> 2014-10-27 11:20 GMT+01:00 Ali Akbar :
>> [ array_agg_anyarray-13.patch ]
> This patch is ready for commit
I've committed this after some significant modifications.
I did not like the API chosen, specifically the business about callers
needing to deal with both accumArra
* Adam Brightwell (adam.brightw...@crunchydatasolutions.com) wrote:
> An array representation was also suggested by Simon (
> http://www.postgresql.org/message-id/ca+u5nmjgvdz6jx_ybjk99nj7mwfgfvemxtdc44lvhq64gkn...@mail.gmail.com).
> Obviously there are pro's and con's to either approach. I'm not
Heikki Linnakangas writes:
>>>
>>> The second one is a self-contained fix, but the third one which is the
>>> actual patch depends on the second one, because it specifies the dbname
>>> keyword two times: first to parse the conninfo/URI, then to override any
>>> dbname provided by the user with "
On Tue, Nov 25, 2014 at 4:01 AM, Robert Haas wrote:
> - This appears to needlessly reindent the comments for PG_CACHE_LINE_SIZE.
Actually, the word "only" is removed (because PG_CACHE_LINE_SIZE has a
new client now). So it isn't quite the same paragraph as before.
> - I really don't think we nee
On Tue, Nov 25, 2014 at 10:38 AM, Peter Geoghegan wrote:
>> - Also, I don't think making abbrev_state an enumerated value with two
>> values is really doing anything for us; we could just use a Boolean.
>> I'm wondering if we should actually go a bit further and remove this
>> from the SortSupport
Marko Tiikkaja writes:
> On 10/15/14, 10:02 AM, Atri Sharma wrote:
>> Please find attached a patch which implements support for UPDATE table1
>> SET(*)=...
> I've had a few looks at this patch and I have a few comments:
>1) This doesn't work for the zero-column table case at all:
> C
On 25 November 2014 at 14:06, Fujii Masao wrote:
> On Thu, Nov 20, 2014 at 5:35 AM, Simon Riggs wrote:
>> On 19 November 2014 16:41, Fujii Masao wrote:
>>> On Wed, Nov 19, 2014 at 10:49 PM, Robert Haas wrote:
On Wed, Nov 19, 2014 at 8:13 AM, Simon Riggs wrote:
> If we ask for PAUSE an
While fooling around with the array_agg(anyarray) patch, I noted
that dblink_get_connections() returns NULL if there are no active
connections. It seems like an empty array might be a saner
definition --- thoughts?
regards, tom lane
--
Sent via pgsql-hackers mailing lis
On 11/24/14 8:49 AM, Alvaro Herrera wrote:
> What would you say if we were to move them to src/test/?
Yes please.
> Now, I know there is some resistance to the idea of moving source code
> around.
I think clarifying "contrib" is more important than that.
--
Sent via pgsql-hackers mailing lis
On 11/24/14 9:35 AM, Andres Freund wrote:
> I actually think that test_decoding is somewhat useful in other cases as
> well, so it might be prudent to leave it there.
For what?
> src/test/ is good, but I think there should be another subdirectory
> inside. testcases/?
What tests are not test cas
On 25/11/14 21:15, Simon Riggs wrote:
On 25 November 2014 at 14:06, Fujii Masao wrote:
On Thu, Nov 20, 2014 at 5:35 AM, Simon Riggs wrote:
On 19 November 2014 16:41, Fujii Masao wrote:
On Wed, Nov 19, 2014 at 10:49 PM, Robert Haas wrote:
On Wed, Nov 19, 2014 at 8:13 AM, Simon Riggs wrote
On 11/24/14 10:46 AM, Tom Lane wrote:
> I think that test_parser is arguably useful as a skeleton/example for
> user-written TS parsers, so I'd lean towards leaving it where it is,
> but the others could move to src/test/ IMO.
I think a useful dividing line would be, is it normally useful to
insta
On 2014-11-25 16:07:52 -0500, Peter Eisentraut wrote:
> On 11/24/14 9:35 AM, Andres Freund wrote:
> > I actually think that test_decoding is somewhat useful in other cases as
> > well, so it might be prudent to leave it there.
>
> For what?
>
> > src/test/ is good, but I think there should be ano
Peter Eisentraut writes:
> On 11/24/14 10:46 AM, Tom Lane wrote:
>> I think that test_parser is arguably useful as a skeleton/example for
>> user-written TS parsers, so I'd lean towards leaving it where it is,
>> but the others could move to src/test/ IMO.
> I think a useful dividing line would b
On 25.11.2014 18:11, Heikki Linnakangas wrote:
> On 11/25/2014 06:06 PM, Christoph Berg wrote:
>
>> db1 is registered in pg_database, but the directory is missing on
>> disk.
>
> Yeah, DROP DATABASE cheats. It deletes all the files first, and commits
> the transaction only after that. There's this
On 11/25/2014 11:01 PM, Tomas Vondra wrote:
[snip]
So you could see the same after crash recovery, but it's a lot easier to
reproduce with PITR.
So we remove the files, and if there happens to be a crash at the right
moment, it results in a database with a record in pg_database, but no
director
All,
> I think if we're going to do this - and I'm not yet convinced that
>> that's the best route, we should add returns all permissions a user
>> has. Right now that's quite easily queryable, but it won't be after
>> moving everything into one column. You'd need to manually use all has_*_
>> fu
2014-11-26 0:38 GMT+07:00 Tom Lane :
> Pavel Stehule writes:
> > 2014-10-27 11:20 GMT+01:00 Ali Akbar :
> >> [ array_agg_anyarray-13.patch ]
>
> > This patch is ready for commit
>
> I've committed this after some significant modifications.
>
> I did not like the API chosen, specifically the busin
Ali Akbar writes:
> Just curious, in accumArrayResultArr, while enlarging array and
> nullbitmaps, why it's implemented with:
> astate->abytes = Max(astate->abytes * 2,
> astate->nbytes + ndatabytes);
> and
> astate->aitems = Max(astate->aitems * 2, newnitems);
> won't it be more consistent if i
2014-11-05 21:50 GMT+07:00 Ali Akbar :
> 2014-11-04 22:16 GMT+07:00 Peter Eisentraut :
>
>> I think the problem this patch is addressing is real, and your approach
>>> is sound, but I'd ask you to go back to the xmlCopyNode() version, and
>>> try to add a test case for why the second argument = 1
Alright, so let me summarize what I think are the next steps in
working towards getting this patch committed. I should produce a new
revision which:
* Uses default costings.
* Applies a generic final quality check that enforces a distance of no
greater than 50% of the total string size. (The use
Adam,
* Adam Brightwell (adam.brightw...@crunchydatasolutions.com) wrote:
> Giving this some thought, I'm curious what would be acceptable as an end
> result, specifically related to how a query on pg_authid might look/work.
> I was able to preserve the structure of results from pg_roles, however,
Stephen,
Having an array sounds pretty reasonable to me.
>
Ok, sounds good, I think so too.
Users interested in having a string instead could use array_to_string().
> Having to go the other way isn't as nice, imo.
>
My thoughts exactly, but wanted to at least put it out there.
Thanks,
Adam
-
Hi,
> > I'm wondering here if it's better to keep partition values per partition
> > wherein we have two catalogs, say, pg_partitioned_rel and pg_partition_def.
> >
> > pg_partitioned_rel stores information like partition kind, key (attribute
> > number(s)?), key opclass(es). Optionally, we could
Sorry, a correction:
> CREATE TABLE pg_catalog.pg_partitioned_rel
> (
>partrelidoidNOT NULL,
>partkindoidNOT NULL,
>partissub bool NOT NULL,
>partkey int2vector NOT NULL, -- partitioning attributes
>partopcl
Hi all,
In the stuff I work on in a daily basis there are a couple of
extensions written in C++, compiling them with MSVC on Windows using
slightly-different scripts available in src/tools after copying them
directly in contrib/. However, the build scripts available in
src/tools/msvc are not able
On Wed, Nov 26, 2014 at 1:51 AM, Simon Riggs wrote:
> On 25 November 2014 at 16:18, Petr Jelinek wrote:
>
>> Won't the pg_last_committed_xact() on slave + pg_xact_commit_timestamp() on
>> master with the xid returned by slave accomplish the same thing?
>
> Surely the pg_last_committed_xact() will
Using both 9.2.9 and 9_2_STABLE 9b468bcec15f1ea7433d4, I get a fairly
reproducible startup failure.
What I was doing is restore a database from a base backup and roll it
forward with a recovery.conf until it completes and starts up. Then I
truncate an unlogged table and start repopulating it with
On Wed, Nov 19, 2014 at 1:37 AM, Simon Riggs wrote:
> On 23 October 2014 00:21, Alvaro Herrera wrote:
>
>>> Attached patch is latest version patch I modified above.
>>> Also, I noticed I had forgotten to add the patch regarding document of
>>> reindexdb.
>>
>> Please don't use pg_catalog in the r
On Fri, Aug 15, 2014 at 8:17 PM, Fujii Masao wrote:
> On Fri, Aug 15, 2014 at 3:40 AM, Andres Freund wrote:
>> On 2014-08-14 14:37:22 -0400, Robert Haas wrote:
>>> On Thu, Aug 14, 2014 at 2:21 PM, Andres Freund
>>> wrote:
>>> > On 2014-08-14 14:19:13 -0400, Robert Haas wrote:
>>> >> That's abou
When packaging PostgreSQL for Postgres.app, I discovered a problem: strcoll
doesn't work for multibyte encodings on OS X. As a consequence, text sorting in
PostgreSQL doesn't work. The only workaround seemed to be to use a legacy
encoding like latin1, which is inacceptable.
I discovered that OS
Hi!
This is indeed a very well tested patch as we've run it in production for 8+
years on 20+ systems.
It is not included upstreams mainly because I did ask for it to happen. I've
been aiming to do it but haven't got around to it. Also, since 9.2 (?) there is
support in PostgreSQL for setting
Hi all
so one problem is closed, and we can start speaking about ASSERT statement.
I propose a (old) syntax
ASSERT expr [, message]
possible questions:
* should be assertions globally enabled/disabled? - I have no personal
preference in this question.
* can be ASSERT exception handled ? - I p
66 matches
Mail list logo
