if no actual insertions occurred.
Unless I have missed anything, I think all other issues have been
adequately addressed. Since there are no red lights, I shall proceed. :)
Best regards,
Matt
On Sat, Jun 17, 2017 at 9:55 PM, Peter Geoghegan wrote:
> On Sat, Jun 17, 2017 at 7:49 AM, Matt Pulver
> wrote:
> > With the proposed "INSERT ... ON CONFLICT () SELECT" feature, the
> > get_or_create_id() function is simplified to:
>
> Are you locking the exi
NFLICT, this becomes well-defined, even
with exclusion constraints.
Feedback/guidance is most welcome.
Best regards,
Matt
commit is least
likely to cause people serious issues. As for the other options, consider
me opposed.
- Matt K.
ng money by not getting Windows licenses for your DR
environment, you are far better off just saving one more license and making
both your production and DR server be Linux builds.
- Matt K.
enums.html
[2] http://adpgtech.blogspot.com/2016/03/gin-indexing-array-of-enums.html
cheers
andrew
Thanks,
Matt
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
though it belongs to Trip
because I wrote it on company time. Let me see if I can open source a
version of it later this week that way you can use it for testing.
- Matt K.
y
return because pos will already be at QUEUE_HEAD. I prepared a second patch
that splits asyncQueueReadAllNotifications. Exec_ListPreCommit then only calls
the worker version only when needed. This avoids the duplicate lock.
Thanks,
Matt Newelldiff --git a/src/backend/commands/async.c b
On Tuesday, September 29, 2015 09:58:35 PM Tom Lane wrote:
> Matt Newell writes:
> > On Monday, September 28, 2015 07:22:26 PM Tom Lane wrote:
> >> Possibly. sinval catchup notification works like that, so you could
> >> maybe
> >> invent a similar mechanism f
On Monday, September 28, 2015 07:22:26 PM Tom Lane wrote:
> Matt Newell writes:
> > 1. When a connection issues it's first LISTEN command, in
> > Exec_ListenPreCommit QUEUE_BACKEND_POS(MyBackendId) = QUEUE_TAIL;
> > this causes the connection to iterate through every not
mbined with a duplicate, so the list would most
likely end up staying very small. If the backend local list does grow too
large then the connection could be killed or handled in some other appropriate
way.
I am happy to attempt coming up with a patch if the ideas are deemed
worthwh
>
> Even if it does fit in memory I suspect memory bandwidth is more important
> than clock cycles.
http://people.freebsd.org/~lstewart/articles/cpumemory.pdf
This paper is old but the ratios should still be pretty accurate. Main
memory is 240 clock cycles away and L1d is only 3. If the experi
as the denominator in that calculation should
help to smooth out that noise and show a clearer picture.
However, I'm happy with the committed version. Thanks Tom.
- Matt K.
On Thu, Feb 19, 2015 at 9:40 PM, Tom Lane wrote:
> Matt Kelly writes:
> > Attached is the fixed version. (hopeful
-type and
wrong extension. Alas, gmail doesn't let you set mime-types; time to find
a new email client...)
- Matt K.
*** a/doc/src/sgml/monitoring.sgml
--- b/doc/src/sgml/monitoring.sgml
***
*** 1710,1715 postgres 27093 0.0 0.0 30096 2752 ?Ss 11:34
0:00 pos
On Thu, Jan 29, 2015 at 8:42 PM, Tom Lane wrote:
> Matt Kelly writes:
> > Jim, I'm not sure I understand what you mean? This new function follows
> > the same conventions as everything else in the file. TimestampTz is
> just a
> > typedef for int64.
>
> ..
This is now: https://commitfest.postgresql.org/4/128/
On Thu, Jan 29, 2015 at 7:01 PM, Matt Kelly wrote:
> Robert, I'll add it to the commitfest.
>
> Jim, I'm not sure I understand what you mean? This new function follows
> the same conventions as everything else in the
fields of the global stats struct.
- Matt K.
On Thu, Jan 29, 2015 at 6:49 PM, Jim Nasby wrote:
> On 1/28/15 11:18 PM, Matt Kelly wrote:
>
>> In a previous thread Tom Lane said:
>>
>> (I'm also wondering if it'd make sense to expose the stats timestamp
>
ate (+docs & tests) needed to expose that value
to SQL. It shouldn't impact anything else in the server.
I'm not particularly attached to the function name, but I didn't have a
better idea.
The patch should apply cleanly to master.
- Matt K
pg_stat_snapshot_timestamp_v1.patch
t_timestamp() for monitoring code to use to
determine if its using a stale snapshot, as well as helping to smooth
graphs of the statistics that are based on highly granular snapshotting.
- Matt Kelly
onsuming a
core and half of CPU. I think its not worth tying these two things
together. Its probably worth it to make these two separate discussions and
separate patches.
- Matt Kelly
*Just sanity checking myself: Shutting down the server, applying the
different patch, 'make clean ins
across the server just like work_mem.
Obviously, this shouldn't block your current patch but its worth revisiting.
- Matt Kelly
l return
a recent free of the same size anyway. Making the guarantee that a PGquery
won't be reused twice in a row should be sufficient, and the only alternative
is
to add a unique id, but that will add further complexity that I don't think is
warranted.
Feedback is very welcome
sult(conn,result,curQuery,PGRES_TUPLES_OK);
if (curQuery == query2)
checkResult(conn,result,curQuery,PGRES_FATAL_ERROR);
if (curQuery == query3)
checkResult(conn,result,curQuery,PGRES_TUPLES_OK);
}
Note that the curQ
; Another thought is that for many applications, it would actually be OK
> to not know which query each result belongs to. For example, if you
> execute a bunch of inserts, you often just want to get back the total
> number of inserted, or maybe not even that. Or if you execute a "CREA
On Thursday, December 04, 2014 04:30:27 PM Claudio Freire wrote:
> On Thu, Dec 4, 2014 at 4:11 PM, Matt Newell wrote:
> > With the API i am proposing, only 2 new functions (PQgetFirstQuery,
> > PQgetLastQuery) are required to be able to match each result to the query
> > tha
previous async queries.
It would also be possible to queue the results and be able to retrieve them
out of order, but I think that add unnecessary complexity and might also make
it easy for users to never retrieve and free some results.
> There are probably plenty of other wrinkly bits to thi
ng the sync logic yet, but I'm guessing that an api to allow manual sync
instead of a sync per PQsendQuery will be needed. That could make things
tricky though with multi-statement queries, because currently the only way to
detect when results change from one query to the next ar
On Jun 24, 2014, at 9:42 AM, Tom Lane wrote:
> I think this means we can write off VAX on NetBSD/OpenBSD as a viable
> platform for Postgres :-(. I'm sad to hear it, but certainly have
> not got the cycles personally to prevent it.
Why? NetBSD/vax has supported shared libraries for a long lon
>I honestly do not mean any offence, just out of curiosity.
>If you guys care about money and time why would you spend the best years of
>your life basically copying commercial products for free?
1) For the same reasons commercial vendors build competing products: different
tools in the same cat
--- On Mon, 12/28/09, Andres Freund wrote:
> From: Andres Freund
> Subject: Re: [HACKERS] parse tree to XML format
> To: pgsql-hackers@postgresql.org
> Cc: "Robert Haas" , "matt"
> Date: Monday, December 28, 2009, 7:39 PM
> On Tuesday 29 December 2009 01
Is there some way to export the postgresql query parse tree in XML format? I
can not locate the API/Tool etc to do that...
thanks
-Matt
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
On Aug 11, 1:11 pm, j...@agliodbs.com (Josh Berkus) wrote:
> > Is there an easier way of going about this other than replacing the
> > postmaster / postgres components?
>
> I'd start with creating my own extended version to psql (the client
> library), I suppose. But since I don't really know what
other than replacing the
postmaster / postgres components?
Thanks for any pointers,
Matt
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> > adding an "anyelement2" pseudotype ... The context was a
> > compatibility SQL function to support Oracle's DECODE function.
>
> The reason it's not in there already is we didn't seem to have quite
> enough use-case to justify it. Do you have more?
No. Even this case, for me, is more an expe
A few months ago at
http://archives.postgresql.org/pgsql-general/2006-11/msg01770.php the
notion of adding an "anyelement2" pseudotype was discussed. The context
was a compatibility SQL function to support Oracle's DECODE function.
Assuming this new pseudotype has not been added yet, I'm ready to
> > The [pgcluster-1.7.0rc1-patch] patch applies to the 8.2.0 tarball ...
> > However, the patch will not apply to cvs branch REL8_2_0.
>
> I've been told that the pgcluster patch patches some generated files
> (parse.h and other apparently).
Yes, I could not at first apply to REL8_2_0 because the
> > difference between REL8_2_STABLE, REL8_2_0
>
> STABLE doesn't mean static. It's the branch for what will be the
> 8.1.x series.
Okay, and this is all different from HEAD, which will presumably become
8.3, correct?
---(end of broadcast)---
TIP 9:
> When I apply pgcluster-1.7.0rc1-patch to Postgres REL8_2_STABLE I get
> a handful of rejects.
The patch applies to the 8.2.0 tarball without rejects and without
fuzz. That's good. Now on to some fun with pgcluster...
However, the patch will not apply to cvs branch REL8_2_0. This all
raises t
> > Why should we add this Oraclism to PostgreSQL? I doesn't add any new
> > feature.
>
> Certainly, this feature falls well within the class of completely
> gratuitous proprietary extensions that we typically reject.
I now agree completely. My purpose is to migrate Oracle databases to
Posgres, a
> > I found it interesting that gram.c and parse.h already supported SYSDATE.
>
> Only after you ran bison ;-). They're derived files.
Well, so much for my conspiracy theory.
Thanks for the bison lesson.
---(end of broadcast)---
TIP 7: You can he
> I suggest you to contribute this kind of code to orafce project [1]
Thanks, I'll go play over there for a while.
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
> > Can't keywords share code
>
> the way to do what you want I think is
> like this:
>
> foo: bar_or_baz
> { code block }
>;
>
> bar_or_baz: bar | baz ;
I'll try that, thanks.
---(end of broadcast)---
TIP 6: explain analyze is your frie
Redirecting from -general.
> > I'd like SYSDATE to work syntactically and semantically the same as
> > CURRENT_TIMESTAMP
>
> current_time and the like are hardcoded in the grammar. You'd have to
> do the same for sysdate.
Okay, I patched. The patch follows. Please comment. In particular,
I've
> > head does this to me when I try to initdb:
>
> I bet you didn't do a full recompile after "cvs update".
> If you're not using --enable-depend then you really have
> to do "make clean" or even "make distclean".
I am using --enable-depend, but I'll 'make clean' and give
it another shot.
--
> > > head does this to me when I try to initdb:
> > ...
> > do "make clean" or even "make distclean".
>
> I am using --enable-depend, but I'll "make clean" and give
> it another shot.
All better. Thanks.
I guess I be suspicious of --enable-depend for a while.
---(end
> > head does this to me when I try to initdb:
>
> I bet you didn't do a full recompile after "cvs update".
> If you're not using --enable-depend then you really have
> to do "make clean" or even "make distclean".
I am using --enable-depend, but I'll "make clean" and give
it another shot.
--
head does this to me when I try to initdb:
[EMAIL PROTECTED]:~$ /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
The database cluster will be initialized with locale en_US
of the tables.
>
It seems that the above solution would be less work, and would keep the data
separate, which seems to be one of the biggest advantages of the current
inheritance design.
> 'Tis a hard problem :-(
I think that's why i'm interested:) I hope th
to
the correct index. It seems this would solve the unique problem without
changing much else.
Matt
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
> > Regards, Dave
> >
>
> Can't prepend a drive name anyways with 'cd', what if you're on a
> different drive?
>
> =Win2kpro=
> E:\>cd "c:/Test"
> The system cannot find the path specified.
Try "cd /D c:/Test"
The /D op
On Tue, 2005-08-30 at 00:56 +0200, Martijn van Oosterhout wrote:
> I saw the discussion about an tester for MVCC. Since I'd never done
> anything with asyncronous queries before, I figured I'd try to write
> something useful with it. The result is at:
>
> http://svana.org/kleptog/pgsql/mvcctest.ta
On Fri, 2005-09-02 at 12:29 -0700, Josh Berkus wrote:
> > still trying to hold on to my fantasy that I can hack Postgres (and
> > contrib/ora2pg) into submission.
>
> I'm happy to work with you on ora2pg
Cool.
It looks like I should have referred to contrib/oracle, not
contrib/ora2pg, but you go
> > Rewriting all my Oracle code function-by-function could be painful
> > ...
> > I'm still trying to hold on to my fantasy that I can hack Postgres (and
> > contrib/ora2pg) into submission.
>
> Why don't you just use EnterpriseDB?
I looked at EnterpriseDB a few months ago. The installation err
On Thu, 2005-09-01 at 18:28 -0400, Tom Lane wrote:
> Matt Miller <[EMAIL PROTECTED]> writes:
> > Basically I'd like my Pl/pgSQL code to be able to utilize the try/catch
> > paradigm of error handling without the overhead of subtransactions
>
> [Pl/pgSQL] can'
doc/src/sgml/storage.sgml says:
"The last 2 bytes of the page header,
pd_pagesize_version, store both the page size
and a version indicator. Beginning with
PostgreSQL 8.0 the version number is 2;
PostgreSQL 7.3 and 7.4 used version number 1;
prior releases used version number 0."
But src/include
On Wed, 2005-08-31 at 15:29 -0400, Tom Lane wrote:
> Matt Miller <[EMAIL PROTECTED]> writes:
> > I don't remember the last time I intended to write code that referenced
> > something that did not exist in the database.
>
> Almost every day, people try to write s
On Wed, 2005-08-31 at 11:59 -0700, Josh Berkus wrote:
> If a table does not exist, we don't want to check for that and bounce
> the function; possibly the function will only be called in a context
> where the table does exist.
The Pl/pgSQL compiler should be able to dive into SQL statements, hit
t
On Wed, 2005-08-31 at 13:13 -0500, Tony Caduto wrote:
> the function below also raises no errors at create, but at run time it does.
> ...
> CREATE or REPLACE FUNCTION public.test_func9(out firstname varchar,out
> lastname varchar)
> RETURNS SETOF pg_catalog.record AS
> $BODY$
> Declare
> row reco
On Fri, 2005-08-26 at 13:13 -0400, Nicholas Walker wrote:
> >You can't use savepoints, you can trap errors which is implemented using
> >savepoints. You still might want to write code like this:
> >
> >BEGIN
> >
> >
> >
> >SAVEPOINT foo;
> >
> >
> >
> >IF SOME_ERROR_CODE = 1234 THEN
> >
On Thu, 2005-08-25 at 15:50 +0900, Michael Glaesemann wrote:
> >> * %Remove CREATE CONSTRAINT TRIGGER
> >>
> > Do we really want to remove it,
>
> Also, I believe CONSTRAINT TRIGGERS are the only way to provide
> transaction level (rather than statement level) referential
> integrity.
Don't d
> > Perhaps we should look at Expect or something similar.
>
> Where can I get more info on Expect?
I think I found it:
http://expect.nist.gov/
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgres
> What we really need is a test program that can issue a command on one
> connection (perhaps waiting for it to finish, perhaps not) and then
> issue other commands on other connections, all according to a script.
It seems to me that this is what contrib/dblink could allow, but when I
presented th
On Mon, 2005-08-08 at 16:59 -0400, Tom Lane wrote:
> Matt Miller <[EMAIL PROTECTED]> writes:
> > I want to write some regression tests that confirm the behavior of
> > multiple connections simultaneously going at the same tables/rows. Is
> > there something like thi
On Wed, 2005-08-10 at 16:41 -0400, Tom Lane wrote:
> Matt Miller <[EMAIL PROTECTED]> writes:
> > It seems to me that contrib/dblink could greatly simplify the design and
> > coding of multi-user regression tests.
>
> I doubt it would be very useful, since
> a scri
On Mon, 2005-08-08 at 16:59 -0400, Tom Lane wrote:
> Matt Miller <[EMAIL PROTECTED]> writes:
> > I want to write some regression tests that confirm the behavior of
> > multiple connections simultaneously going at the same tables/rows. Is
> > there something like thi
be referenced in the SELECT.
SQL:1999 (feature E1210-02) relaxed this to allow columns to be specified in
the ORDER BY clause but not in the SELECT.
--
Matt Emmerton
---(end of broadcast)---
TIP 6: explain analyze is your friend
ersion. My only concern is if it would actually
delay the discussed rewrite of plpgsql by splitting the effort.
That's my two one hundreths of a euro, anyway.
Matt
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
overhaul of plpgsql :-(. But it needs one
> anyway.
Look forward to seeing it.
Matt
---(end of broadcast)---
TIP 8: explain analyze is your friend
this sort of thing isn't the
issue. The issue is whether we want to allow dynamic access to columns
in any syntax at all. A simple yes or no would do :)
Matt
BTW: here's the original post adding the rec.(3) syntax to the TODO:
http://archives.postgresql.org/pgsql-hac
triggers. Is this new in 8?
As an application developer, though, it'd be nice to keep everything in
one pl language, and ideally one guaranteed available (or easily
installable without other dependencies) on every postgres db out there.
That's pretty much wh
sions appearing
inside loops (and whose arguments are reassigned inside the loop?) and
marking them as dynamic.
Does that make any sense? Is it worth the work? Or should we just tell
anyone who actually needs it (I don't, at present) 'use another PL'?
Regards,
Matt
diff -u src.
s by ordinal - the example there was rec.(1). But I
was wrong about functions not working there - plpgsql_read_expression()
is smarter than that, as you say.
OK, download is done. I've got some more general ideas which relate to
this. I'll post along with updated version.
Matt
-
o pass a column name as an argument to a trigger
would make writing generic triggers a whole lot easier. And going back
through the archives on this list I see I'm not alone.
Regards,
Matt
On Thu, 2004-11-18 at 13:18, Matt wrote:
> Hi,
>
> I got extremely frustrated with having to cr
setting expectedtypeoid to InvalidOid bombs the whole thing :(
Hrm.... the "best made plans" and all that...
Matt
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
riting generic triggers. And it's a
tribute to the existing code that a complete newbie can cut-and-paste
their way to a halfarsed solution in a (rather long) night!
Regards,
Matt
diff -u src/pl_comp.c src.mk/pl_comp.c
--- src/pl_comp.c 2004-09-13 21:09:20.0 +0100
+++ src.mk/pl_c
[EMAIL PROTECTED] (Ned Lilly) wrote in message news:<[EMAIL PROTECTED]>...
> Jonathan,
>
> This is exactly how my company has built a very robust ERP application. See
> www.openmfg.com.
>
Hi Mr. Lilly:
I not sure who to address this question to at your company.
I'm a valued added reseller wh
76 matches
Mail list logo
