On Thursday, February 07, 2013 6:15 PM Etsuro Fujita wrote:
> Through the work on the patch [1], I had a question about the psql
> \copy command. We are permitted 1) but not permitted 2):
> 1) \copy foo from stdin ;
> 2) \copy foo from stdin;
> Is this intentional? I think it would be better to a
On Fri, Feb 15, 2013 at 5:19 AM, Tom Lane wrote:
>
> + CallXactCallbacks(XACT_EVENT_PRE_COMMIT);
> +
> /*
> * The remaining actions cannot call any user-defined code, so it's safe
> * to start shutting down within-transaction services. But note that most
> * of this stuff co
(changing subject)
On Thu, Feb 14, 2013 at 11:48 PM, Fujii Masao wrote:
> On Mon, Feb 11, 2013 at 5:46 PM, Pavan Deolasee
>> I also noticed that the WAL file switch
>> happens after archive_timeout seconds irrespective of whether
>> archive_mode is turned ON or not. This happens because we don't
Tomas Vondra escribió:
> I don't see how that changes the autovacuum behavior. Can you explain
> that a bit more?
It might be that I'm all wet on this. I'll poke at it some more.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Servi
I forgot to mark all.
I could be a co mentor, helping in overall coordination and supporting all the
students in getting familiar with the project and community etc.
Atri
Sent from my iPad
On 15-Feb-2013, at 8:34, Stephen Frost wrote:
> * Josh Berkus (j...@agliodbs.com) wrote:
>> - Who wants
I forgot to mark all.
I could be a co mentor, helping in overall coordination and supporting all the
students in getting familiar with the project and community etc.
Atri
Sent from my iPad
On 14-Feb-2013, at 23:32, Josh Berkus wrote:
> Folks,
>
> Once again, Google is holding Summer of Code
* Josh Berkus (j...@agliodbs.com) wrote:
> - Who wants to mentor for GSOC?
I could be a mentor.
> - Who can admin for GSOC? Thom?
>
> - Please suggest project ideas for GSOC
Will think on this.
Thanks,
Stephen
signature.asc
Description: Digital signature
Josh Berkus wrote:
> Folks,
>
> Once again, Google is holding Summer of Code. We need to assess whether
> we want to participate this year.
>
> Questions:
>
> - Who wants to mentor for GSOC?
I am open to being a mentor.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Any objection to making it a TODO?
>
> None here. I was thinking it might be a useful finger exercise for
> someone who wanted to learn about pg_dump.
Done. Thanks.
Stephen
signature.asc
Description: Digital signature
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> That payoff is a little bit too far off to motivate me to do anything in
>> this line personally, but in case anybody else is more excited about it,
>> I thought I'd get the idea into the archives.
> Any objection to making it a TO
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> That payoff is a little bit too far off to motivate me to do anything in
> this line personally, but in case anybody else is more excited about it,
> I thought I'd get the idea into the archives.
Any objection to making it a TODO? Might be a bit light for
Andres Freund writes:
> On 2013-02-14 20:47:11 -0500, Tom Lane wrote:
>> Yeah, probably worth doing. At the time we thought that that code path
>> was just a short-term legacy thing for loading ancient pg_dump files.
>> However, given that even modern pg_dumps will use this syntax if
>> necessary
On 2013-02-14 20:47:11 -0500, Tom Lane wrote:
> Andres Freund writes:
> > due to no respective element being in in table_toast_list nothing is
> > vacuumed and you cannot escape the situation. Not very nice. I wonder if
> > we should do something about it even due 8.3 is formally out of support,
>
Andres Freund writes:
> due to no respective element being in in table_toast_list nothing is
> vacuumed and you cannot escape the situation. Not very nice. I wonder if
> we should do something about it even due 8.3 is formally out of support,
Out of support is out of support. We're certainly not
>For my Python DBAPI2 PostgreSQL driver I plan the following optimizations:
I suggest you have a look at my Python ocpgdb driver:
http://code.google.com/p/ocpgdb/
It uses the v3 binary protocol exclusively (to avoid the usual escaping
security issues). A number of gotchyas were discovered al
Hi,
While investigating an anti-wraparound shutdown issue of Peter
H. Ezetta (cced) on IRC the issue came up that when you:
CREATE TABLE foo(id int, text text);
CREATE RULE "_RETURN" AS ON SELECT TO foo DO INSTEAD SELECT 1::int AS id,
''::text AS text;
a) the view keeps its relfrozenxid value
b
On Thu, Feb 14, 2013 at 07:21:27PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Agreed. The attached patch modifies pg_check_dir() to report about
> > invisible and lost+found directory entries, and give more helpful
> > messages to the user.
>
> I'm not terribly thrilled with special-casi
Bruce Momjian writes:
> Agreed. The attached patch modifies pg_check_dir() to report about
> invisible and lost+found directory entries, and give more helpful
> messages to the user.
I'm not terribly thrilled with special-casing 'lost+found' like that,
since it's an extremely filesystem-dependen
On 14 February 2013 23:49, Tom Lane wrote:
> Any objections?
Makes sense to me.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to y
On 14.2.2013 22:24, Alvaro Herrera wrote:
> Alvaro Herrera escribió:
>> Here's a ninth version of this patch. (version 8 went unpublished). I
>> have simplified a lot of things and improved some comments; I think I
>> understand much of it now. I think this patch is fairly close to
>> committabl
I'm trying to whack the postgres_fdw patch into committable shape, with
one eye on the writable-foreign-tables patch that's right behind it in
the queue. One thing I've come across is that the timing of remote
commits is a mess. As-is in the submitted patches, we'll issue a commit
to the remote s
First of all, big thanks for working on this patch and not only
identifying the issues but actually fixing them.
On 14.2.2013 20:23, Alvaro Herrera wrote:
> Here's a ninth version of this patch. (version 8 went unpublished). I
> have simplified a lot of things and improved some comments; I think
On 14.2.2013 20:43, Josh Berkus wrote:
> I saw discussion about this on this thread, but I'm not able to figure
> out what the answer is: how does this work with moving the stats file,
> for example to a RAMdisk? Specifically, if the user sets
> stats_temp_directory, does it continue to work the w
On Tue, Feb 5, 2013 at 08:49:17AM -0500, Peter Eisentraut wrote:
> On 2/5/13 7:32 AM, Kevin Grittner wrote:
> > Sean Chittenden wrote:
> >
> >> > Currently src/port/pgcheckdir.c will reject non-empty
> >> > directories, which is an issue during initdb(1) when PGDATA is
> >> > also the mount poin
On Thu, Feb 14, 2013 at 11:11:13AM +0400, Alexander Law wrote:
> Hello,
> Alexander Law writes:
>> Please look at the following l10n bug:
>> http://www.postgresql.org/message-id/502a26f1.6010...@gmail.com
>> and the proposed patch.
>> With your proposed change, the problem will res
On 14 February 2013 18:02, Josh Berkus wrote:
> Folks,
>
> Once again, Google is holding Summer of Code. We need to assess whether
> we want to participate this year.
>
> Questions:
>
> - Who wants to mentor for GSOC?
>
> - Who can admin for GSOC? Thom?
I don't mind being an admin again.
--
T
On Wed, Feb 13, 2013 at 11:40 AM, Alvaro Herrera
wrote:
> Andrew Dunstan wrote:
>>
>> On 02/13/2013 12:07 PM, David E. Wheeler wrote:
>> >On Feb 13, 2013, at 8:36 AM, Andrew Dunstan wrote:
>
>> >>I think Merlin's suggestion if unwrap might be good. Or simply
>> >>"elements()" might work.
>> >Per
Hello,
Well i'm interested in PostgreSQL for GSOC, i'm not sure for the project
yet. But i'm looking forward in meeting the mentors and speak with them
what could be implemented over the summer.
Thanks,
Sirbu Nicolae-Cezar
Alvaro Herrera escribió:
> Here's a ninth version of this patch. (version 8 went unpublished). I
> have simplified a lot of things and improved some comments; I think I
> understand much of it now. I think this patch is fairly close to
> committable, but one issue remains, which is this bit in
>
Robert Haas writes:
> Wait, I'm confused. I had a note to myself to come back and review
> this, but now that I look at it, I didn't think that patch was pending
> review. Alvaro, Tom, and I all made comments that seems to impinge
> upon that design rather heavily. No?
The current design follo
Alvaro Herrera escribió:
> Here's a ninth version of this patch. (version 8 went unpublished). I
> have simplified a lot of things and improved some comments; I think I
> understand much of it now. I think this patch is fairly close to
> committable, but one issue remains, which is this bit in
>
On Thu, Feb 14, 2013 at 7:45 AM, Jehan-Guillaume de Rorthais
wrote:
> Hi,
>
> I am facing an unexpected behavior on a 9.2.2 cluster that I can
> reproduce on current HEAD.
>
> On a cluster with archive enabled but failing, after a crash of
> postmaster, the checkpoint occurring before leaving the
Josh Berkus wrote:
> I saw discussion about this on this thread, but I'm not able to figure
> out what the answer is: how does this work with moving the stats file,
> for example to a RAMdisk? Specifically, if the user sets
> stats_temp_directory, does it continue to work the way it does now?
Of
I saw discussion about this on this thread, but I'm not able to figure
out what the answer is: how does this work with moving the stats file,
for example to a RAMdisk? Specifically, if the user sets
stats_temp_directory, does it continue to work the way it does now?
--
Josh Berkus
PostgreSQL Exp
On 14/02/2013 20:01, Peter Eisentraut wrote:
On 2/14/13 9:23 AM, Manlio Perillo wrote:
1) always use PQsendQueryParams functions.
This will avoid having to escape parameters, as it is done in
psycopg2
(IMHO it still use simple query protocol for compatibility purpose)
I think the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 14/02/2013 20:01, Peter Eisentraut ha scritto:
> On 2/14/13 9:23 AM, Manlio Perillo wrote:
>> 1) always use PQsendQueryParams functions.
>>
>>This will avoid having to escape parameters, as it is done in
>>psycopg2
>>(IMHO it still use s
Here's a ninth version of this patch. (version 8 went unpublished). I
have simplified a lot of things and improved some comments; I think I
understand much of it now. I think this patch is fairly close to
committable, but one issue remains, which is this bit in
pgstat_write_statsfiles():
Alvaro Herrera escribió:
> Hm, and I now also realize another bug in this patch: the global stats
> only include database entries for requested databases; but perhaps the
> existing files can serve later requestors just fine for databases that
> already had files; so the global stats file should c
On 2/14/13 9:23 AM, Manlio Perillo wrote:
> 1) always use PQsendQueryParams functions.
>
>This will avoid having to escape parameters, as it is done in
>psycopg2
>(IMHO it still use simple query protocol for compatibility purpose)
I think the reason this doesn't work is that in order
On Mon, Feb 11, 2013 at 5:46 PM, Pavan Deolasee
wrote:
> On Fri, Feb 8, 2013 at 10:25 PM, Fujii Masao wrote:
> .>
>> BTW, the cause of the problem is that the following sequences happens.
>>
>> 1. archive_timeout switches WAL file because checkpoint WAL record has
>> has been written since la
Folks,
Once again, Google is holding Summer of Code. We need to assess whether
we want to participate this year.
Questions:
- Who wants to mentor for GSOC?
- Who can admin for GSOC? Thom?
- Please suggest project ideas for GSOC
- Students seeing this -- please speak up if you have projects
On Thu, Feb 14, 2013 at 10:03 AM, Stephen Frost wrote:
> * Merlin Moncure (mmonc...@gmail.com) wrote:
>> That doesn't work. functions don't allow arbitrary returned columns.
>> CALL should support this.
>
> That's yet another discussion, though for a preview, you could just
> return a single text
On Thu, Feb 14, 2013 at 10:32 AM, Pavel Stehule wrote:
> 2013/2/14 Stephen Frost :
>> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>>> it is not true
>>
>> It most certainly is true- did you look at the command?
>>
>> SELECT top10('foo');
>>
>> Note that it's "top10", implying that it'd return
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 14/02/2013 18:18, Jonathan Rogers ha scritto:
> A number of the described features sound quite useful. Is it not
> practical to extend an existing library such as psycopg2?
I suspect there are compatibility issues.
> What method
> will you use to
On Thu, Feb 14, 2013 at 5:52 AM, Simon Riggs wrote:
> On 13 February 2013 09:04, Heikki Linnakangas wrote:
>
>> Without step 3, the server would perform crash recovery, and it would work.
>> But because of the recovery.conf file, the server goes into archive
>> recovery, and because minRecoveryPo
On Thu, Feb 14, 2013 at 5:15 AM, Heikki Linnakangas
wrote:
> On 13.02.2013 17:02, Tom Lane wrote:
>>
>> Heikki Linnakangas writes:
>>>
>>> At least in back-branches, I'd call this a pilot error. You can't turn a
>>> master into a standby just by creating a recovery.conf file. At least
>>> not if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
A number of the described features sound quite useful. Is it not
practical to extend an existing library such as psycopg2? What method
will you use to call libpq functions? As you are no doubt aware,
psycopg2 uses the traditional CPython API but there
On Mon, Feb 11, 2013 at 9:53 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>>> Robert, you specifically opposed to "sql_drop" and I just removed it
>>> from the patch. What do you think now? Also, should that be a follow-up
>>> patch to the current one for your reviewing purposes?
>>
>> Well,
On 02/15/2013 12:45 AM, Peter Eisentraut wrote:
> On 2/11/13 10:22 PM, Greg Stark wrote:
>> On Sun, Feb 10, 2013 at 11:47 PM, Tom Lane wrote:
>>> If we knew that postgresql.conf was stored in, say, UTF8, then it would
>>> probably be possible to perform encoding conversion to get string
>>> variab
On Tue, Feb 12, 2013 at 10:22 AM, Satoshi Nagayasu wrote:
> (1) Fix pgstatindex arguments to work same as pgstattuple.
>
> As the document describes, pgstattuple accepts 'schema.table'
> expression and oid of the table, but pgstatindex doesn't.
> (because I didn't add that when I created pgstatind
Stephen Frost writes:
> This discussion isn't going to change my feelings on this particular
> misfeature. If others feel it's valuable and important then they can
> certainly speak-up.
I think the same --- a new backslash command for this is absolutely not
worth its weight compared to using "TA
On 2/11/13 10:22 PM, Greg Stark wrote:
> On Sun, Feb 10, 2013 at 11:47 PM, Tom Lane wrote:
>> If we knew that postgresql.conf was stored in, say, UTF8, then it would
>> probably be possible to perform encoding conversion to get string
>> variables into the database encoding. Perhaps we should all
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> it is not easy - we have no available any formatting support on server side
Sure we do.
> so then you need to supply lot of libpq code
No, you don't.
This discussion isn't going to change my feelings on this particular
misfeature. If others fe
2013/2/14 Stephen Frost :
> * Merlin Moncure (mmonc...@gmail.com) wrote:
>> That doesn't work. functions don't allow arbitrary returned columns.
>> CALL should support this.
>
> That's yet another discussion, though for a preview, you could just
> return a single text column from the function in w
Shigeru Hanada writes:
> On Thu, Feb 14, 2013 at 1:01 PM, Tom Lane wrote:
>> * AFAICT, the patch expects to use a single connection for all
>> operations initiated under one foreign server + user mapping pair.
>> I don't think this can possibly be workable. For instance, we don't
>> really want
2013/2/14 Stephen Frost :
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> it is not true
>
> It most certainly is true- did you look at the command?
>
> SELECT top10('foo');
>
> Note that it's "top10", implying that it'd return the first 10 records.
> That's only 2 characters more than:
In c
On Feb 13, 2013 10:35 PM, "Heikki Linnakangas"
wrote:
> We could support operator("?") as well; belt and suspenders. That would
help ODBC clients too.
+1 for the belt and suspenders approach. With {postgres qm} JDBC can work
with older PostgreSQL versions, not requiring applications to bump their
On Feb 13, 2013 10:29 PM, "Heikki Linnakangas"
wrote:
> Hmm, I just realized a little problem with that approach. If you take a
base backup using an atomic filesystem backup from a running server, and
start archive recovery from that, that's essentially the same thing as
Kyotaro's test case.
Coin
* Merlin Moncure (mmonc...@gmail.com) wrote:
> That doesn't work. functions don't allow arbitrary returned columns.
> CALL should support this.
That's yet another discussion, though for a preview, you could just
return a single text column from the function in which you do whatever
formatting you
Kohei KaiGai writes:
> 2013/2/14 Tom Lane :
>> * deparse.c contains a depressingly large amount of duplication of logic
>> from ruleutils.c, and can only need more as we expand the set of
>> constructs that can be pushed to the remote end. This doesn't seem like
>> a maintainable approach. Was t
On Thu, Feb 14, 2013 at 12:29:52AM -0500, Bruce Momjian wrote:
> You might remember this pg_upgrade bug report where the user complained
> that user-defined tablespaces _inside_ the old cluster directory were
> deleted by the old cluster delete script:
>
>
> http://www.postgresql.org/messag
On Thu, Feb 14, 2013 at 8:43 AM, Stephen Frost wrote:
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> My proposal should not replace stored procedures.
>
> Stored procedures, with actual transaction-management capabilities, is a
> completely different topic which isn't usefully involved here
Hi,
I am facing an unexpected behavior on a 9.2.2 cluster that I can
reproduce on current HEAD.
On a cluster with archive enabled but failing, after a crash of
postmaster, the checkpoint occurring before leaving the recovery mode
deletes any additional WALs, even those waiting to be archived.
Be
Pavel Stehule escribió:
> 2013/2/14 Stephen Frost :
> > * Merlin Moncure (mmonc...@gmail.com) wrote:
> >> CALL top10('foo');
> >>
> >> which seems more general and just as terse. So I think implementing
> >> call syntax is probably topping my 'wanted feature' list.
> >
> > We have that, it's calle
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> My proposal should not replace stored procedures.
Stored procedures, with actual transaction-management capabilities, is a
completely different topic which isn't usefully involved here.
> The core of my proposal was using autocomplete for one oft
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> it is not true
It most certainly is true- did you look at the command?
SELECT top10('foo');
Note that it's "top10", implying that it'd return the first 10 records.
That's only 2 characters more than:
CALL top10('foo');
It's not as short as '\v
2013/2/14 Stephen Frost :
> * Merlin Moncure (mmonc...@gmail.com) wrote:
>> CALL top10('foo');
>>
>> which seems more general and just as terse. So I think implementing
>> call syntax is probably topping my 'wanted feature' list.
>
> We have that, it's called 'SELECT' and it's only 2 more characte
On 2013-02-14 09:33:51 -0500, Stephen Frost wrote:
> * Merlin Moncure (mmonc...@gmail.com) wrote:
> > CALL top10('foo');
> >
> > which seems more general and just as terse. So I think implementing
> > call syntax is probably topping my 'wanted feature' list.
>
> We have that, it's called 'SELECT
2013/2/14 Merlin Moncure :
> On Thu, Feb 14, 2013 at 1:25 AM, Pavel Stehule
> wrote:
>> few year ago I proposed a implementation of macros - and I wrote a
>> prototype - enhanced psql
>>
>> http://okbob.blogspot.cz/search?q=epsql
>>
>> but now I don't think so enhancing psql in this direction is
* Merlin Moncure (mmonc...@gmail.com) wrote:
> CALL top10('foo');
>
> which seems more general and just as terse. So I think implementing
> call syntax is probably topping my 'wanted feature' list.
We have that, it's called 'SELECT' and it's only 2 more characters..
Thanks,
On Thu, Feb 14, 2013 at 1:25 AM, Pavel Stehule wrote:
> few year ago I proposed a implementation of macros - and I wrote a
> prototype - enhanced psql
>
> http://okbob.blogspot.cz/search?q=epsql
>
> but now I don't think so enhancing psql in this direction is good way.
> Enhanced console needs cre
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 14/02/2013 14:06, Albe Laurenz ha scritto:
> Manlio Perillo wrote:
>> Sorry for the question, but where can I find the libpq test suite?
>> I can not find it in the PostgreSQL sources; it seems that there are
>> only some examples, in src/test/examp
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> Native implementation of \vt is terrible simple - and it is generic
> and usual task
I'm still a -1 on this. We don't have anything like this today and I
don't think it's a good idea to try adding these kinds of
shortcuts-for-generic-SQL to psql'
Manlio Perillo wrote:
> Sorry for the question, but where can I find the libpq test suite?
> I can not find it in the PostgreSQL sources; it seems that there are
> only some examples, in src/test/examples.
The regression tests are in src/interfaces/libpq/test
and currently contain only URL parsing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi.
Sorry for the question, but where can I find the libpq test suite?
I can not find it in the PostgreSQL sources; it seems that there are
only some examples, in src/test/examples.
I'm planning to add some new features to libpq:
* make PQsendP
On Thu, Feb 14, 2013 at 6:45 PM, Albe Laurenz wrote:
> Shigeru Hanada wrote:
>> Tom Lane wrote:
>>> It ought to be pulling the rows back a few at a time, and
>>> that's not going to work well if multiple scans are sharing the same
>>> connection. (We might be able to dodge that by dec
Shigeru Hanada wrote:
> Tom Lane wrote:
>> It ought to be pulling the rows back a few at a time, and
>> that's not going to work well if multiple scans are sharing the same
>> connection. (We might be able to dodge that by declaring a cursor
>> for each scan, but I'm not convinced that
On Thu, Feb 14, 2013 at 1:01 PM, Tom Lane wrote:
> * The code seems to always use GetOuterUserId() to select the foreign
> user mapping to use. This seems entirely wrong. For instance it will
> do the wrong thing inside a SECURITY DEFINER function, where surely the
> relevant privileges should b
On 12.02.2013 16:55, Alvaro Herrera wrote:
Create libpgcommon, and move pg_malloc et al to it
libpgcommon is a new static library to allow sharing code among the
various frontend programs and backend; this lets us eliminate duplicate
implementations of common routines. We avoid libpgport, becau
79 matches
Mail list logo
