On Tue, 2009-10-13 at 11:39 +0900, Itagaki Takahiro wrote:
> We can skip writing WAL during COPY and CLUSTER if archive_mode is off,
> but we don't use the skipping during tables rewrites in ALTER TABLE.
> Also we don't use BulkInsertState there.
>
> Is it possible to use WAL-skipping and BulkIns
On Mon, 2009-10-12 at 22:22 -0700, Jeff Davis wrote:
> On Mon, 2009-10-12 at 22:13 -0700, Josh Berkus wrote:
> > However, for *two* settings, and two settings only, we distinguish that
> > by naming an identical setting "default_*" in postgresql.conf. This is
> > confusing and inconsistent with th
Please can someone pass me details on/off-list about joining the SQL
Standard Committee, as discussed at developer meeting in May.
Thanks,
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Tue, 2009-10-13 at 10:18 +0100, Simon Riggs wrote:
> Please can someone pass me details on/off-list about joining the SQL
> Standard Committee, as discussed at developer meeting in May.
I have replied to Simon off-list about the details, which had also been
forwarded to the funds group.
The cu
On Wed, 2009-10-07 at 13:07 -0400, Alvaro Herrera wrote:
> David Fetter wrote:
>
> > I seem to recall that there were some patches to get psql to help with
> > such things, but they didn't go in. Time to revive them?
>
> Yeah, the API they implemented wasn't ideal, so there was some
> discussion
Tom Lane wrote:
Ultimately, there's always going to be a tradeoff between speed and
flexibility. It may be that we should just say "if you want to import
dirty data, it's gonna cost ya" and not worry about the speed penalty
of subtransaction-per-row. But that still leaves us with the 2^32
limit
Robert Haas wrote:
> I sometimes want to know what the planner thinks the cost of some
> plan other than the one actually selected would be.
Another DBMS I used for years had a way to turn on an *extremely*
verbose mode for their planner; it showed everything it considered
with its related cos
Kevin Grittner wrote:
> Robert Haas wrote:
>
> > I sometimes want to know what the planner thinks the cost of some
> > plan other than the one actually selected would be.
>
> Another DBMS I used for years had a way to turn on an *extremely*
> verbose mode for their planner; it showed everythin
Jeff Davis wrote:
> It appears that the patch here:
>
> http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=a30fa4ca33d055c46bebc0e5c701d5b4fd27814d
>
> missed adding PGC_S_DATABASE_USER to a few locations, most notably
> GucSource_Names, where the PGC_S_SESSION now points off the end of
Emmanuel Cecchet writes:
> - speed with error logging best effort: no use of sub-transactions but
> errors that can safely be trapped with pg_try/catch (no index violation,
There aren't any. You can *not* put a try/catch around arbitrary code
without a subtransaction. Don't even think about i
Tom Lane wrote:
> 5. Now commit in the second session. First session resumes and
> prints
>
> f1 | f2 | f3 | f4
> +++-
> 1 | 1 | 1 | 111
> 1 | 1 | 1 | 112
> 2 | 42 | 2 | 113
> 2 | 42 | 2 | 114
> 2 | 42 | 2 | 113
> 2 | 42 | 2 | 114
> (6 rows)
>
> Of cours
"Kevin Grittner" writes:
> Is this related to issue 4593?
No, not directly. Now that locking is done in a separate plan node,
we could think about addressing #4593 by switching the order of the
LockRows and Sort plan nodes, but that has nothing to do with how
well EvalPlanQual works.
I was plan
A useful feature found in other DBMSs such as MS SQL Server that has
been requested on these lists a few times, is the ability for a client
application to report its name to the server. This information may
then be presented in logs, activity reports and so on to aid debugging
and help the sysadmin
Dave Page wrote:
> The attached patch is a first quick cut of the basic functionality to
> do this. Currently, it makes the following changes:
Couple of thoughts,
- should we use argv[0] automatically in libpq unless overridden?
- should we reject funny chars such as \n? (hopefully \0 won't be a
Dave Page wrote:
My questions to the group are:
- Is my approach reasonable?
- What interface should I include in libpq?
On the second question, obviously the user can call SET to set a
value, as I've done for now in psql, however in other DBMSs, it may be
set in the connection string. My fee
On Tue, Oct 13, 2009 at 4:06 PM, Alvaro Herrera
wrote:
> Dave Page wrote:
>
>> The attached patch is a first quick cut of the basic functionality to
>> do this. Currently, it makes the following changes:
>
> Couple of thoughts,
>
> - should we use argv[0] automatically in libpq unless overridden?
On Tue, Oct 13, 2009 at 4:11 PM, Andrew Dunstan wrote:
>
> Doing it with a GUC will not be nearly so useful as having it in the wire
> protocol, IMNSHO. Just one example: it wouldn't be present in connection
> records, because it wouldn't be set yet.
I quite like the flexibility of being able to
Dave Page wrote:
> On Tue, Oct 13, 2009 at 4:06 PM, Alvaro Herrera
> wrote:
> > - should we reject funny chars such as \n? (hopefully \0 won't be a
> > problem)
>
> Is there any need? I can't see that it would do any harm other than
> maybe messing up some query output - and the solution would b
Dave Page wrote:
On Tue, Oct 13, 2009 at 4:11 PM, Andrew Dunstan wrote:
Doing it with a GUC will not be nearly so useful as having it in the wire
protocol, IMNSHO. Just one example: it wouldn't be present in connection
records, because it wouldn't be set yet.
I quite like the flexib
Itagaki Takahiro writes:
> Here is an update version of buffer usage patch.
I started to look at this patch, and I have a few comments:
1. I was expecting this patch to get rid of ShowBufferUsage() and friends
altogether, instead of adding yet more static counters to support them.
Isn't that stu
On Tue, Oct 13, 2009 at 4:34 PM, Andrew Dunstan wrote:
>
> From time to time people ask for "scalar variable" facility. ISTM what
> you're trying to do is just a special case of that. Maybe we could approach
> it by providing a builtin (and non-removable) custom_variable_classes entry
> ('pg_varia
Dave Page writes:
> - Is my approach reasonable?
> - What interface should I include in libpq?
I thought the plan was to have libpq look at an environment variable,
compare PGCLIENTENCODING for example. I'm not convinced psql should be
involved in the logic at all --- if it is, there definitely
Dave Page writes:
> On Tue, Oct 13, 2009 at 4:06 PM, Alvaro Herrera
> wrote:
>> - should we use argv[0] automatically in libpq unless overridden?
> How can I get to it from libpq?
You can't.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
Dave Page writes:
> On Tue, Oct 13, 2009 at 4:34 PM, Andrew Dunstan wrote:
>> From time to time people ask for "scalar variable" facility.
> I'm not sure that's really related to this
It isn't; I think Andrew confused this thread with the one where someone
wanted to know about trigger context.
On Tue, Oct 13, 2009 at 5:05 PM, Tom Lane wrote:
> Dave Page writes:
>> - Is my approach reasonable?
>> - What interface should I include in libpq?
>
> I thought the plan was to have libpq look at an environment variable,
I wasn't aware we had a plan :-)
> compare PGCLIENTENCODING for example.
Tom Lane wrote:
Dave Page writes:
On Tue, Oct 13, 2009 at 4:34 PM, Andrew Dunstan wrote:
From time to time people ask for "scalar variable" facility.
I'm not sure that's really related to this
It isn't; I think Andrew confused this thread with the one where someo
On http://www.postgresql.org/docs/8.4/interactive/protocol.html we say:
"Higher level features built on this protocol (for example, how libpq
passes certain environment variables when the connection is
established) are covered elsewhere."
I cannot find anything that is obviously 'elsewhere' in th
On Tue, 13 Oct 2009, Dave Page wrote:
A useful feature found in other DBMSs such as MS SQL Server that has
been requested on these lists a few times, is the ability for a client
application to report its name to the server. This information may
then be presented in logs, activity reports and s
>I can have libpq look at the environment as it does for
>PGCLIENTENCODING, but I'd certainly like to be able to use the
>connection string as well, as environment variables are not really the
another challenge with the Environment variable: they are (at least on
windows) usually set for one logge
Tom Lane wrote:
Emmanuel Cecchet writes:
- speed with error logging best effort: no use of sub-transactions but
errors that can safely be trapped with pg_try/catch (no index violation,
There aren't any. You can *not* put a try/catch around arbitrary code
without a subtransaction. D
Emmanuel Cecchet writes:
> Tom was also suggesting 'refactoring COPY into a series of steps that the
> user can control'. What would these steps be? Would that be per row and
> allow to discard a bad tuple?
The idea is to have COPY usable from a general SELECT query so that the
user control what
At 2009-10-13 17:25:15 +0100, dp...@pgadmin.org wrote:
>
> I cannot find anything that is obviously 'elsewhere' in the docs -
> does that need fixing, or do my searching skills need improving?
I don't know, but…
> *starts reading source code* :-)
Look at what fe-protocol3.c:build_startup_packet(
On Tue, Oct 13, 2009 at 5:41 PM, Abhijit Menon-Sen wrote:
> At 2009-10-13 17:25:15 +0100, dp...@pgadmin.org wrote:
>>
>> I cannot find anything that is obviously 'elsewhere' in the docs -
>> does that need fixing, or do my searching skills need improving?
>
> I don't know, but…
>
>> *starts readin
On Tuesday 13 October 2009 18:30:54 Massa, Harald Armin wrote:
> >I can have libpq look at the environment as it does for
> >PGCLIENTENCODING, but I'd certainly like to be able to use the
> >connection string as well, as environment variables are not really the
> another challenge with the Environ
On Tue, Oct 13, 2009 at 12:05 PM, Tom Lane wrote:
> Dave Page writes:
>> - Is my approach reasonable?
>> - What interface should I include in libpq?
>
> I thought the plan was to have libpq look at an environment variable,
> compare PGCLIENTENCODING for example. I'm not convinced psql should be
Emmanuel Cecchet writes:
> Tom Lane wrote:
>> There aren't any. You can *not* put a try/catch around arbitrary code
>> without a subtransaction. Don't even think about it.
>>
> Well then why the tests provided with the patch are working?
Because they carefully exercise only a tiny fraction of
Robert Haas writes:
> What happens if we want to change the application name after the fact?
As long as it's a GUC variable you can just do SET. I think the point
of discussion is what is the best convention for getting it set
initially.
regards, tom lane
--
Sent via p
On Tue, Oct 13, 2009 at 11:55 AM, Robert Haas wrote:
>
> What happens if we want to change the application name after the fact?
> Consider the case where there is a connection pooler between the
> database and application, for example.
>
good point...
--
Atentamente,
Jaime Casanova
Soporte y c
On Tue, 13 Oct 2009, Dave Page wrote:
On http://www.postgresql.org/docs/8.4/interactive/protocol.html we say:
"Higher level features built on this protocol (for example, how libpq
passes certain environment variables when the connection is
established) are covered elsewhere."
http://www.postg
Peter,
> The current status is that no one at INCITS is replying to my emails.
> If someone preferably in the right time zone is interested in phoning
> them up or pursuing other means of getting an answer out of them, please
> let me know privately. I can't give this the attention it apparently
Dave Page writes:
> Right. My complaint though, is that the docs imply that the info on
> how those values get set is in the docs somewhere, which appears to be
> incorrect.
The libpq documentation does cover the fact that libpq uses those
variables to establish initial settings. I wouldn't expe
Dave Page writes:
> On Tue, Oct 13, 2009 at 5:05 PM, Tom Lane wrote:
>> Dave Page writes:
>>> - Is my approach reasonable?
>>
>> I thought the plan was to have libpq look at an environment variable,
> I wasn't aware we had a plan :-)
There was some previous discussion of this, which I am too
> Yeah, they basically have semantics specified by the SQL standard that
> are not compatible with anything else in GUC land. They are more like
> SET LOCAL settings, but again not quite.
Mind you, transaction_isolation and transaction_read_only aren't
documented anywhere in our docs *as setting
On Tue, Oct 13, 2009 at 6:24 PM, Tom Lane wrote:
> Dave Page writes:
>> Right. My complaint though, is that the docs imply that the info on
>> how those values get set is in the docs somewhere, which appears to be
>> incorrect.
>
> The libpq documentation does cover the fact that libpq uses those
On Tue, Oct 13, 2009 at 6:38 PM, Tom Lane wrote:
> Dave Page writes:
>> On Tue, Oct 13, 2009 at 5:05 PM, Tom Lane wrote:
>>> Dave Page writes:
- Is my approach reasonable?
>>>
>>> I thought the plan was to have libpq look at an environment variable,
>
>> I wasn't aware we had a plan :-)
>
On Tue, 2009-10-13 at 09:14 -0500, Kevin Grittner wrote:
> Now that we can generate EXPLAIN output in more structured formats,
> perhaps we could think about adding an "extremely verbose" mode where
> the planner would "think out loud" as a whole separate section from
> where we show the chosen pla
On Tue, 2009-10-13 at 11:26 -0700, Jeff Davis wrote:
> On Tue, 2009-10-13 at 09:14 -0500, Kevin Grittner wrote:
> > Now that we can generate EXPLAIN output in more structured formats,
> > perhaps we could think about adding an "extremely verbose" mode where
> > the planner would "think out loud" as
On Tue, Oct 13, 2009 at 10:14 AM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> I sometimes want to know what the planner thinks the cost of some
>> plan other than the one actually selected would be.
>
> Another DBMS I used for years had a way to turn on an *extremely*
> verbose mode for their
On Tue, Oct 13, 2009 at 1:07 PM, Dave Page wrote:
>
> Oh, and apologies to Jaime who I just noticed had volunteered to work
> on this :-(
>
never mind... i get blocked for the ugliness of the libpq api connect
functions...
and my first attempt to solve that was seriously broken...
besides, as Ro
On Tue, Oct 13, 2009 at 9:13 PM, Jaime Casanova
wrote:
> On Tue, Oct 13, 2009 at 1:07 PM, Dave Page wrote:
>>
>> Oh, and apologies to Jaime who I just noticed had volunteered to work
>> on this :-(
>>
>
> never mind... i get blocked for the ugliness of the libpq api connect
> functions...
> and m
Roger Leigh writes:
> The attached updated patch renames all user-visible uses of
> "utf8" to "unicode". It also updates the documentation
> regarding "locale" to "psql client character set encoding"
> so the docs now match the code exactly.
Applied with light editorialization. The main non-cos
Dave Page writes:
> On Tue, Oct 13, 2009 at 9:13 PM, Jaime Casanova
> wrote:
>> besides, as Robert mention, because of pooler connections using a GUC
>> is more appropiate...
> I'd like both options to be available to the programmer.
We have several things already that can be fed either from an
On Tue, 13 Oct 2009, Robert Haas wrote:
An exhaustive dump of everything the planner has considered is going to
be a LOT of data, and I don't really want to have to set up a graphical
visualization tool every time I have a planning question. I am a
command-line kind of guy...
Wouldn't this
On Sat, 2009-10-10 at 00:04 +0300, Peter Eisentraut wrote:
> On Mon, 2009-09-14 at 18:58 +0900, Itagaki Takahiro wrote:
> > Itagaki Takahiro wrote:
> >
> > > Ok, the attached patch implements standard-compliant version of
> > > column trigger.
> >
> > Here is an updated version of column-level t
KaiGai Kohei writes:
> The attached patch is the revised one for largeobejct access controls,
> because it conflicted to the "GRANT/REVOKE ON ALL xxx IN SCHEMA".
I started to look through this patch with the hope of committing it, but
found out that it's not really ready.
The most serious proble
Tom Lane wrote:
> KaiGai Kohei writes:
>> The attached patch is the revised one for largeobejct access controls,
>> because it conflicted to the "GRANT/REVOKE ON ALL xxx IN SCHEMA".
>
> I started to look through this patch with the hope of committing it, but
> found out that it's not really ready
56 matches
Mail list logo
