> This is only true for server encodings. In a client library I think
> you lose on this and do have to deal with it. I'm not sure what client
> encodings we do support that aren't ascii-supersets though, it's
> possible none of them generate quote characters this way.
We have a clear definition w
> Personally, I think the first thing we ought to do is add a real, bona
> fide planner hint to override the selectivity calculation manually,
> maybe something like this:
>
> WHERE (x < 5 AND y = 1) SELECTIVITY (0.1);
>
If you're going to go that far, why not just collect statistics on
that spec
Dan Ports wrote:
> The obvious solution to me is to just keep the lock on both the old
> and new page.
That's the creative thinking I was failing to do. Keeping the old
lock will generate some false positives, but it will be rare and
those don't compromise correctness -- they just carry the c
On Wed, Feb 23, 2011 at 4:16 AM, Peter Geoghegan
wrote:
> Since Postgres only supports encodings that are ASCII supersets, I
> don't believe that I have to consider encoding - only my clients do.
>
This is only true for server encodings. In a client library I think
you lose on this and do have to
I'm investigating the possibility of developing a utility function for
our C++ client library, libpqxx, that produces array literals that can
be used in prepared statements. This problem appears to be a bit of a
tar pit, so I'm hoping that someone can help me out. My goal is to
produce a template f
> Right now pg_options_to_table() is not documented. Should it be?
Yes, I think so.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
--
Sent via pgsql-hackers mailin
Robert Haas writes:
> On Tue, Feb 22, 2011 at 9:43 PM, Tom Lane wrote:
>> One of the criteria we've always had for a suitable hint-or-whatever-
>> you-call-it design is that it *not* involve decorating the queries.
> [ snip ]
> To put that another way, it's true that some people can't adjust the
On Tue, Feb 22, 2011 at 9:43 PM, Tom Lane wrote:
> Robert Haas writes:
>> /me prepares to go down in flames.
>
>> Personally, I think the first thing we ought to do is add a real, bona
>> fide planner hint to override the selectivity calculation manually,
>> maybe something like this:
>
>> WHERE
Robert Haas writes:
> /me prepares to go down in flames.
> Personally, I think the first thing we ought to do is add a real, bona
> fide planner hint to override the selectivity calculation manually,
> maybe something like this:
> WHERE (x < 5 AND y = 1) SELECTIVITY (0.1);
One of the criteria w
On Tue, Feb 22, 2011 at 9:26 PM, Tom Lane wrote:
>> Well, unfortunately, there's an awful lot of information that can only
>> be obtained in a reasonable way by introspection of the system
>> catalogs. If you want to know whether user A can select from table B,
>> there's really no sensible way o
Robert Haas writes:
> On Tue, Feb 22, 2011 at 8:20 PM, Tom Lane wrote:
>> ... But my question isn't about that; it's about why
>> aclitem should be considered a first-class citizen. It makes me
>> uncomfortable that client apps are looking at it at all, because any
>> that do are bound to get br
On Tue, Feb 22, 2011 at 8:55 PM, Alvaro Herrera
wrote:
> The current discussion seems to have reached the same conclusion as the
> last one: the snapshot info shouldn't leave the server, but be
> transmitted internally -- the idea of the temp file seems prevalent.
> Here's an attempt at a detailed
2011/2/22 PostgreSQL - Hans-Jürgen Schönig :
> how does it work? we try to find suitable statistics for an arbitrary length
> list of conditions so that the planner can use it directly rather than
> multiplying all the selectivities. this should make estimates a lot more
> precise.
> the current
The current discussion seems to have reached the same conclusion as the
last one: the snapshot info shouldn't leave the server, but be
transmitted internally -- the idea of the temp file seems prevalent.
Here's an attempt at a detailed spec:
By invoking pg_export_snapshot(), a transaction can exp
On Tue, Feb 22, 2011 at 05:54:49PM -0600, Kevin Grittner wrote:
> I'm not sure it's safe to assume that the index page won't get
> reused before the local lock information is cleared. In the absence
> of a clear proof that it is safe, or some enforcement mechanism to
> ensure that it is, I don't t
[ removing Radoslaw from the CC list, as his email is bouncing every time ]
On Tue, Feb 22, 2011 at 8:20 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Feb 22, 2011 at 5:24 PM, Tom Lane wrote:
>>> It'd be more future-proof than this patch, but I'm still unconvinced
>>> about the use-case.
Here is a patch to support CREATE UNLOGGED TABLE in psql tab-completion.
It also fixes a bug that DROP is completed with TEMP and UNIQUE unexpectedly
and cleanup codes for DROP OWNED BY in drop_command_generator().
--
Itagaki Takahiro
psql_tab_completion_for_unlogged-20110223.patch
Description:
Robert Haas writes:
> On Tue, Feb 22, 2011 at 5:24 PM, Tom Lane wrote:
>> It'd be more future-proof than this patch, but I'm still unconvinced
>> about the use-case.
> Do we want to intentionally make binary format a second-class citizen?
Well, it's not exactly a first-class citizen; compare fo
On Tue, Feb 22, 2011 at 8:00 PM, Joachim Wieland wrote:
> Both Tom and Robert voted quite explicitly against the
> store-in-shared-memory idea.
No, I voted *for* that approach.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers
On Tue, Feb 22, 2011 at 5:24 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 02/22/2011 05:04 PM, Tom Lane wrote:
>>> I think this one has got far less use-case than the other, and I don't
>>> want to expose the internal representation of ACLITEM to the world.
>
>> The sendv for enums sends th
On Tue, Feb 22, 2011 at 3:34 PM, Heikki Linnakangas
wrote:
> On 22.02.2011 16:29, Robert Haas wrote:
>> On Tue, Feb 22, 2011 at 8:58 AM, Heikki Linnakangas
>> wrote:
>>> No, the hash is stored in shared memory. The hash of the garbage has to
>>> match.
>>
>> Oh. Well that's really silly. At th
I wrote:
> I did a bit of poking around here, and came to the following
> conclusions:
> 1. We don't want to add another RTEKind. RTE_RELATION basically has the
> semantics of "anything with a pg_class OID", so it ought to include
> foreign tables. Therefore the fix ought to be to add relkind to
Dan Ports wrote:
> On Tue, Feb 22, 2011 at 10:51:05AM -0600, Kevin Grittner wrote:
> The theory was before that the local lock table would only have
> false negatives, i.e. if it says we hold a lock then we really do.
> That makes it a useful heuristic because we can bail out quickly
> if we're
Andrew Dunstan wrote:
> Have you performance tested it? Scanning pg_index for index
> columns for each row strikes me as likely to be unpleasant.
I haven't, yet. I had rather assumed that the index info for a
relation would have a high probability of being cached during
execution of an AFTER
On Tue, Feb 22, 2011 at 10:51:05AM -0600, Kevin Grittner wrote:
> Dan Ports wrote:
>
> > It looks like CheckTargetForConflictsIn is making the assumption
> > that the backend-local lock table is accurate, which was probably
> > even true at the time it was written.
>
> I remember we decided th
On 02/22/2011 05:32 PM, Kevin Grittner wrote:
[moving to -hackers with BC to -general]
Dimitri Fontaine wrote:
"Kevin Grittner" writes:
PL/pgSQL seems tantalizingly close to being useful for developing
a generalized trigger function for notifying the client of
changes. I don't know whethe
[moving to -hackers with BC to -general]
Dimitri Fontaine wrote:
> "Kevin Grittner" writes:
>
>> PL/pgSQL seems tantalizingly close to being useful for developing
>> a generalized trigger function for notifying the client of
>> changes. I don't know whether I'm missing something or whether
>>
Andrew Dunstan writes:
> On 02/22/2011 05:04 PM, Tom Lane wrote:
>> I think this one has got far less use-case than the other, and I don't
>> want to expose the internal representation of ACLITEM to the world.
> The sendv for enums sends the label, and ISTR there are some others that
> send the
On 02/22/2011 05:04 PM, Tom Lane wrote:
=?utf-8?q?Rados=C5=82aw_Smogura?= writes:
Actaully one more POD left it's aclitem :). In Java for e.g. it is used to
obtain column priviliges, I assume some folks may want to use it too.
I think this one has got far less use-case than the other, and I
=?utf-8?q?Rados=C5=82aw_Smogura?= writes:
> Actaully one more POD left it's aclitem :). In Java for e.g. it is used to
> obtain column priviliges, I assume some folks may want to use it too.
I think this one has got far less use-case than the other, and I don't
want to expose the internal repres
Committed this, with two changes: Changed some things around with the
way const char * is propagated. Just casting it away is not nice. Also
dropped the error tests in the _quote.sql regression test. This
generates three different wordings of error messages from Python with
2.6, 3.1, and 3.2, w
Hello,
Per the customary URL:
https://www.postgresqlconference.org/
JD
--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support, Custom Development, Engineering
http://twitter.com/cmdpromptinc | http://identi.ca/command
Hi,
Actaully one more POD left it's aclitem :). In Java for e.g. it is used to
obtain column priviliges, I assume some folks may want to use it too.
I tested only recv :-(
Acually I don't know if idea of such format is OK, but my intention was to
send roles names, so driver don't need to ask f
hello everbody,
we have spent some time in finally attacking cross column correlation. as this
is an issue which keeps bugging us for a couple of applications (some years).
this is a WIP patch which can do:
special cross column correlation specific syntax:
CREAT
On Tue, Feb 22, 2011 at 5:04 AM, Greg Smith wrote:
> Daniel Farina wrote:
>>
>> As it will be somewhat hard to prove the durability guarantees of
>> commit without special heroics, unless someone can suggest a
>> mechanism.
>
> Could you introduce a hack creating deterministic server side crashes
On Sat, Feb 19, 2011 at 11:26 PM, Robert Haas wrote:
>
> DEBUG: write 0/3027BC8 flush 0/3014690 apply 0/3014690
> DEBUG: released 0 procs up to 0/3014690
> DEBUG: write 0/3027BC8 flush 0/3027BC8 apply 0/3014690
> DEBUG: released 2 procs up to 0/3027BC8
> WARNING: could not locate ourselves on
On Fri, Feb 18, 2011 at 11:50 AM, Robert Haas wrote:
> On Fri, Feb 18, 2011 at 10:41 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Fri, Feb 18, 2011 at 10:09 AM, Simon Riggs wrote:
Make a hard state change from catchup to streaming mode.
More useful state change for monitoring pur
Robert Haas writes:
> On Tue, Feb 22, 2011 at 10:15 AM, Tom Lane wrote:
>> Yeah, this has been discussed before.
>>
>> Even though this patch is far past the CF deadline, I'm a bit tempted to
>> push it into 9.1 anyway, just so we can check off that problem.
> +1.
Done.
On Tue, Feb 22, 2011 at 8:22 AM, rsmogura wrote:
> On Tue, 22 Feb 2011 08:12:23 -0600, Merlin Moncure wrote:
>>
>> On Tue, Feb 22, 2011 at 6:01 AM, Robert Haas
>> wrote:
>>>
>>> On Sun, Feb 20, 2011 at 5:20 AM, Radosław Smogura
>>> wrote:
Just patch for missing procedures for void send
hi,
> "Kevin Grittner" wrote:
>
>> I'm proceeding on this basis.
>
> Result attached. I found myself passing around the tuple xmin value
> just about everywhere that the predicate lock target tag was being
> passed, so it finally dawned on me that this logically belonged as
> part of the targe
2011/2/22 Alvaro Herrera :
> Excerpts from Bruce Momjian's message of vie feb 18 23:41:18 -0300 2011:
>>
>> Is this a TODO item?
>
> Only to me, it seems.
looks like you suggestion get positive impact so far :-)
+1 to fix the bogosity output rather than waiting for 9.2 via a todo
>
>
> --
On 18.02.2011 12:02, Magnus Hagander wrote:
Better late than never (or?), here's the final cleanup of
pg_streamrecv for moving into the main distribution, per discussion
back in late dec or early jan. It also includes the "stream logs in
parallel to backup" part that was not completed on pg_baseb
Dan Ports wrote:
> It looks like CheckTargetForConflictsIn is making the assumption
> that the backend-local lock table is accurate, which was probably
> even true at the time it was written.
I remember we decided that it could only be false in certain ways
which allowed us to use it as a "los
Excerpts from Bruce Momjian's message of vie feb 18 23:41:18 -0300 2011:
>
> Is this a TODO item?
Only to me, it seems.
--
Álvaro Herrera
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-hackers mailing list
Greg Stark writes:
> On Tue, Feb 22, 2011 at 12:55 PM, Robert Haas wrote:
>> A little OT, but ISTM that the buffer pin mechanism by its nature is
>> prone to lock upgrade hazards.
> Except that pins don't block exclusive locks so there's no deadlock risk.
> The oddity here is on Vacuums super-e
On Mon, Feb 21, 2011 at 10:31 AM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> I needed something to test the FDW API patch with, and didn't want to
>> get involved in the COPY API changes, and also wanted to have something
>> that needs real connection management and can push down quals. So I
On Tue, Feb 22, 2011 at 10:15 AM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Tue, Feb 22, 2011 at 6:01 AM, Robert Haas wrote:
>>> What problem does this fix?
>
>> void returning functions may not be called when binary protocol is
>> requested currently. this is annoying: some drivers that w
Marti Raudsepp writes:
> On Tue, Feb 22, 2011 at 07:38, Fujii Masao wrote:
>> + SpinLockAcquire(&WalSndCtl->ctlmutex);
>> + result = WalSndCtl->sync_rep_service_available;
>> + SpinLockRelease(&WalSndCtl->ctlmutex);
>> volatile pointer needs to be used to prevent code rearrange
On Tue, Feb 22, 2011 at 12:55 PM, Robert Haas wrote:
> A little OT, but ISTM that the buffer pin mechanism by its nature is
> prone to lock upgrade hazards. A cleanup lock is essentially an
> access exclusive lock on the buffer, while a buffer pin is an access
> share lock. In the middle, we hav
Robert Haas writes:
> On Tue, Feb 22, 2011 at 10:10 AM, Tom Lane wrote:
>> I don't see a good reason to change it. The SQL standard is perfectly
>> clear that OUTER is a fully reserved word.
> My vote would be to change it. We don't normally reserve keywords
> unnecessarily.
Well, we don't li
Merlin Moncure writes:
> On Tue, Feb 22, 2011 at 6:01 AM, Robert Haas wrote:
>> What problem does this fix?
> void returning functions may not be called when binary protocol is
> requested currently. this is annoying: some drivers that wrap libpq
> or the protocol directly use the binary mode e
On Tue, Feb 22, 2011 at 10:10 AM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> On 22.02.2011 16:58, Bruce Momjian wrote:
>>> It this a TODO?
>
>> If we want to change OUTER, we should just do it now. If not, I don't
>> see a TODO here.
>
> I don't see a good reason to change it. The SQL stand
Heikki Linnakangas writes:
> On 22.02.2011 16:58, Bruce Momjian wrote:
>> It this a TODO?
> If we want to change OUTER, we should just do it now. If not, I don't
> see a TODO here.
I don't see a good reason to change it. The SQL standard is perfectly
clear that OUTER is a fully reserved word.
On 22.02.2011 16:58, Bruce Momjian wrote:
Heikki Linnakangas wrote:
On 04.10.2010 18:23, Tom Lane wrote:
I wrote:
Heikki Linnakangas writes:
Why is OUTER a type_func_name_keyword? The grammar doesn't require that,
it could as well be unreserved.
Hm, you sure? All the JOIN-related keywor
Heikki Linnakangas wrote:
> On 04.10.2010 18:23, Tom Lane wrote:
> > I wrote:
> >> Heikki Linnakangas writes:
> >>> Why is OUTER a type_func_name_keyword? The grammar doesn't require that,
> >>> it could as well be unreserved.
> >
> >> Hm, you sure? All the JOIN-related keywords used to need to b
On Tue, Feb 22, 2011 at 9:34 AM, Heikki Linnakangas
wrote:
>> Oh. Well that's really silly. At that point you might as well just
>> store the snapshot and an integer identifier in shared memory, right?
>
> Yes, that's the point I was trying to make. I believe the idea of a hash was
> that it tak
On 22.02.2011 16:29, Robert Haas wrote:
On Tue, Feb 22, 2011 at 8:58 AM, Heikki Linnakangas
wrote:
On 22.02.2011 15:52, Robert Haas wrote:
On Tue, Feb 22, 2011 at 8:01 AM, Heikki Linnakangas
wrote:
Yes. It would be good to perform those sanity checks anyway.
I don't think it's good;
On Tue, Feb 22, 2011 at 8:58 AM, Heikki Linnakangas
wrote:
> On 22.02.2011 15:52, Robert Haas wrote:
>>
>> On Tue, Feb 22, 2011 at 8:01 AM, Heikki Linnakangas
>> wrote:
>>>
>>> Yes. It would be good to perform those sanity checks anyway.
>>
>> I don't think it's good; I think it's absolutely nec
On Tue, 22 Feb 2011 08:12:23 -0600, Merlin Moncure wrote:
On Tue, Feb 22, 2011 at 6:01 AM, Robert Haas
wrote:
On Sun, Feb 20, 2011 at 5:20 AM, Radosław Smogura
wrote:
Just patch for missing procedures for void send/recv
What problem does this fix?
void returning functions may not be calle
Robert Haas wrote:
> On Fri, Feb 18, 2011 at 9:35 PM, Bruce Momjian wrote:
> > Was this implemented? ?Is it a TODO?
>
> It's not entirely clear to me that there's a meaningful win here.
> Speeding up COPY is already on the TODO list, with this link:
>
> http://archives.postgresql.org/pgsql-hacke
On Tue, Feb 22, 2011 at 6:01 AM, Robert Haas wrote:
> On Sun, Feb 20, 2011 at 5:20 AM, Radosław Smogura
> wrote:
>> Just patch for missing procedures for void send/recv
>
> What problem does this fix?
void returning functions may not be called when binary protocol is
requested currently. this i
On 22.02.2011 15:52, Robert Haas wrote:
On Tue, Feb 22, 2011 at 8:01 AM, Heikki Linnakangas
wrote:
Yes. It would be good to perform those sanity checks anyway.
I don't think it's good; I think it's absolutely necessary. Otherwise
someone can generate arbitrary garbage, hash it, and feed it
On Tue, Feb 22, 2011 at 8:01 AM, Heikki Linnakangas
wrote:
> This is hashing, not encryption, there is no key. The point is that even if
> the attacker has the hash value and knows the algorithm, he can not
> construct *another* snapshot that has the same hash.
What good does that do us?
> Yes.
On Tue, 22 Feb 2011 07:01:02 -0500, Robert Haas wrote:
On Sun, Feb 20, 2011 at 5:20 AM, Radosław Smogura
wrote:
Just patch for missing procedures for void send/recv
What problem does this fix?
Can not execute stored procedures in JDBC with out arguments, I think
function retuning void as w
On Tue, Feb 22, 2011 at 8:03 AM, Cédric Villemain
wrote:
> The fact that you didn''t saw it might be enough to reconsider the way
> we display the unlogged state (and temp state) of a relation.
>
> Maybe some a "Durability: normal, temp, unlogged" line at bottom of
> the \d output ?
The term we
On Fri, Feb 18, 2011 at 9:35 PM, Bruce Momjian wrote:
> Was this implemented? Is it a TODO?
It's not entirely clear to me that there's a meaningful win here.
Speeding up COPY is already on the TODO list, with this link:
http://archives.postgresql.org/pgsql-hackers/2008-02/msg00954.php
...and i
Daniel Farina wrote:
As it will be somewhat hard to prove the durability guarantees of
commit without special heroics, unless someone can suggest a
mechanism.
Could you introduce a hack creating deterministic server side crashes in
order to test this out? The simplest thing that comes to mind
2011/2/22 Itagaki Takahiro :
> On Tue, Feb 22, 2011 at 18:11, Cédric Villemain
> wrote:
>> 2011/2/22 Itagaki Takahiro :
>>> psql \d(+) doesn't show any information about UNLOGGED and TEMP attributes
>>> for the table. So, we cannot know the table is unlogged or not unless
>>> we directly select fr
On 22.02.2011 14:24, Robert Haas wrote:
On Tue, Feb 22, 2011 at 1:59 AM, Heikki Linnakangas
wrote:
If you don't use a cryptographically secure hash, it's easy to construct a
snapshot with the same hash as an existing snapshot, with more or less
arbitrary contents.
And if you did use a crypto
On Sun, Feb 20, 2011 at 12:39 PM, Greg Stark wrote:
> On Fri, Feb 18, 2011 at 6:59 PM, Andrew Dunstan wrote:
>> The server is running as a warm standby, and the client's application tries
>> to connect to both the master and the slave, accepting whichever lets it
>> connect (hence hot standby is
On Tue, Feb 22, 2011 at 1:59 AM, Heikki Linnakangas
wrote:
> Really? The idea of the hash is to prevent you from importing arbitrary
> snapshots into the system, allowing only copying snapshots that are in use
> by another backend. The purpose of the hash is to make sure the snapshot the
> client
On Sun, Feb 20, 2011 at 5:20 AM, Radosław Smogura
wrote:
> Just patch for missing procedures for void send/recv
What problem does this fix?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
On Tue, Feb 22, 2011 at 18:11, Cédric Villemain
wrote:
> 2011/2/22 Itagaki Takahiro :
>> psql \d(+) doesn't show any information about UNLOGGED and TEMP attributes
>> for the table. So, we cannot know the table is unlogged or not unless
>> we directly select from pg_class.relpersistence. Is this
On Tuesday 22 February 2011 09:59:21 Marti Raudsepp wrote:
> On Tue, Feb 22, 2011 at 07:38, Fujii Masao wrote:
> > + SpinLockAcquire(&WalSndCtl->ctlmutex);
> > + result = WalSndCtl->sync_rep_service_available;
> > + SpinLockRelease(&WalSndCtl->ctlmutex);
> >
> > volatile pointer
2011/2/22 Itagaki Takahiro :
> psql \d(+) doesn't show any information about UNLOGGED and TEMP attributes
> for the table. So, we cannot know the table is unlogged or not unless
> we directly select from pg_class.relpersistence. Is this a TODO item?
>
> The same issue is in TEMP tables, but we can
On Tue, Feb 22, 2011 at 07:38, Fujii Masao wrote:
> + SpinLockAcquire(&WalSndCtl->ctlmutex);
> + result = WalSndCtl->sync_rep_service_available;
> + SpinLockRelease(&WalSndCtl->ctlmutex);
> volatile pointer needs to be used to prevent code rearrangement.
I don't think that's ne
76 matches
Mail list logo
