On Tue, Feb 22, 2011 at 07:38, Fujii Masao masao.fu...@gmail.com 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
2011/2/22 Itagaki Takahiro itagaki.takah...@gmail.com:
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
On Tuesday 22 February 2011 09:59:21 Marti Raudsepp wrote:
On Tue, Feb 22, 2011 at 07:38, Fujii Masao masao.fu...@gmail.com wrote:
+ SpinLockAcquire(WalSndCtl-ctlmutex);
+ result = WalSndCtl-sync_rep_service_available;
+ SpinLockRelease(WalSndCtl-ctlmutex);
volatile
On Tue, Feb 22, 2011 at 18:11, Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
2011/2/22 Itagaki Takahiro itagaki.takah...@gmail.com:
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
On Sun, Feb 20, 2011 at 5:20 AM, Radosław Smogura
rsmog...@softperience.eu 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
On Tue, Feb 22, 2011 at 1:59 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Sun, Feb 20, 2011 at 12:39 PM, Greg Stark gsst...@mit.edu wrote:
On Fri, Feb 18, 2011 at 6:59 PM, Andrew Dunstan amduns...@nc.rr.com 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
On 22.02.2011 14:24, Robert Haas wrote:
On Tue, Feb 22, 2011 at 1:59 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
2011/2/22 Itagaki Takahiro itagaki.takah...@gmail.com:
On Tue, Feb 22, 2011 at 18:11, Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
2011/2/22 Itagaki Takahiro itagaki.takah...@gmail.com:
psql \d(+) doesn't show any information about UNLOGGED and TEMP attributes
for the table. So,
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
On Fri, Feb 18, 2011 at 9:35 PM, Bruce Momjian br...@momjian.us 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:
On Tue, Feb 22, 2011 at 8:03 AM, Cédric Villemain
cedric.villemain.deb...@gmail.com 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
On Tue, 22 Feb 2011 07:01:02 -0500, Robert Haas wrote:
On Sun, Feb 20, 2011 at 5:20 AM, Radosław Smogura
rsmog...@softperience.eu 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
On Tue, Feb 22, 2011 at 8:01 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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.
On 22.02.2011 15:52, Robert Haas wrote:
On Tue, Feb 22, 2011 at 8:01 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
On Tue, Feb 22, 2011 at 6:01 AM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Feb 20, 2011 at 5:20 AM, Radosław Smogura
rsmog...@softperience.eu wrote:
Just patch for missing procedures for void send/recv
What problem does this fix?
void returning functions may not be called when binary
Robert Haas wrote:
On Fri, Feb 18, 2011 at 9:35 PM, Bruce Momjian br...@momjian.us 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:
On Tue, 22 Feb 2011 08:12:23 -0600, Merlin Moncure wrote:
On Tue, Feb 22, 2011 at 6:01 AM, Robert Haas robertmh...@gmail.com
wrote:
On Sun, Feb 20, 2011 at 5:20 AM, Radosław Smogura
rsmog...@softperience.eu wrote:
Just patch for missing procedures for void send/recv
What problem does this
On Tue, Feb 22, 2011 at 8:58 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 22.02.2011 15:52, Robert Haas wrote:
On Tue, Feb 22, 2011 at 8:01 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Yes. It would be good to perform those sanity checks anyway.
On 22.02.2011 16:29, Robert Haas wrote:
On Tue, Feb 22, 2011 at 8:58 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 22.02.2011 15:52, Robert Haas wrote:
On Tue, Feb 22, 2011 at 8:01 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.comwrote:
Yes. It would be
On Tue, Feb 22, 2011 at 9:34 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
Heikki Linnakangas wrote:
On 04.10.2010 18:23, Tom Lane wrote:
I wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com 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
On 22.02.2011 16:58, Bruce Momjian wrote:
Heikki Linnakangas wrote:
On 04.10.2010 18:23, Tom Lane wrote:
I wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
Why is OUTER a type_func_name_keyword? The grammar doesn't require that,
it could as well be unreserved.
Hm,
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
On Tue, Feb 22, 2011 at 10:10 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Merlin Moncure mmonc...@gmail.com writes:
On Tue, Feb 22, 2011 at 6:01 AM, Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com writes:
On Tue, Feb 22, 2011 at 10:10 AM, Tom Lane t...@sss.pgh.pa.us 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
On Tue, Feb 22, 2011 at 12:55 PM, Robert Haas robertmh...@gmail.com 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
Marti Raudsepp ma...@juffo.org writes:
On Tue, Feb 22, 2011 at 07:38, Fujii Masao masao.fu...@gmail.com wrote:
+ SpinLockAcquire(WalSndCtl-ctlmutex);
+ result = WalSndCtl-sync_rep_service_available;
+ SpinLockRelease(WalSndCtl-ctlmutex);
volatile pointer needs to be used to
On Tue, Feb 22, 2011 at 10:15 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Tue, Feb 22, 2011 at 6:01 AM, Robert Haas robertmh...@gmail.com wrote:
What problem does this fix?
void returning functions may not be called when binary protocol is
requested
On Mon, Feb 21, 2011 at 10:31 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
Greg Stark gsst...@mit.edu writes:
On Tue, Feb 22, 2011 at 12:55 PM, Robert Haas robertmh...@gmail.com 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
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 alvhe...@commandprompt.com
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via
Dan Ports d...@csail.mit.edu 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
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
2011/2/22 Alvaro Herrera alvhe...@commandprompt.com:
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
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 target tag.
On Tue, Feb 22, 2011 at 8:22 AM, rsmogura rsmog...@softperience.eu wrote:
On Tue, 22 Feb 2011 08:12:23 -0600, Merlin Moncure wrote:
On Tue, Feb 22, 2011 at 6:01 AM, Robert Haas robertmh...@gmail.com
wrote:
On Sun, Feb 20, 2011 at 5:20 AM, Radosław Smogura
rsmog...@softperience.eu wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Feb 22, 2011 at 10:15 AM, Tom Lane t...@sss.pgh.pa.us 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.
On Fri, Feb 18, 2011 at 11:50 AM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Feb 18, 2011 at 10:41 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Feb 18, 2011 at 10:09 AM, Simon Riggs si...@2ndquadrant.com wrote:
Make a hard state change from
On Sat, Feb 19, 2011 at 11:26 PM, Robert Haas robertmh...@gmail.com 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
On Tue, Feb 22, 2011 at 5:04 AM, Greg Smith g...@2ndquadrant.com 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
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:
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
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 |
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,
=?utf-8?q?Rados=C5=82aw_Smogura?= rsmog...@softperience.eu 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
On 02/22/2011 05:04 PM, Tom Lane wrote:
=?utf-8?q?Rados=C5=82aw_Smogura?=rsmog...@softperience.eu 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
Andrew Dunstan and...@dunslane.net 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
[moving to -hackers with BC to -general]
Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
Kevin Grittner kevin.gritt...@wicourts.gov 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
On 02/22/2011 05:32 PM, Kevin Grittner wrote:
[moving to -hackers with BC to -general]
Dimitri Fontainedimi...@2ndquadrant.fr wrote:
Kevin Grittnerkevin.gritt...@wicourts.gov writes:
PL/pgSQL seems tantalizingly close to being useful for developing
a generalized trigger function for
On Tue, Feb 22, 2011 at 10:51:05AM -0600, Kevin Grittner wrote:
Dan Ports d...@csail.mit.edu 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
Andrew Dunstan and...@dunslane.net 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
Dan Ports d...@csail.mit.edu 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
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
On Tue, Feb 22, 2011 at 3:34 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 22.02.2011 16:29, Robert Haas wrote:
On Tue, Feb 22, 2011 at 8:58 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
No, the hash is stored in shared memory. The hash of the
On Tue, Feb 22, 2011 at 5:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net 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.
On Tue, Feb 22, 2011 at 8:00 PM, Joachim Wieland j...@mcknight.de 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
Robert Haas robertmh...@gmail.com writes:
On Tue, Feb 22, 2011 at 5:24 PM, Tom Lane t...@sss.pgh.pa.us 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
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
[ removing Radoslaw from the CC list, as his email is bouncing every time ]
On Tue, Feb 22, 2011 at 8:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Feb 22, 2011 at 5:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
It'd be more future-proof than this
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
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
2011/2/22 PostgreSQL - Hans-Jürgen Schönig postg...@cybertec.at:
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
On Tue, Feb 22, 2011 at 8:55 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
Robert Haas robertmh...@gmail.com writes:
On Tue, Feb 22, 2011 at 8:20 PM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com 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
On Tue, Feb 22, 2011 at 9:43 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com writes:
On Tue, Feb 22, 2011 at 9:43 PM, Tom Lane t...@sss.pgh.pa.us 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
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
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
On Wed, Feb 23, 2011 at 4:16 AM, Peter Geoghegan
peter.geoghega...@gmail.com 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
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
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 specific
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 what
75 matches
Mail list logo
